Lumina Sales is live.See it

Write the call summary for the tech in the truck

6 min read

By Lumina Software

  • Voice AI
  • Operations
  • Service business
  • Reliability

When a voice agent answers a call for a service business, the call itself is half the job. The other half is what lands on someone's phone afterward. For a plumbing shop or an HVAC company, that someone is usually a tech sitting in a truck between jobs, or an owner reading texts at a red light. They have about ten seconds. If the summary does not tell them what to do in those ten seconds, the call might as well have gone to voicemail.

Most summaries we see in first drafts are written for nobody in particular. They read like meeting notes. "The caller called regarding an issue with his water heater. He mentioned that it has been making a noise for a few days and he would like someone to take a look. He asked about pricing. The agent explained that pricing depends on the issue." Every sentence is true. None of it helps the person who has to call him back.

So when we build phone reception, we treat the summary as its own product with its own reader. Here is how we shape it.

Start with the action, then the person

The first line of the summary should answer one question: what does the reader need to do, and by when? "Call back today, wants a quote on water heater replacement." "Booked Thursday 10am, no action needed." "Urgent: no heat, elderly resident, asked for a call within the hour." The reader can stop there and still make the right choice.

The second line is who and how to reach them. Name, callback number, and service address. We have the agent read the number back to the caller during the call, so the number in the summary is the confirmed one, not whatever the speech to text heard first.

Only after that does the summary get into detail. What the caller said is wrong, in their words where it matters. "Banging noise when the heat kicks on" is more useful to a tech than "reported a noise issue." The tech knows what banging means. A paraphrase throws that away.

The shape we ship looks like this:

  • Action: what to do and by when
  • Caller: name, confirmed callback number, service address
  • Issue: in the caller's own words, one or two lines
  • Promised: anything the agent told the caller the business would do
  • Flags: anything odd, like a caller who asked twice for a person

That fourth line is the one people forget. If the agent told the caller "someone will call you back this afternoon," the shop has made a promise. The tech reading the summary needs to know that promise exists, or they will call tomorrow and the customer will feel ignored. We have the agent log every commitment it makes in a fixed field, and the summary repeats it word for word.

Short beats complete

The urge with any AI output is to include everything because it is cheap to generate. Resist it here. A summary that runs to a full screen on a phone gets skimmed, and skimmed summaries are how the urgent call gets missed. We cap ours at a length that fits on one phone screen without scrolling, and the full transcript sits one tap away for anyone who wants it.

That cap forces choices. Small talk goes. Repeated questions go. A caller asking three times whether the shop is open Saturday becomes one line, "asked about Saturday hours," unless the repetition itself means something, like confusion a dispatcher should know about before calling back.

We also keep the wording boring and consistent. The same fields in the same order on every summary. After a week, a tech stops reading the labels and goes straight to the line they need. That only works if the format never moves. When a client asks for a new field, we add it at the end, not in the middle.

Route it to the person who acts on it

A good summary sent to the wrong place is a bad summary. Most small service businesses start with every call summary going to the owner by text. That works with ten calls a week. It stops working once the owner is fielding dozens of texts a day, most of which are booked appointments that need nothing.

We sort summaries by what they need before we send them.

  • Booked jobs with no open questions go into the schedule and a daily digest. No text.
  • Callbacks go to whoever handles callbacks that day, which is often the office manager, not the owner.
  • Urgent calls, as the business defines urgent, go by text to the on-call person right away, and to a backup if nobody opens it within a set window.
  • Calls the agent could not handle at all, like a caller who only wanted a person, go to the callback queue with that flag at the top.

The rules for what counts as urgent come from the business, in writing, before launch. No heat in winter, water where it should not be, a gas smell. We do not let the model decide on its own what is urgent. It classifies against the list, and if it is unsure, it marks the call urgent and says why. A false alarm costs a text. A missed emergency costs the customer.

Check the summaries against the calls

Summaries drift the same way prompts do. A change in the agent's instructions, a new service the shop offers, a model update, and suddenly the summaries start dropping the address or burying the callback time. Nobody notices until a tech drives to the wrong house.

So we review a sample of calls each week against their summaries. Not every call, only enough to catch a pattern. The questions are simple. Did the action line match what the call actually needed? Is the callback number the one the caller confirmed? Did every promise the agent made show up in the summary? Is anything in the summary that the caller never said?

That last question matters most. A summary that invents a detail is worse than one that leaves a detail out, because the tech trusts it. If the caller said "sometime this week" and the summary says "Wednesday," someone shows up Wednesday. When we find a summary adding facts, we treat it as a bug, fix the instructions, and add that call to our test set so the next change gets checked against it.

What to do with your own summaries

If you already have a phone agent, pull up the last ten summaries it sent and read them the way your busiest tech would, standing in a driveway with a phone in one hand. For each one, ask whether you know what to do from the first line. Ask whether the phone number is right. Ask whether you can tell what the agent promised.

If the answer is no on more than a couple, the fix is usually not a new tool. It is a fixed format, a short length limit, a written list of what counts as urgent, and someone checking a handful each week. That is a few days of work, and it is the part of voice reception your team touches every day.

The call is what the customer hears. The summary is what your business does next. Build both on purpose.

Written by Lumina Software. Have a question? Book a call

Keep reading