[ FIELD SERVICE ]LIVE
Hub Virtual Assistant for Field Workforce
The call transcript, turned into a field brief. Hub extracts what the customer actually said, what support already tried, the sentiment on the line and the known equipment faults on that line, then hands the technician a next best action instead of a work-order number.
Queue
WO-55120 · 09:30Brief ready
No broadband sync — 14 Elm St
WO-55131 · 11:00Known outage
Intermittent drop-outs — Riverside Tower 4B
WO-55142 · 13:30Standard
New install — 7 Grange Rd
WO-55150 · 15:00Repeat visit
Slow speeds — 22 Hill View
Drafted reply · grounded in ontology
Next best action: start at Cabinet 12, port 17 — the SNR pattern matches the card fault logged Tuesday. Do not repeat the router reboot; support ran it twice on the call.
If SNR recovers above 9 dB at the cabinet, the internal wiring is fine. Update router firmware before leaving (customer mentioned Wi-Fi drops too).
Customer 360
- Customer sentiment
- Frustrated · 2nd call this week
- Already tried by support
- Router reboot ×2 · line test (pass) · profile reset
- Line
- FTTC · 380m · SNR 6.1 dB (low)
- Known issues
- Cabinet 12 card fault reported 2 days ago
- Equipment
- Router HG-635 · firmware 3 versions behind
// Problem
The Problem
The customer explains the fault to the call centre. The call centre tries three things. A work order is raised, and the technician arrives knowing none of it — so the first twenty minutes on site are spent repeating the steps support already ran, in front of a customer who has now explained the same problem twice. Repeat visits follow, because the one piece of context that would have prevented them was in a call recording nobody transcribed.
- Work orders carry a fault code, not the conversation that produced it.
- Troubleshooting already performed by support is repeated on site, in front of the customer.
- Known network or equipment issues affecting the line are not attached to the job.
- Repeat visits are the default failure mode, and each one costs a slot another customer needed.
// Overview
Hub sits between the contact centre and the field. Call transcripts are parsed for the facts a technician needs — the reported symptom, the steps support already attempted and their outcomes, the customer's sentiment, and any known equipment or network issues implicated on that line. From those it derives a next best action: the specific step most likely to resolve the job given everything already tried. A dynamic troubleshooting log travels with the job, recording what support did and what the technician subsequently did, so the record is cumulative rather than reset per visit. The assistant is delivered inside the mobile workforce management application the field team already uses, and it learns from technician feedback on whether the suggested action was the right one.
// AI System
Why AI
The whole input is speech. A call transcript is unstructured, disfluent and full of the customer's own vocabulary for technical objects — and the useful content is scattered through it rather than stated in a field. Extracting 'what has already been tried' from that requires comprehension, not pattern matching. Sentiment matters for the same reason: it is carried in phrasing, and it changes how the visit should be handled. The next-best-action recommendation is then a ranking over the organisation's own resolution history, which keeps the suggestion grounded in what has actually worked on this equipment rather than in general advice.
// Specs
Specifications
- INPUT
- Contact-centre call transcripts, per job
- EXTRACTION
- Symptom, steps attempted, outcomes, sentiment, known faults
- OUTPUT
- Ranked next best action, grounded in resolution history
- LOG
- Dynamic troubleshooting record, cumulative across support and field
- DELIVERY
- Inside the existing mobile workforce management application
- LEARNING
- Technician feedback refines the knowledge base
// Features
Features
- 01Call transcripts parsed into a field brief rather than summarised into a work-order note.
- 02Next best action derived from what has already been attempted, so nothing is repeated on site.
- 03Customer sentiment surfaced before the technician knocks on the door.
- 04Known network and equipment issues on the line attached to the job automatically.
- 05Cumulative troubleshooting log spanning support and field, not reset per visit.
- 06Delivered inside existing mobile workforce applications, so no new tool is introduced.
// Architecture
Architecture
FIELD FLOW
Runtime · one item, left to right
- 01Call Transcript
- 02Insight Extraction
- 03Next Best Action RankingSteps AttemptedSentimentKnown Equipment IssuesResolution History
- 04Job Brief in Field App
- 05Technician Execution
- 06Outcome Feedback
dashed = the inference step, where the system exercises judgment
System stack
Data in · decisions out
01
Sources
The conversation and the network
02
Ingestion
Transcript to structured insight
03
Ontology
Job, line, and what has been tried
04AI
Intelligence
Rank the next action
05Human
Human control
Technician judgment on site
06
Actions
Written back
Observability
Every model call traced; evals run on real cases, not anecdotes.
Governance
Entitlements enforced at retrieval; rules versioned by the organisation.
Write-back
Systems of record are written only through the approval gate.
Technician feedback returns to the knowledge base; the ranking improves on the equipment it is used on.
// Impact
Impact
- Cumulative
- Troubleshooting log across support and fielddesign intent
- Fewer
- Repeat visits, by removing repeated stepsindicative target
Interested in the Field Workforce assistant?
Let's talk about what your call recordings could be telling your technicians.
Get in touch