Repair ticket and troubleshooting
How do we capture a service fault once with guided tests, and turn an unresolved issue into a repair ticket with the evidence attached?
Diagnose on the customer's screen before anyone creates a ticket. Callvu prefills the account and the service (the line, the equipment, the known outages at the address, the recent changes), classifies the symptom the customer describes into a fault type, runs the guided tests the fault type needs (the modem and router status pulled from the network, the line test, a reboot the customer confirms, a speed test on the customer's device, photos of the lights and the cabling), resolves what the tests resolve, chases the customer for the evidence a technician would need, creates the repair ticket with the test results and the evidence attached when the fault remains, books the visit where one is needed, and writes the ticket to the BSS, the system of record, and the field system with the customer told the next step.
In scopeComplex: multi-party handoffsCallvu moves: prefill, classify, chase and verify, write back
Last updated November 7, 2026.
The problem today
The customer rebooted the router three times for three agents, and the ticket said 'no internet'.
A fault call is a script: have you restarted it, what colour is the light, is the cable in. The customer has done all of it. The agent creates a ticket with a one-line description, the technician arrives without the history, and the second visit is where the fault is found. Meanwhile a known outage at the address was on a screen the agent never saw.
The diagnosis has a structure: the known state of the network and the equipment, the fault type from the symptom, the tests that isolate it in order, the evidence a technician needs (the light states, the cabling, the speed test, the error codes), and the ticket with all of it attached. The customer can run most of the tests on their own screen with the network data shown to them, and the ticket should carry what they found.
A ticket with the evidence attached is a visit that fixes the fault.
How it runs
From the requestto the system of record.
A customer reports a fault in the app, on the website, to an agent, or through an AI assistant. Callvu identifies them and opens the diagnosis.
- Customer
- Describes the symptom, runs the guided tests on their screen, confirms the results and uploads photos.
- Agent
- Sees the same diagnosis on a call and co-browses where needed.
- Network and field teams
- Receive the ticket with the evidence; the dispatcher decides exceptions in the Decision Desk.
- Callvu
- Prefills, classifies, runs the tests with network data, chases evidence, creates the ticket, books and writes.
Prefill and classify
The account and the service are prefilled (the line, the equipment and its reported status from the network, the known outages and planned work at the address, the recent orders and changes, the prior tickets); the customer's description classifies the fault type (no service, intermittent, slow, voice quality, a feature, equipment) and the tests that apply; a known outage is shown at once with the estimated restoration and the credit process.
Run the guided tests
The tests run in order on the customer's screen with the network data shown: the equipment status and the line test from the network, the restart with the customer confirming the light sequence, the cabling check with photos, a speed test on the customer's device, the device and Wi-Fi checks; each result is recorded, and a test that resolves the fault closes the case with the fix recorded.
Chase and verify the evidence
For a fault that remains, the evidence a technician needs is chased from the customer (the photos of the lights and the cabling, the times the fault occurs, the devices affected, the error messages); each is read and attached, and the customer is not asked again by anyone.
Write back
The repair ticket is created with the fault type, the tests and their results, the evidence and the network data attached, the visit is booked through the dispatch process where one is needed, the ticket is written to the BSS, the system of record, and the field system, the customer is told the next step and the estimated time, and a ticket outside the standard path (a repeat fault, a network-side fault, a safety issue) goes to the dispatcher in the Decision Desk.
Where it ends: The fault was diagnosed once on the customer's screen with the network data, resolved where the tests could resolve it, and otherwise became a ticket with the evidence attached that the technician could act on. The Decision Trace shows the classification, the tests and any decision; the Audit Trace shows each test result, each upload and the ticket write with time.
Runtime enforcement
What is enforcedwhile the work runs.
The regulations preloaded in Callvu Studio and the bank's own policies, applied as steps that run, not lines in a binder. A step that breaks a rule does not run, so a completed run was compliant.
The handoff
Between the front doorand the back office.
The front door
The app, the website, a call or an AI assistant; the customer tests on their own screen.
The back office
Network and field teams open tickets with evidence; the dispatcher decides only exceptions.
The Decision Desk
- A repeat fault, a network-side fault, a chargeable-visit question or a safety issue goes to the dispatcher in the Decision Desk with the ticket and only the allowed outcomes.
Proof
In scope.Proof at scale, not one process at a time.
The kind of process Callvu runs in production for customers in this industry. Ask for a reference on this exact process. The results below are the industry's published proof; each claim code links to its record on agents.callvu.com.
More than 1,000 processes are live across Callvu customers.
Across Callvu customers
AT&T runs close to 100 processes on Callvu, used by 55,000 agents.
Questions
What buyers ask next,answered plainly.
What tests does the customer run?
The ones the fault type needs, in order, on their screen with the network data shown: the equipment status and line test, the restart with the light sequence, the cabling with photos, a speed test and the device checks; each result is recorded.
What is in the ticket?
The fault type, the tests and their results, the photos and details, and the network data, so the technician starts from the evidence.
What if there is a known outage?
It is shown at once with the estimated restoration, no ticket is needed, and the credit process applies by rule.
Related processes
Bring this process, or the one that costs you most.
We build it against your policies and your systems, train your team and stay with you through launch. You are live in weeks.