Rebuilding the workflow so SMS could finally ship
Overview
Problem
An agent does nothing until a workflow puts it to work, and the old builder could only place one kind of AI call. Customers had asked for SMS for over two years, and there was nowhere to put it.
Solution
We rebuilt the builder as a sequence of steps, with a router after each one that reacts to how it went. That gave SMS a place to go, and I designed it as the first next step.
- SMS finally possible after 2 years
- Routing on real outcomes
- Room for next steps
Role
Product & UX design: flows, information architecture, UI, design-system components, developer collaboration, async testing with CX. Both projects were led by our project manager. For the rebuild I was implementing a plan with another UX Designer, and for SMS, I was the only designer, and was working in the room with all the right problem solvers.
A builder that could do one thing
A workflow is what puts an agent to work: who it reaches out to, or how it handles calls coming in. The old one barely qualified: three triggers (contact created, contact updated, or nothing at all), a single action (an AI call) and a drip to meter how many went out at once. The actual goal of the call lived on the workflow as a whole, not on each call step.
We needed to add more complexity, and that required some information architecture restructuring.
More control of the workflow
The rebuild replaced one fixed behavior with a sequence the user controls at three points:
- Triggers got specific. The old ones were “contact created” and “contact updated”. Now a workflow starts from any webhook or a contact reaching out to the agent’s number.
- Voicemail lives inside each AI call step, instead of one voicemail for the whole workflow.
- Routing happens after every step, not once for the whole workflow. More on that next.
Routing by what actually happened
The old workflow couldn’t really route. It checked each call against preset “goals” that didn’t always match what the user was really after, and the one thing it could do in response was unenroll the contact.
The new router sits after every communication step. It came straight out of what people kept asking for, and every request was a version of “react to how that went”:
- Answered, but the agent didn't get what it needed? Maybe try again.
- Went to voicemail? Maybe try again, but not on the same schedule.
- Meeting booked, or transferred to a person? Stop. That contact is done; take them out.
SMS, after two years
SMS had been asked for for over two years. Customers wanted it, the company wanted it, and it kept not happening. With this rebuild, we had the back end that could support SMS, so it was time to deliver.
SMS dropped in as a new kind of step in a structure already shaped to receive one, and shipped outbound first, then inbound. Inbound allowed an incoming SMS message from a contact to start a workflow, and a text step gets the same routing a call does.
It was PM-led at the outset, but I was able to shape the solution that was delivered. We hit problems nobody had anticipated. Working them out meant one-on-one time with the developers, async testing with CX to find where it held up and where it didn't. I spent a lot of my energy arguing for the simplest version we could deliver while still allowing for the complexity we wanted to allow the users to have.
Inbox-style review
A more inbox-like way to read conversations. Cut for bandwidth, but near the front of the queue for the next time we touch it.
Agent memory
Letting an agent carry what it already knows about someone through a conversation. Also deferred, but still highly desired.
What it opened
The builder now reads as one path: who enters, what happens, how it behaves, when they leave. Instead of a pile of settings with a call bolted on, we have a workflow.
The more useful result is that things can be added to it now: LLM steps, custom routers, templated workflows. None exist yet, but all are buildable. SMS was just the first addition to the new framework we built.
The router taught the workflow to react to an outcome, but an outcome is only a label. Knowing a call ended in “booked a meeting” says nothing about whether the agent handled the conversation well. Answering that is the next study.
Where I'd take it next
The inbox-style review and unified memory are the immediate next pieces, and both were designed before they were deferred. After that the structure invites what it was built for: LLM steps, custom routing, and templated workflows. All of this was out of scope for now due to time, but now we’re in good shape to add them as it suits the company’s goals.
New screens are Figma mockups with made-up data. Older screens are captures of the previous product with customer details removed. The real product keeps changing with business decisions and user needs.