An event management company in the US was running client communications across four channels that did not know about each other. The CRM held one version of a client. Email held another. Phone calls lived in a third system, SMS in a fourth. Each event brought a different client with different preferences and a different set of people to coordinate.
The company had not chosen this. It is what happens when tools are adopted one at a time, each solving the problem in front of it, over several years of growth.
What it actually cost them
The visible cost was duplicated effort — the same update entered in two places, the same client asked twice for something they had already provided.
The expensive cost was subtler. Nobody could answer "what is the current state of this client" without checking four systems, and because nobody could, decisions were made on partial information. A follow-up went out to someone who had already replied. A call was made to a client who had asked for text only. An event ran with the account manager unaware of a conversation a colleague had had the previous week.
For a business whose product is coordination, that is not an administrative inconvenience. It is the product degrading.
The constraint that shaped everything
The requirement that mattered most was not technical. It was that the client had to be able to configure their own flows, without engineering involvement, with no technical background.
This is easy to agree to and hard to honour, because the obvious implementation — a flexible system with a powerful configuration surface — produces something only its builders can operate. The failure mode of automation projects in operations-heavy businesses is not that the automation is wrong. It is that it becomes unchangeable, so it slowly stops matching how the business works, and people route around it.
So the design question was not "what should the pipeline do", it was "what is the smallest set of concepts someone can hold in their head and still express how they want an event run".
What we built
A single automation pipeline sitting over the existing channels, with one record of the client underneath it.
Unified client state. CRM, email, calls and SMS write into one view of each client rather than four. When a conversation happens on any channel, it is part of that client's history — so the question "where are we with this client" has one answer, available to anyone who needs it.
Flows the client configures. Sequences are built from a small vocabulary: a trigger, a condition, an action, a wait. What that deliberately excludes is as important as what it includes — no scripting, no expressions, no branching complex enough to need testing. If a flow cannot be read back as a sentence by the person who built it, it is too complicated to maintain.
Channel choice as a client property, not a flow property. Whether someone is contacted by email, SMS or a call is a fact about that client, held once. A flow says "contact them"; the system decides how. That removes the most common source of error in the old arrangement — the wrong channel for the wrong person — without anyone having to think about it.
Agentic handling of the unstructured parts. Replies arrive as prose. The agent reads them, updates the client record, and advances or holds the flow accordingly. Where a reply is ambiguous, or asks something the flow does not cover, it stops and surfaces it to a person rather than guessing at an interpretation and acting on it.
Where we drew the line
Three limits, set at the start and enforced in the system.
The agent does not commit the business to anything. It schedules, confirms, chases and records. It does not agree terms, promise a date that is not already in the plan, or make a commercial concession. A system operating on a client's behalf with authority to bind them is a liability, not a feature.
Ambiguity stops the flow. A reply the agent cannot interpret with confidence pauses that client's sequence and raises it. The alternative — proceeding on the most likely reading — produces the exact failure the project existed to remove: a client handled on the basis of something they did not say.
Every automated action is visible and reversible. The client can see what the system did, why, and on which trigger, and can stop a flow mid-sequence. Automation people cannot inspect is automation they eventually switch off.
The outcome that mattered
The measure was not messages sent or hours saved. It was whether the client could change how an event runs without calling us.
They can. Flows are built and altered by the people running the events, in the language they use to describe those events, and the four systems that used to disagree about who a client was now agree — because there is only one place that answer lives.
Have a system that needs to do this?
500+ systems shipped since 2011, and we still maintain most of them. Tell us what you are trying to move.
