This post in 30 seconds.
- The idea: a structured service case is one record per job, assembled from guided capture by the person standing at the fault, that arrives before anyone is dispatched. Video per required step, photos of the named parts, the data plate, the fault code, the answers and the timestamps, together.
- The number: a failed first visit adds two more visits and 14 days to resolution, according to Aquant's 2025 field service benchmark. Most failed first visits start with a ticket that says "unit not working".
- The honest limit: a case can prove when it arrived and that its files are unchanged. It cannot prove when the fault happened or who caused it, and a good case says so.
- Written for: service managers, heads of field operations, dispatch leads and technical support managers at equipment makers, dealers, installers, utilities and maintenance providers.
Open the shared inbox on a Monday. Eleven photos from a customer, three of them the same shot. A voice note. Two emails with "see attached", one of which has nothing attached. Somewhere in there is the model number, or maybe it is in the WhatsApp thread the account manager started. Nobody has written down what the display said when the machine stopped.
That is not a service case. It is a pile.
A structured service case is what the desk should have received instead: one record, tied to one job, holding the footage, the identifiers, the fault codes, the answers and the checklist responses in a fixed order, with a timestamp on each, ready to review and route. This post defines the term for service operations, lists what the case should contain, explains why loose files never qualify, and walks through how a case is reviewed, closed, compared with other cases and, when it has to be, used as evidence.
If you run dispatch or a technical desk, you know the ticket that reads "not working, please send someone" and the trip that follows it. We build Venta Capture, a product of VentaVid, so that the customer, operator or technician at the fault can send you a structured case instead of a pile. Start for free and send one capture link to your own phone before you read on.
In this post:
What a structured service case is
A structured service case is a single record for one service event, built from a guided capture rather than from whatever the customer felt like sending. The organisation decides the steps. The person at the fault follows them on their own phone. The result lands in the team's queue as one case with one reference number.
The word "structured" is doing the work in that sentence. Every submission for the same job type contains the same items, in the same order, with the same questions answered. That is what makes it a case rather than a message with attachments.
A structured service case is an input record: it exists before the visit, not after it, and it is captured by whoever is already standing there. That is the opposite of the field service report your technicians write at the end of a job, and it is the reason the two get confused.
It is also not a work order. In most field service systems the case records the issue and the work order is the plan to resolve it. Microsoft's own Dynamics 365 Field Service documentation runs a work order through four stages, created, scheduled, performed, completed, and treats the case as the thing that can be turned into one. The structured service case is what should fill that upstream record with something better than a one-line description.
Why it matters is in the benchmark data. Aquant's 2025 Field Service Benchmark Report, drawn from about 160 service organisations and more than 600,000 technician records, found that a failed first visit adds two more visits on average and stretches resolution by 14 days. The same report puts first-time fix at 86% for the top performers and 53% at the bottom. A lot of that gap is decided before the van leaves, by what the desk knew.
Case management tools have existed for decades. What has been missing is a way to get a complete, ordered, verifiable submission out of a person who is not trained to produce one. That is the job guided capture does, and the structured service case is its output.
What the service team should actually receive
Ask a dispatcher what they wish every ticket contained and the list is short and consistent. The trouble is that nobody asks the customer for it in that form. So here is the list, as a case.
Each row is a step the participant walks through in the mobile browser, with no app and no account. A serial number step, for instance, shows an example photo of where the plate sits on that model, opens the camera with a scan frame and torch, and falls back to typing if the sticker is worn. A yes/no question ("Does the unit power on?") can change which steps come next, which is conditional logic doing the dispatcher's first three questions for them.
The case is the minimum evidence set for that job type, collected in full the first time, from the person who is already there. Write the list for a boiler no-heat call and it is perhaps seven steps. For a machine fault it is the display, the data plate, a walk-around video and four questions.
The spoken part deserves a mention. People will say "it makes a grinding noise for about ten seconds after start-up and then goes quiet" on camera and will never type it into a form. Transcription turns that into text the reviewer can search, so the sentence ends up in the case rather than in the customer's memory.
This matters more than it looks. In the Service Council's 2022 Voice of the Field Service Engineer survey of more than 1,850 technicians, summarised by GoFormz, only 63% agreed that their company makes it easy to find the information needed to resolve a service inquiry. Roughly one technician in three is working without it. Guided video capture, described in detail on the guided video capture page, is one way to close that gap at the source.
Why loose files in an inbox or chat are not a case
Every "send us some photos" inbox I have looked at has the same shape. Plenty of material, none of it in order, and the one thing the technician needs missing. The customer did their best. They were never told what "best" meant.
The difference between a pile and a case comes down to five questions. Can you find it? Is it complete? Is the order fixed? Who owns it? What does it prove?
The last row is where chat apps quietly fail you. A photo forwarded through a messaging app is re-saved by that app, its original device data is gone, and the time on it is the time of the forward. That is fine for a conversation and useless for a record.
The cost of the pile shows up as repeat visits. Industrility's write-up on why technicians keep returning for the same repair cites Aberdeen Group figures of 1.6 additional visits to close an unresolved job, and notes that around 35% of replaced parts are later found to be working. A part swapped on a guess is a diagnosis that never had the right inputs. "Unit not working" as the entire ticket, which that article names as a root cause, is the pile in one line.
Some teams try to fix this with a form. A form gets you fields. It does not get you the footage, the identifiers in a scan-checked format, or the spoken explanation, and it does not stop the customer attaching a gallery photo from last spring. The guided photo capture post covers why a labelled slot with an example photo beats an upload button.
A case is a thing the desk can act on without a phone call to ask what the photos are of. If your desk still makes that call, you are receiving files, whatever the system calls them.
If the pile is what your queue looks like today, book a demo and bring your messiest ticket type. We will build the case for it while you watch.
How a structured service case is reviewed, routed and closed
Receiving the case is the start. What makes it operational is that the same record carries ownership, status and the decision trail through to closure. This is how it runs in Venta Capture, and the shape is the same whatever tool you use.
Arrival
The submission lands in a shared inbox as one case with a reference number in your own format (prefix, digits, optional year) and a separate "your reference" field for the ticket or asset number your other systems already use. The person who sent it gets the same reference on their thank-you page. No hunting for the thread.
Review
The reviewer opens the case and sees the video and photos with counts, the answer to each question, the transcript, and the customer's details. From there the decision is one of four:
- Approve the case as complete and move it on.
- Ask a question with an internal note, visible only to the team, with author and time.
- Request a retake in one click. A retake request becomes a new case linked to the original, and the submitter is asked why they are recording again, so the reason sits in the file.
- Escalate to a manager with a stated reason, following the escalation path you configured. They approve or reject.
The review and retake page shows the screen; the point is that nothing leaves the case to be decided. Every decision is an event on the record.
Routing
Not every case belongs with the same person. Routing resolves from the form first, then the tenant defaults, so a warranty flow can land with the warranty desk and a no-heat flow with the on-call engineer. A route can carry an SLA in hours. Require-claim means someone has to pick the case up before anyone works it, which ends "I thought you had that one". Notifications fire on new, claim, assign, status and note, immediately or batched, to everyone on the route or to named addresses.
Closing
Statuses are yours to define, with one default and one final. Closing a case sets that final status and leaves the trail intact. Two buttons matter at this point: copy view link, which shares the case with someone who has no login, and copy for CRM, which pastes the case into whatever holds the job. Webhooks and a REST API push the same case into a ticketing or field service system automatically; the workflow automation page covers the rules you can set yourself in the builder and the conditional ones VentaVid sets up around your process.
Venta Capture reports 4 out of 5 issues handled and closed the same day, which is what a review queue looks like when the case arrives complete. The remote diagnostics post goes further into what an engineer can decide from that first review, and where a visit is still the right answer.
What makes a case comparable across jobs and usable as evidence
Two properties separate a structured service case from a well-organised folder, and both come from the same design decision: the organisation fixed the steps.
Comparable
When every no-heat call produces the same nine items in the same order, case 40 looks like case 400. That sounds trivial until you try to do quality work on a folder of photos. With comparable cases you can ask which fault codes precede a repeat visit, which installers' handovers keep coming back with a retake, whether a model's data plate is being photographed wrong (it usually is), and how long the desk takes from arrival to first decision. None of that is possible when each submission is a different shape.
Comparability is also what makes training possible. A new engineer reviewing their first twenty cases sees the same structure each time, and learns what a complete one looks like.
Usable as evidence
Evidence is only as good as what you can say about it. On arrival, a Venta Capture case gets a server receipt time, a SHA-256 fingerprint per file, and a signed seal with a downloadable manifest, so the file being reviewed eight months later can be checked against the file that arrived. The live product page describes it as more than 25 control points per submission: automatic signals, recorded session events and one signed seal. The audit trail records who created the link, when it was opened, when the submission arrived, who claimed it, and every note and status change.
Be precise about what that proves. The timestamp proves when the case was received by the system, not when the fault occurred. The fingerprint proves the file has not changed since receipt, not that what it shows is true. A sealed submission is a strong statement about the chain of custody from capture to case, and a weak statement about what happened before the camera opened. A good case says both parts out loud.
The same restraint applies to the signals. Control points such as a file arriving by upload instead of being recorded in the session, or a device seen on an earlier submission, are flagged green, orange or red for a human to look at. Each one carries its own caveat in the interface, because several legitimate reports from one family phone will trip the same signal as something worth a closer look. Signals, not verdicts. The reviewer decides, and Capture does not diagnose the fault either; it gives the engineer better eyes.
Where the record does have to hold up, in a warranty argument, a contractor dispute, or an insurer's query, that combination is what gets asked for. The proof of work post covers the completion side of the same idea, and the photo evidence standards piece sets out what an inspection record needs across sectors.
How to start with one job type
Do not try to structure everything. Pick the job type that most often ends in a no-fix visit or a "can you send more photos" reply, and build the case for that one.
- Write the list. The five to nine things a reviewer needs before deciding to dispatch. If the list passes twelve, cut it; a flow the customer abandons is worse than a shorter one they finish.
- Put an example photo on every step. The data plate on that model, the display in that state. Participants copy what they see.
- Make the identifiers a scan step. Serial and model typed by a customer are wrong often enough to matter. A scan with a typed fallback is not.
- Add the three questions the desk always asks. Power on? Since when? What changed? Let the answers steer the next step.
- Route it to a named owner with an SLA. A queue nobody owns becomes the inbox again.
- Send it to yourself first. Then to the next customer who says "it doesn't work".
On a free Venta Capture plan a first standard flow is live in about 10 minutes, and the field service page shows the flows other service teams start with. The pre-visit assessment post covers the see-before-you-send step in more depth, and reducing truck rolls puts a number on what each avoided trip is worth.
The case starts with guided video capture and the checklist and questions attached to it; how the same record is used to check work is in field service quality control.
Frequently asked questions
What is a structured service case?
A single record for one service event, built from a guided capture that the customer, operator or technician completes on their own phone. It holds the video per step, photos, equipment identifiers, fault codes, answers, checklist responses and timestamps in a fixed order, ready for the service team to review, route and close.
How is a service case different from a work order?
The case records the issue; the work order is the plan to resolve it. In most field service systems a case is created first and a work order is generated from it once someone decides what to do. A structured service case makes that first record complete enough to decide well.
What should a service case contain?
Enough for a reviewer to decide without calling the customer back: the fault shown on video, the data plate or serial, the fault code or display, what was tried and since when, a short checklist, and the submitter's spoken explanation as text. Add your own reference so it ties to the ticket or asset you already track.
Does the customer need an app to submit a case?
No. A Venta Capture link opens in the phone's browser, with no app and no account, in the customer's language. A desktop visitor is shown a QR code to continue on their phone, because the recording happens on the device in their hand.
Can a technician create a structured service case on site?
Yes. Staff can start a capture themselves without sending a link, which is how teams use it for handovers, completion evidence and counter check-ins. The technician follows the same guided steps, so their case is comparable with the ones customers submit.
What does "sealed" mean on a service case?
On arrival the case receives a server receipt time, a SHA-256 fingerprint per file and a signed seal with a downloadable manifest, so anyone can later check that the file they are looking at is the one that arrived. It proves when the case arrived and that it is unchanged. It does not prove when the fault happened.
How does a structured service case get into our FSM or CRM?
Three ways, in increasing order of effort: copy for CRM pastes the case into the record you already have, a view link shares it with anyone without a login, and webhooks or the REST API push each case into your ticketing or field service system as it arrives. Custom routing and integrations are set up by VentaVid around your process.
Get one real case into your inbox this week
Pick the ticket type that costs you the most repeat visits, write the list of what a reviewer needs, and send the link to your own phone. A structured service case is easier to recognise than to describe: once you have opened one, the pile in the inbox looks like what it is.
What it takes to start.
- Free plan, no credit card. Build the flow, test it on yourself, then send it to the next "unit not working" ticket.
- Live in 10 minutes for a first standard flow. Stuck? Book a free setup call and we build it together.
- Everything goes out in your own branding, in the participant's language, with no app to install.
The VentaVid team builds Venta Capture and runs the free setup call on your own job types.
Start for free and build the first case flow this afternoon. If you would rather see it against your own tickets first, book a demo and bring the messiest one. The Venta Capture product page has the full feature list.