From WhatsApp to a Structured Order System

Since starting her business, Ayala has managed all orders for her boutique bakery through WhatsApp. As the only person working in the business, she is responsible for the entire process — talking with customers, baking and decorating, arranging deliveries, and creating receipts.

Most orders start with a general request such as, “I want a birthday cake,” and then develop into a conversation that can continue for hours or even days. During the conversation, many details are collected and sometimes changed, including the type of cake, size, flavors, colors, fillings, text, date, and delivery details.

At the end of this process, there is no clear and organized order to work from. Different versions of the order stay inside the chat, and WhatsApp becomes the main source of information Ayala uses while preparing the cake.

To understand where the main difficulties happened, I observed Ayala throughout the full workflow — from receiving a new request to preparing the cake, receiving payment, and delivering the order.

I saw how she repeatedly returned to WhatsApp to check an important detail about the cake she was working on. I also noticed how one small change during the conversation could affect the whole order. Sometimes the customer sent a new message after the details had already been agreed on, and sometimes they simply forgot to mention something earlier.

This mapping led me to one main insight: at no point does the conversation become a clear business record that Ayala can continue working from.

Based on this, I defined the product challenge: turn an unstructured conversation into a clear and reliable workflow that supports the order throughout the entire process.

How the Order Process Actually Worked

Mapping Ayala’s existing workflow showed five steps that appeared in almost every order:

1. Receiving a request — A customer sends a WhatsApp message, sometimes while Ayala is already working on other orders.
2. Collecting order details — Ayala and the customer discuss details such as flavors, colors, fillings, text, date, and other information. These details may also change during the conversation.
3. Rebuilding the order during preparation — When Ayala starts working on the cake, she goes back to the chat, scrolls through the messages, and tries to understand the latest version of the order.
4. Arranging pickup or delivery — Delivery details and customer updates continue inside the same WhatsApp conversation.
5. Creating a receipt — After payment, Ayala manually enters the customer and order information again into an external invoicing system. Once again, she collects the information from the chat.

The same information moves through several stages, but each time Ayala needs to find it, understand it, or enter it again.

There Is No Single Source of Truth for an Order

Order details are spread across messages, images, and changes made during the conversation.

A customer may first choose pink and later change it to blue, choose a different filling, or add text a day later. To understand what the customer actually ordered, Ayala needs to go back through the conversation and compare the different versions.

The more an order changes, the higher the chance that she will accidentally work according to information that is no longer correct.

Mistakes Become Part of the Process

Depending on memory and manually reading through the conversation caused mistakes almost every week: the wrong flavor, a missed color, a forgotten filling, text that was not updated, or a date change that was missed.

Each mistake could mean making something again, wasting ingredients, or creating a bad customer experience.

Every Order Is Handled Separately

Even when several orders include the same flavors, colors, or fillings, there is no way to see this overlap in advance.

For example, four chocolate cakes become four separate rounds of preparation and cleaning.

The information exists inside the orders, but there is no tool that connects the orders and helps Ayala plan the work together.

The Same Information Is Entered Again in Other Systems

After receiving payment, Ayala opens an external invoicing system and enters information that was already collected earlier: the customer’s name, product, price, and date.

In other words, the same information moves between systems through manual work. This takes more time and creates another place where mistakes can happen.

The Same View Is Used for Different Needs

While preparing a cake, Ayala needs to quickly see important production details, such as flavor, color, filling, and text.

At that moment, prices and payment details are not relevant.

So even when all the information already exists in the WhatsApp conversation, it is not presented in a way that fits the task Ayala is doing.

From my observations and workflow mapping, I defined four principles that guided the design of the system.

Flexibility Controlled by the User

Different products need different information.

A simple cake may only need one flavor and some text, while a more complex product may include several flavors, colors, fillings, and extras.

The system therefore needs to allow Ayala to change the products and the information collected for them by herself, without requiring a code change every time the catalog changes.

Reusing Existing Settings

Flavors, colors, fillings, and other options are often shared between different products and price levels.

Instead of defining the same information again and again, the system should manage it in one place and allow Ayala to reuse it in every product where it is relevant.

The Information Keeps Being Useful After the Order Is Created

Once orders are stored in a structured way, the same information can also be used for planning the work.

For example, if several orders include chocolate or cream in the same color, the system can connect this information and show Ayala what can be prepared together in advance.

This can save a lot of time.

The View Should Match the Task

The customer and Ayala work with the same order, but they need to see different information.

The customer needs a clear summary of what was ordered.

Ayala needs to quickly see the details that affect the actual preparation, such as colors, flavors, and fillings.

The same source of information should support both situations, while showing the right information to each user.

There are many order management systems available, but this case needed a structure that could adapt to the product itself.

Every cake can have different characteristics.

One product may include one flavor and one color. Another may include three flavors, a filling, and custom text.

A fixed form would create unnecessary fields and limitations, and every change in the catalog would require extra maintenance.

So I defined a simple principle:

The product builds its own order form.

Ayala defines what information is needed for each product, how many choices the customer can make, and which options are available.

The system then uses these settings to build the order process dynamically.

For example, a cake that includes two flavors will show two flavor selections. A product that allows three flavors will show three.

If a product does not need a color or filling, those fields will not appear at all.

All products use the same flexible system behind the scenes. This means Ayala can add products and change the catalog without creating a new form for every product.

Each Product Defines the Information It Needs

Instead of having one form with fixed fields, each product is built from the fields and options that are relevant to it.

For every product, Ayala can add fields such as flavor, color, filling, or text.

She can choose whether the customer should type a free-text answer or select an option from a list. She can also decide how many selections are required for each field.

For example, if a cake includes two flavors, the order form will show two required flavor selections.

If another product allows three flavors, the same system automatically adjusts without needing a separate form.

For Ayala, this means she can change the structure of her products directly inside the system, even when the catalog and product options change.

Repeated Options Are Managed in One Place

A large part of the product information is shared between different products.

For example, the same flavors may be available for both a bento cake and a birthday cake. The same colors or fillings may also be used across several product categories.

For fields where customers choose from a list, I created shared lists.

Instead of managing the same flavor list separately inside every product, Ayala manages the list once.

Any product that needs a flavor field can then connect to that shared list. The same works for colors, fillings, and other options.

If Ayala adds a new flavor, she only needs to add it once. It is then updated automatically in every product connected to that list.

Pricing Tiers Build on Each Other

The same product can be sold at different price levels.

Each level can change both what the customer receives and what information needs to be collected in the order form.

For example, a basic level may include two flavors. A higher level may keep those two choices, allow one additional flavor, and also add a color selection.

There was no reason to define the entire product again for every price level.

Instead, each level is built on top of the previous one and only defines what changes.

This allows Ayala to update shared settings once while still keeping the differences between pricing levels.

Custom Information Appears Only When It Is Relevant

Some details in an order depend on another choice made by the customer.

For example, an address is only needed if the customer chooses delivery instead of pickup.

This means some questions are only relevant when the customer selects a specific option or extra.

The system therefore shows additional fields based on the choices made during the order process.

If the customer chooses delivery, an address field appears.

If they choose pickup, there is no reason to show it.

This keeps the form focused and makes sure customers only see information that is relevant to their choices.

Shared Settings Across Products

During the product definition process, I also found that complete groups of fields could be shared between several products.

Examples include allergens, packaging upgrades, or general extras.

Again, the goal was to avoid maintaining the same information several times.

Ayala can create one shared group in the system, including its options and prices, and connect it to the relevant products.

Every product connected to that group automatically receives the same fields.

This makes it easier to manage shared information across the full product catalog.

The system structure described above allows Ayala to expand and change her catalog without turning every business change into a development task.

Once the information was stored consistently, it also became possible to use it for more than just the order form.

At this stage, I focused on three areas where Ayala was still doing manual work: planning preparation, working in the kitchen, and creating receipts after payment.

While observing Ayala’s workflow, I noticed that every order was treated as a separate unit, even when several orders required exactly the same components.

If she has four chocolate cakes coming up over the next few days, there is no reason to prepare the same cake base four separate times.

The same is true for creams, colors, and fillings.

This led to the batch preparation tool.

The dashboard includes a section that collects upcoming orders and groups similar components across them.

Ayala can choose a date range and see, for example, that during that period she needs to prepare four chocolate cake bases, three batches of pink cream, and two dulce de leche fillings.

Instead of opening every order and finding the overlap herself, she gets one clear overview that helps her decide what can be prepared together.

Once all the information was organized in one place, I noticed another problem:

A full order summary is still not the right view when someone is actually preparing the cake.

While working in the kitchen, Ayala needs to identify the important preparation details within a few seconds: flavors, colors, fillings, text, and special instructions.

Price, payment method, and other administrative information only create unnecessary noise at that moment.

Because of this, I decided to completely separate the customer’s order view from Ayala’s working view.

For Ayala, I created a “kitchen note” style that shows only the information needed for preparation. The details are shown in a clear hierarchy that is easy to scan quickly while working.

The customer still receives a full order summary with all the information that is relevant to them, presented in a view designed for their needs.

Another point where Ayala had to enter order information again was after receiving payment.

She had to open the invoicing system, enter the customer details, product, and amount again, create the receipt, and then send it to the customer.

To remove this duplicate work, I connected the system to the API of the digital invoicing provider.

This allows information that already exists in the order to continue directly into the receipt process.

When Ayala marks an order as paid, the system uses the existing customer and transaction information to create the receipt.

After the receipt is created, the customer can access it directly from their order details through a link.

The system has been in regular use for about a year.

During this time, there has been a clear change in the way Ayala manages both her orders and the work around them.

Fewer Order Mistakes

Before moving to the system, mistakes such as using the wrong color, missing a flavor, or forgetting to update the text happened almost every week.

Since orders started going through a structured process and are saved as one clear record, no mistakes of this type have been reported.

Instead of returning to the chat and trying to understand the customer’s latest request about a color or flavor, Ayala works from information that was approved by the customer and saved in the order.

Less Repeated Work

The batch preparation tool also changed the way Ayala plans her workday.

Instead of starting with each cake separately, she can see in advance which components are shared between orders and prepare some of them together.

In a typical week of 10–15 orders, the estimate is that working this way saves around 10 hours that were previously spent on repeated tasks, including separate preparation and repeated cleaning.

Seeing what is needed for upcoming orders also makes it easier to plan preparation and purchasing.

According to Ayala, there are now fewer leftovers, less waste, and fewer situations where she has to stop working because an ingredient is missing and make a last-minute purchase.

Less Administrative Work

Creating receipts used to be a manual process that took several minutes for every order: opening another system, entering the information, and sending the document to the customer.

Today, the information moves directly from the order into the receipt creation process.

With around 40–60 orders per month, this saves several hours each month and also helps prevent mistakes when entering receipt details.

More Control Over the Process

The biggest change Ayala talks about is the feeling of having more control and order in her work.

She describes a process that used to feel tiring and stressful as now being “organized and calming.”

Instead of worrying that an order or important detail will get lost inside WhatsApp conversations, she knows that all the information is stored in one place.

She can clearly see the latest version of every order and what is coming up during the week.

She can simply open the system, see the upcoming orders, and know that everything is documented and organized.

I led the project end to end: from the first observations and workflow mapping, through defining the problem, requirements, and product principles, to UX/UI design, information structure, frontend and backend development, and the integration with Morning.

One of the main challenges was designing a system that supports highly dynamic products, where field types, pricing levels, options, and categories can change from one product to another.

I learned how important flexibility is in a system like this, but also that this complexity should stay behind the interface.

From Ayala’s point of view, the actions should stay simple: define a product, choose what information is needed, and manage orders without having to think about the structure working behind the scenes.

The project also showed me that even a small business and a system with only one main user can require deep product and system thinking.

Product flexibility, permissions, data management, edge cases, and the ability to continue developing the system over time all require planning in advance, even when the product itself needs to feel very simple to the user.

In the end, a process that was based on WhatsApp messages, memory, and manually moving information between systems is now managed through one source of information that supports the order from collecting the first details all the way to preparation, payment, and receipt.