It started with follow-ups.
At Monarchy, I worked with GoHighLevel, or GHL, to connect lead forms, messages, emails, and course access. Someone replies; the next step changes. Someone books; the reminders need to follow.
I built chat workflows with OpenAI and Twilio, and later worked on voice agents using Vapi. Voice made the same problem more interesting: people interrupt, go quiet, change their mind, or never pick up.
A good conversation can still go nowhere.
One issue made this very clear. The voice agent could ask the questions we wanted, but the answers were not being saved back into the system. The call sounded useful. The person following up still did not have the information.
I worked through that gap: defining what the agent should collect, saving the answers and the call outcome, and making them available to the next part of the workflow.
One part of the outreach workflow
What happens when the phone rings?
They answer
Have the conversation. Check availability, book, or transfer when needed.
It reaches voicemail
Leave a message. Queue a text follow-up and a limited retry.
The small things took real work.
Voicemail detection. Making sure a passing “bye” did not end a call too early. What to do during a long silence. A fallback when a model or voice provider is unavailable.
These were the details I kept coming back to. I wanted the whole thing to be useful on an ordinary working day, including the calls that did not go to plan.
My take on it now.
I’m interested in the part after the impressive demo. Can someone on the team see what happened? Is there a clear next step? Does the information survive the handoff? That is where I found most of the work.
A little more on the build
GHL for customer workflows; Vapi for calls; SMS for follow-up. The outreach code includes structured call data, summaries, booking tools, voicemail handling, retry limits, and an operator view. This example comes from the campaign voice project within my broader Monarchy work.