How to Build a Follow-Up Reminder Agent for a Sales Rep

A sales rep makes a dozen small promises a day and keeps almost none of them on time.

Not because the rep is lazy. Because the promise gets made in the doorway. The customer is halfway to their car. Something just got said, "call me Tuesday after I hear from my wife," and there is no keyboard in reach and the next up is already walking in.

That promise lives in the rep's head now. Until it does not. And Tuesday comes and goes and the deal cools by a degree nobody notices until it is cold.

That gap is the whole problem. It is also one of the best first agents an operator can build.

I sell cars for a living. Twenty years in automotive retail, no tech background, no computer science degree. I have dropped that Tuesday more times than I want to admit. So I built a follow-up reminder agent for that exact moment. This is the build log. The stack, the bugs, and the fixes.

What does a follow-up reminder agent actually do for a sales rep?

It moves a promise out of the rep's head and onto a clock.

Nothing more than that. It does not write the follow-up message. It does not decide the pitch. It does not replace the rep's read on when a customer actually wants to hear back. It listens for two seconds, pulls out the who and the when, and makes sure the rep is reminded at the right time with enough context to pick the thread back up.

Here is the real moment it is built for. A customer says on the way out, "I am serious, just call me Wednesday morning once payday clears." The rep cannot stop to log that. So it goes in the head. And the head is already holding four other Wednesdays and a lunch order.

The agent replaces the head with a five-second voice note. Tap, speak, done. Wednesday morning the rep's phone buzzes with "call the customer on the blue Silverado, payday cleared, they asked for a morning call."

That is capture and schedule. It is close cousin to the voice-to-task agent I built for a service writer, and the front half of the stack is nearly identical. The difference is the back half. A task lands in a list. A reminder has to wait, then fire at exactly the right time. I broke down the capture side in detail in how to build a voice-to-task agent for a service writer. This post is about the part that waits.

What is the stack, conceptually?

Five pieces. Each one does exactly one job. That is the whole design.

Mic capture (phone web app)

→

Transcribe audio to text

→

LLM parse person + reason + time

→

Scheduler holds the reminder

→

Notifier pings the rep

Mic capture. A simple web app the rep opens on a phone. One button. Tap it, it records, tap again, it stops and sends the audio up. No app-store install, no login gymnastics between customers. Just a page with a mic. This is the same front door as the voice-to-task build, and it breaks in the same mobile-audio ways, which is why I do not repeat that fight here.

Transcription. The audio goes to a speech-to-text step that returns plain text. You send audio, you get a string back. Solved problem, mostly.

LLM parse. You hand the transcript to a model with a tight instruction: pull out three things. Who to follow up with, why, and when. The "who" and the "why" are the easy part. The "when" is the hard part, and it is the whole reason this agent is harder than a plain task capture. "Tuesday" is not a time. It is a puzzle the model has to solve against today's date, and it will get it wrong in ways I will show you.

Scheduler. The parsed reminder gets stored with its fire time and held until that moment arrives. This is the piece a task-capture agent does not have. A task lands and it is done. A reminder has to survive until Wednesday, through restarts, through deploys, through the machine sleeping. The classic tool for "run this thing at this time" is cron, the scheduler that has been quietly firing jobs on servers for forty years. You do not have to use cron itself, but you have to solve the problem cron solves.

Notifier. At fire time the reminder gets delivered back to the rep, on their phone, with the context attached. A buzz that just says "follow up" is useless. A buzz that says who, why, and what they asked for is the product.

You can stand all five up on free and hobby tiers to start. Once it is live for one rep it runs on less than fifty dollars a month in hosting. That is not a teaser number, it is what a single-operator agent actually costs to keep on.

Why build the scheduler and the notifier before the cool part?

Because a follow-up reminder that fires at the wrong time, or never fires, is worse than no reminder at all.

The mic and the parse feel like the product. They are not. The moment of truth for this agent is Wednesday morning, when the phone is supposed to buzz. If it buzzes on time with the right context, the rep trusts it and starts offloading every promise into it. If it buzzes a day late, or buzzes with no context, or does not buzz at all, the rep goes back to keeping promises in their head and the agent is dead.

So I build the boring back half first. I make sure a known-good reminder, hand-fed into the scheduler, will survive a restart and fire on time and land on the rep's phone with its context intact, every single time, with a record that it happened. Only then do I put the voice on the front. This is the same order I build everything in, for the same reason, which I laid out in why I built the routing layer before any of the agents. The plumbing is the product. The faucet is the demo.

The mic is the demo. The reminder that fires on Wednesday is the product. Build the part nobody claps for first.

If you are trying to decide whether this is even the right agent to build first for a sales floor, I put a simple test for that in how to evaluate an AI agent for your sales floor. The short version: small, painful when missing, happens every day. A dropped follow-up hits all three.

What breaks first, and how do you fix it?

Three failures, in the order they hit me.

One. Time parsing quietly guesses wrong. The rep says "follow up Tuesday," and the model returns a date. But which Tuesday? This one or next? And in whose timezone? The model will confidently hand you a timestamp that is a day off, or a week off, or built against the wrong clock, and it will never tell you it guessed. This is the failure that will embarrass you fastest, because the rep will get the buzz on the wrong day and immediately stop trusting the thing.

The fix is two-part. First, always pass the model today's date and the rep's timezone as context, and make it resolve relative words against that, not against whatever the model imagines "now" is. The behavior of dates and offsets in code is a whole rabbit hole, well documented at the MDN Date reference, and you will read it more than once. Second, make the model return the resolved time in plain words alongside the timestamp, "Tuesday, 9am, your time," and show that back to the rep at capture. A one-second confirmation kills the wrong-Tuesday bug before it ever fires.

Two. The scheduler forgets when the process restarts. My first version held the reminders in memory. It worked beautifully in testing. Then I deployed a change on a Monday, the process restarted, and every reminder that had been waiting quietly vanished. Nobody got buzzed. In-memory timers do not survive a restart, and your process will restart, on a deploy, on a crash, on a platform putting your app to sleep. A reminder that only exists in RAM is a reminder you are going to lose.

The fix is to store the reminder in something durable the moment it is scheduled, and to have the fire mechanism read from that store, not from memory. This is exactly the discipline the old cron and crontab model bakes in, jobs written to a file that outlives any single run, defined in the POSIX crontab spec. Whatever you build with, the rule is the same: if a reminder is not written down somewhere that survives a restart, it is not scheduled. It is just hoping.

Three. The silent missed follow-up. This is the one that will actually cost a deal. A promise gets captured, the transcription succeeds, the parse looks fine, and then something in the scheduler or the notifier fails, and the buzz never comes. No error. The rep believes it is handled. It is gone. And unlike a dropped service task, a dropped sales follow-up is money walking out the door, and the rep only finds out when the customer buys somewhere else.

The fix is to make every step confirm the next one, and to make the system tell on itself when a fire is missed. A reminder is not "scheduled" when the audio uploads. It is scheduled when it is sitting durably in the store with a confirmed fire time. And the notifier has to be watched, so that a reminder whose time has passed without a delivery gets surfaced, loudly, instead of dissolving. Anything in flight can be lost, so nothing is allowed to stay silently in flight.

How do you keep the build small enough to actually ship?

You ship one shape of reminder first.

Not every kind of follow-up a rep might ever promise. One. The dated callback. Capture a spoken "follow up with this person on this day," parse the person and the day, schedule it, fire it on time with the context. That is the whole v1. It is small. It is painful when it is missing. And it happens every single day a rep works. Those are the three criteria I hold every first build to.

Then you run it for a week without adding anything. A week of a real rep using it on a real floor tells you which of your imagined features were real and which were you gold-plating at your kitchen table. Almost always the thing that matters is not a fancier reminder type. It is that Wednesday's buzz showed up on Wednesday, with the right name, and the rep did not have to think about it in between.

Only after that week do you add the next shape. A "follow up in three days" relative reminder. A recurring nudge for a long deal. A snooze. Each one is cheap once the durable scheduler and the notifier underneath already work, because adding a shape is just a new way to compute a fire time, not a new machine. This is the compounding that makes an operator stack grow. Five rivers, twenty-two agents, all built the same way, one small trusted piece at a time. If you want the starting sequence for your own first build, I wrote it out in how to start building AI agents if you have a day job.

Does a sales rep need to know how to code to run one?

No. The rep taps a button and speaks, and later their phone buzzes. That is the entire interface.

The person building it needs to be able to follow a build, modify code a model writes, and read enough of it to fix the three failures above when they show up. That is closer to running a complicated spreadsheet than to being a software engineer. The genuinely tricky parts are narrow: getting the time right against a real clock, and keeping the schedule durable across a restart. Neither requires a computer science degree. Both require you to respect that they are where the reliability lives.

The reason to build this one, if you are an operator picking an agent for a sales floor, is that it is small, the failures teach you everything about scheduling and time, and the moment it works you have removed a class of dropped promises from a real person's day. That is the only scoreboard that matters here. Fewer follow-ups lost. Fewer Wednesdays nobody remembered until the customer had already bought elsewhere.

The community where we ship these in public, bugs and all, is at skool.com/agent-empire-4291. Free.

While I sell cars for a living.

Michael