Showcase · Build AI
Pattern: front-desk intake
A teaching example of turning messy phone intake into a draft a person reviews and files. It’s a composite, not a client case, and claims no results.
3 min read
This is a teaching example, pieced together from the way small service businesses describe their mornings. It isn’t a client case study, and it doesn’t report any time saved, money saved, or before-and-after results. If you’d like to know how to read pages like this one, start with how to read an honest build.
The problem
The phone rings while someone’s also trying to keep an eye on the front door. The details of the call end up in a notebook, a text thread, and someone’s memory of what the caller said about getting in, the dog, or which location they meant. Later, a different person sets up the job and has to call the customer back because something was missing. That night the owner notices the gap, because they’re the one retyping it.
What’s really going wrong is that every job gets started twice. “We need AI” doesn’t describe that at all.
What a build like this includes
A build of this kind usually has four parts:
- A short list of the fields the business already requires: who the customer is, where the job is, what they need, when, and how to get in.
- A draft that fills in those fields from the notes the desk has already taken, in the order the job board expects them.
- A place where the draft waits. During a first pilot, it doesn’t create the job on its own.
- A named person who files it, or sends it back with a line about what’s wrong.
The source material is the business’s own examples, typically three good intakes and three that had to be redone. Without those, the draft ends up sounding like a generic call center. With them, it sounds like your front desk.
A sensible first version leaves out automatic scheduling, pricing, and texting the customer. Each of those is a separate decision for later, with its own review step.
What it replaced
When a build like this works, what goes away is the second from-scratch start. The person creating the job begins with a draft instead of a blank form and whatever they remember. The notebook might still be around during the shadow pilot, and there’s no need to throw it out on Monday to look modern.
If the desk is still retyping every field because the draft keeps getting things wrong, nothing has been replaced yet. That’s the point to revise or stop, as described in the build guide. Don’t keep a draft around that nobody uses because it looked good in the demo.
What stays with people
The person at the front desk still picks up on the caller’s tone. They still decide whether the job is real, whether the time window is something the business can commit to, and whether the access note has enough detail to send someone out. The draft never talks to the customer, and it never apologizes to anyone.
Calls that are angry, unusual, or involve a lot of money stay entirely with a person. Forcing them through the same template for the sake of consistency makes things worse. The template is meant for the everyday calls.
If you’d like help building this
A front-desk setup like this becomes custom work when the draft needs to land in the system you already use, carry your company’s name, work across more than one location, or be looked after by someone other than you next month. That’s a discovery conversation about a custom build, whitelabel screens, or Managed AI.
Bring three real intakes with the names taken out. The evaluation prep sheet covers the rest of what’s useful to have on hand.
Keep going
- How to read an honest build
How our showcase pages are laid out (the problem, what was built, what it replaced, and what stayed with people) and why none include invented results.

