Anatomy of an operating flow: WhatsApp, CRM and data in one loop

Most companies treat a customer conversation as the end of a process: someone wrote, someone answered, done. In practice the conversation is only the beginning. A question about an order becomes a refund, a stock check, a delivery change. If that work has no place in the operation, it lives in someone's head and in a chat history nobody can measure.

An operating flow fixes that. It is the path from the first message to resolved work, with every step recorded. This is its anatomy.

1. Intake: every channel into one queue

Conversations arrive through WhatsApp, social inboxes and web forms. The first rule is that they all land in the same queue with the same shape: who, through which channel, about what, and when.

A single queue matters more than any model choice. Two queues means two definitions of "open", two backlogs and no honest answer to "how many customers are waiting right now?"

2. Understanding: classify before you answer

An agent reads each conversation and labels it before anyone replies: intent (order status, complaint, purchase, other), the entities involved (order number, product, store) and urgency.

Classification is what lets the rest of the system route work. Without it, every message is the same message, and the fastest responder wins instead of the right one.

3. Record: the CRM is the source of truth

Each conversation creates or updates a record in the CRM, linked to the customer. The chat is a channel; the record is the work. That record moves through explicit stages, for example:

• New: received and classified.
• In progress: someone or something owns it.
• Resolved: the customer's problem is solved, not just answered.

The distinction between answered and resolved is the whole point. A reply is an event. A resolution is an outcome.

4. Action and escalation: agents act, people decide

With the record in place, an agent can act on what it is allowed to do: look up an order, confirm a delivery window, collect missing data, propose a solution. Everything outside those limits escalates to a person with the full context attached, so nobody has to ask the customer twice.

Two design rules keep this safe:

1. Explicit permissions. The agent's allowed actions are a list, not a vibe. Anything not on the list escalates.
2. Every step on record. Each action, by agent or person, is written to the record. That is what makes the flow auditable and improvable.

5. Measurement: the loop that closes the loop

A flow you cannot measure is a hope. The minimum set of metrics:

• Resolution rate: share of records that reach Resolved, over a defined window.
• Time to resolution: the median, not the average. A few slow cases distort an average.
• Escalation rate and reasons: where the agent stops, and why. This is your redesign backlog.

Be strict about what you count. State the window, state which records are in the cohort, and say when there is no earlier baseline to compare against.

What this looks like in a real operation

For Rodo, a retailer in Argentina, WhatsApp, social and web enquiries were brought into a single service pipeline with exactly these stages. In the first measured window, 82% of the 604 enquiries created live reached Resolved, with a median of about one hour to get there.

The caveats are part of the result: it was a first window with no comparable earlier baseline, and the figures describe pipeline records, not every conversation. That is the discipline the flow enforces. You can only improve what you have defined.

Where to start

Start with the queue and the stages, not the model. Put every channel into one place, define New, In progress and Resolved, and measure for a few weeks. The agents you add afterwards will have somewhere to put their work, and a number that tells you whether they helped.