A technician voice note is a terrible document and a perfect input. It has the diagnosis, the parts, the “we should come back Tuesday,” and the thing the customer was actually worried about. It also has coughs, radio, half sentences, and no headings.
When we built ServiceBrief AI, the pipeline from that note to a report the office can stand behind was the first product, not a feature we bolted on later. This post is how that path is shaped.
Transcription is not the product
If you stop at a transcript, you have given the manager more text to ignore. The useful object is a structured brief: customer issue, equipment, diagnosis, work completed, parts, tests, safety notes, recommendations, missing information, a customer-safe summary, and whether a follow-up or a quote is in play.
Those fields have to come from evidence in the audio or the typed note. The model is not there to complete a fantasy of a perfect visit.
Do the work in a queue
Upload should feel instant. Processing should not. The request stores the job and the audio, marks the visit queued, and hands off to a worker. Status moves through transcribing, extracting, and summarizing so the UI can poll and tell the truth.
Real systems fail in the middle. We kept the transcript when extraction failed so a retry does not bill the same audio twice without reason. Duplicate clicks while a visit is already processing are ignored. Summary failure is non-fatal: the internal report can still exist if the customer paragraph did not generate. Stale queued work can be recovered instead of sitting in limbo forever.
Several small AI steps beat one giant prompt
One prompt that “does everything” is hard to debug and easy to make quietly wrong. We split the job: transcribe; extract a structured report with optional company SOP context; draft a customer summary; detect follow-ups; detect quote opportunities against a price book.
Each step has a job. Extraction is allowed to flag what the technician did not say. Summarization is allowed to be turned off in company rules. Quoting is not allowed to invent a rate. Classification of the visit type matters: a customer intake call should not get a fictional “work completed” section just because the schema has that field.
The report has to live in the job
Managers should not hunt a PDF in email to see the transcript, the photos, the follow-up, and the quote. ServiceBrief keeps the brief inside the job workspace with sources, files, and a timeline. Edits write a new version. Approve and reject are first-class. Export is a customer-safe PDF, not a dump of the admin screen.
Chronology matters. The story is the initial visit, then each follow-up as its own chapter, then a finishing assessment when the job is completed. Parts and tests come after the story, not mixed into a blob.
What to copy if you are building something similar
- Make capture cheap and processing asynchronous
- Persist checkpoints so retries are boring
- Split model calls by responsibility
- Keep a human approval step on anything a customer will see
- Store versions. You will need them the first time someone asks “what did it say before I edited?”
If you want the full product context — inbox, phone, quotes, knowledge — that is the ServiceBrief project page. This article is only the spine: voice in, structured record out, person in the middle.