VOICE-FIRST AI FOR FIELD TECHS
FieldWake
Telecom field technicians have a chatbot most of them do not use. The obvious brief is improve it. I think the right answer is kill it and replace it with something .
Industry
Telecom
Surface
Voice-first mobile
Pattern
3-trigger model
- Type
- Concept build, self-directed
- Scope
- Product design, build, writing
- Status
- Working prototype
What this is
A self-directed concept build. No client, no production users, no revenue on the line. I chose the problem, wrote the brief, made the calls, and built the working prototype. The design decisions are real and I will defend every one of them. The outcomes are unmeasured, because concept work cannot honestly claim outcomes. What I would measure is at the end.
TL;DR
I replaced a chatbot with a voice-first AI assistant for field technicians. Three trigger phrases. No chat UI. Hands-free, bandwidth-resilient. The obvious brief is 'improve the chatbot.' I think the right answer is kill it.
The problem
The chatbot was the wrong surface.
The premise: a telecom carrier's field technicians have a chatbot they mostly do not use. The obvious instinct is to improve the chatbot, better latency, better answers, better UI.
I think that instinct is wrong. Field techs do not have time to type. They are on a ladder, in a crawlspace, holding equipment in one hand. A chatbot needs two hands and visual attention. Both are the scarcest resources on the job site.
Improving the chatbot would not move adoption. The chatbot is the wrong surface entirely.
Process artifact
Three trigger phrases. No chat UI.
"Hey Field, find..."
Retrieval. Wiring diagrams, part numbers, error-code workarounds. Agent reads the answer aloud and offers to send the visual to the dispatch app for later.
"Hey Field, log..."
Capture. Technician dictates a note attached to the current job ticket. Agent transcribes, confirms, writes back to dispatch.
"Hey Field, help..."
Escalation. Agent connects to a senior tech with current job context attached. Stays on the line and offers to take notes during the call.
The approach
Voice-first, bandwidth-resilient, hands-free.
Voice-first, hands-free, bandwidth-resilient. Three trigger phrases: find, log, help: each tied to one intent class. No chat UI. The technician's hands stay on the work.
Find
Retrieval: wiring diagrams, error codes, parts. Read aloud, optional visual to dispatch app.
Log
Capture: dictated notes attached to the current job ticket. Auto-transcribed, written back.
Help
Escalation: connect to senior tech with job context. Agent stays on the line and takes notes.
Offline mode
Local cache + queued sync. Mode switch invisible. Agent says what it can do, never what it can't.
The offline-resilience strategy was the second piece. Most job sites have bad connectivity. The agent runs in two modes, full retrieval online, local-cache + queued sync offline, and never says 'I'm offline.' It says what it can do.
Decisions made
The calls that shaped the build.
Every project has a handful of decisions that determined the outcome. These are mine, with the trade-offs I accepted.
Killed the chatbot. Wrote the brief that re-scopes the problem from 'improve' to 'replace.'
Improving the chatbot is a path to incremental gain on a shape that does not match the job. Saying 'this surface is wrong' is the harder and more necessary call than making it faster.
The trade-off I accepted: no incremental path, no fallback to a familiar pattern. What I'd watch for: whether voice-only actually removes friction, or just moves it somewhere less visible.
Refused a 'fallback chat UI' as a hedge against the voice-first thesis.
A fallback chat UI signals doubt in the voice-first thesis. Given two surfaces, a technician will pattern-match to the more familiar one, which defeats the redesign.
The trade-off I accepted: no safety net if voice-first fails in a specific edge case. What I'd watch for: whether there is a real failure mode that needs a text-based escape hatch, distinct from just habit.
What I'd measure
There are no . Here is the scorecard.
Concept work earns the right to talk about outcomes only by naming how it would be judged. If FieldWake were live, this is the scorecard I would put my name to. If those numbers did not move, the pattern is wrong and I would want to know.
- Adoption rate against the chatbot baseline, tracked monthly, not just at launch.
- Time-to-resolution on jobs flagged complex, before and after voice-first rollout.
- Trigger-phrase accuracy: how often the system correctly classifies find / log / help.
- A failure-mode taxonomy for the offline mode, because a silent mode switch that gets it wrong is this design's most dangerous defect.
Visual moments
What this case study renders on the live site.
Audio waveform hero
A mocked technician voice saying 'Hey Field, I need to find the firmware reset for a Calix 844G.' Waveform animates; transcript reveals word-by-word.
Three-trigger model diagram
Three phrases as columns, each with intent class and example flow.
Online vs offline mode
Paired diagram showing what the agent does in each connectivity state. Mode switch is invisible to the technician.
What I'd do differently
In .
- 1.Build the offline cache as a v1 feature. Bad connectivity is the default on this job.
- 2.Design the trigger-phrase failure mode before the happy path. What the agent says when it mishears 'find' as 'log' matters more than the demo case.
Stack used
Tools that did the work.
More work