The short version for the desk.
- What it is: a service checklist with video puts the questions your engineers would ask in front of the person standing at the equipment, at the moment they record the fault, so the answers arrive attached to the footage instead of in a separate email.
- Why it matters: the desk decides who goes, with what, and whether anyone goes at all. Four closed questions and one guided video change that decision more than a page of free text.
- The rule: require only what changes a dispatch decision. Everything else is optional, and one open question at the end catches the rest.
- Who it's for: service managers, dispatch and planning leads, and service desk leads at equipment manufacturers, dealers, installers, maintenance providers, facilities and utility operators.
"No heat." Two words on a work order, and a planner now has to pick a skill, guess at parts and block out a slot.
The desk did ask the right questions on the phone. When did it start, is there a code on the display, has anyone reset it, can we get to the unit. The customer answered from memory, the answers went into a call note, and the engineer who arrives on Thursday will ask all four again because nobody reads call notes standing in a plant room.
I've built a lot of capture flows for service teams, and one question does more work than any other: "what have you already tried". It only works as a closed list with an "other" option. As a text box it comes back empty, or it comes back as "everything".
That is the whole design problem in one line. The questions are known. What's missing is asking them at the right moment, in the right shape, and keeping the answers next to the evidence.
If you run a service desk or a dispatch board and your engineers keep arriving to find out what the ticket should have told them, this post is about the checklist that fixes the intake, not the one the technician fills in on site. Venta Capture, a product of VentaVid, is the guided capture layer we build for it: the customer records the fault on their own phone, answers your questions as they go, and the whole thing lands as one case. Start for free and build the checklist for the fault type you dispatch most.
What a service checklist with video actually is
Search the term and you get the technician's checklist: the list a field engineer ticks on site inside a field-service app. Useful, but it happens after the van has left. The service checklist in this post is answered before that, by the person who is already at the equipment.
A service checklist with video is a short set of structured questions the customer or site contact answers while recording the fault, so the answers and the footage arrive as one case. The organisation decides what gets asked, in what order, and which steps are required. That is what guided capture means in practice.
The difference from the technician's version is not the questions. It's who answers, when, and where the answers end up.
Field-service platforms are built for the first column. The Microsoft Learn documentation for Dynamics 365 Field Service inspections, for example, lists textbox, checkbox, dropdown, number, date, barcode scan and file upload question types with a Required toggle, and every one of them is filled in by the technician on the mobile app (Microsoft Learn). The customer is not a user.
That gap is where the second column lives. It is the intake half of a pre-visit assessment: the questions plus the guided video, captured together, reviewed together.
The four questions that change the dispatch
Kiolo's field service visit checklist makes a point most intake forms miss: agree in advance "what would make the visit unsuccessful even if some work is completed", and it puts access failures at the top of that list (Kiolo). A good checklist works backwards from that. Every required question exists to prevent one specific failed visit.
A required question earns its place only if a wrong answer would change who you send, what they bring, or whether anyone goes at all. Four questions pass that test for almost every equipment type.
1. When did it start, and what changed?
Not a date picker. A dropdown of windows (today, this week, longer than a week, it's intermittent) and a second single-choice question: anything changed just before (power cut, new installation, moved, serviced, nothing).
This one decides urgency and often the likely cause. A fault that began right after a power cut gets a different brief from one that has been intermittent for a month.
2. What does the display or indicator show?
A closed list of what the customer can see: a code, a flashing light, a blank screen, a warning message, nothing unusual. Attach a video step right after it with one instruction on screen: "Film the display for ten seconds."
The answer tells the desk which manual to open. The footage tells them whether the answer is right.
3. What have you already tried?
The closed list: switched it off and on, reset at the panel, checked the power or supply, checked the fuse or breaker, nothing yet, other. Multi-select, with "other" opening a short text field.
"Have you tried turning it off and on" gets a yes on the phone and a no on site. Asked as a list the customer taps while looking at the machine, it gets the real answer, and the engineer stops repeating steps the customer has done.
4. Can our engineer reach it?
Yes/no questions, each steering the next: is the unit accessible without a key holder, can it be isolated or switched off during the visit, is it above head height or in a confined space, is the site running when we'd arrive. Kiolo's phrasing is blunt and correct: "Access failures waste visits even when the technical preparation is perfect."
This is the question most often skipped on the phone and most often behind a wasted truck roll. Fieldcode's write-up on why scheduling problems start before dispatch lists the same gaps: dispatchers "clarifying requests, reviewing notes, contacting customers, and correcting ticket information" because the intake didn't ask (Fieldcode).
The numbers behind this are not small. Aquant's 2026 Field Service Benchmark puts the first-time fix rate at 77% for the median organisation, 88% for top performers and 60% at the bottom, and it puts the cost of failed visits at 25% of total service cost for the median company (Aquant). Four questions asked at the right moment attack exactly that 25%.
If you want to see what those four look like as a flow your customers actually complete, book a demo and bring your most-dispatched fault type.
Closed or open: how to word each question
The research on question design is clear, and it favours the shape most service desks avoid. Closed questions are faster to answer and get completed more often; NN/g's guidance is that "a survey with many open-ended questions will usually have a lower completion rate than one with more closed questions" (Nielsen Norman Group). In a split-ballot experiment on a large web survey, Reja and colleagues found open-ended questions produced more missing data than close-ended ones in a self-administered setting (Reja et al., 2003).
A person standing at a broken machine with their phone out is the definition of self-administered. Default to closed questions for anything the desk will filter, route or brief on, and let the video do the open-ended work.
NN/g describes the funnel technique: broad open question first, then closed clarifiers. For a service intake, run it in reverse. Closed clarifiers up front while the customer is looking at the fault, then one open beat at the end.
- Closed is right for: the four dispatch questions, equipment identification, anything you'll count or filter on, anything that steers a later step.
- Open is right for: the sequence of events on an intermittent fault, "anything else the engineer should know", and the spoken explanation during the video.
- Spoken beats typed: the video step's instruction can simply say "describe what happens, out loud". The transcription turns that into searchable text in the case, so the open question costs the customer nothing to type.
Three wording rules stop a good question set from failing on the phone screen:
- Use the customer's words, not the engineer's. "The light on the front panel" rather than "the fault LED". "The big grey box outside" rather than "the condenser unit".
- One thing per question. "Is there a code on the display and is the fan running" is two questions and gets one answer.
- "I don't know" is always an option. A forced guess is worse than a known gap, and the desk can ask for a retake on the one thing that's missing.
Required or optional: the test for every step
Required means the customer cannot submit without it. That is a strong lever, so use it on few things.
The Dynamics 365 documentation describes the same mechanism on the technician side, where a required inspection question blocks the task from being marked complete (Microsoft Learn). A customer-side checklist uses that lever earlier, at intake, where it prevents the wasted visit rather than recording it.
Run every step through one question: if the answer here were wrong, would we send someone different, bring something different, or not go at all? If yes, require it. If no, make it optional and let the customer skip it without penalty.
Require by default:
- The four dispatch questions above.
- One video of the fault with a single instruction on screen, such as "walk around the unit and film the display, then the area around it".
- Which equipment it is, as a single-choice list if you service more than one type, or a scan of the serial label if that drives parts.
- A contact and a site, asked at the end, not up front, so the customer has already invested a minute before they type their details.
Leave optional by default:
- Extra photos of the model plate, the surrounding area, the supply, unless one of them changes the parts you bring.
- Model or serial typed by hand when a photo of the label does the same job.
- How long they've had the equipment and other history the engineer would like but the desk won't act on.
- The free-text "anything else" at the end. Keep it, never require it.
A missing optional answer is not a dead end. The reviewer sends a retake request for that one item, and the customer is asked why they're recording again, so the case keeps the reason. That is cheaper than a second visit and much cheaper than a required field that made the first submission fail.
Question sets by equipment type
The four core questions are universal. Each equipment type then adds three to five items, and the video instruction changes so the customer films the thing your engineer would look at first.
Two boundaries keep this table honest.
An installation checklist uses the same structure from the other direction: site, access, existing equipment and supply captured before the install so the crew arrives with the right kit. Same four questions, different subject.
An inspection checklist is a different thing altogether. That is a compliance record (fire doors, lifting equipment, scaffold) where the question set is set by a regulation and the record has to stand up in an audit. This post is about service intake, and the two shouldn't share a form.
On building them: standard flows come ready-made in Venta Capture and your team adjusts the steps, slots and questions in the builder. The moment a question needs to steer the path ("if the display shows a code, ask which code and skip the reset step"), that is a branching flow, and we set it up around your process rather than leaving you to assemble it. The guided video capture and workflow automation pages cover what each part does.
How the desk reviews answers and video together
Most of the value leaks at review, not at capture. The answers sit in one tab and the video plays in another, and the reviewer reads the answers, skims the footage, and never checks one against the other.
"Error E4 on the display" is worth very little until someone pauses the video on the display and confirms it says E4. The whole point of collecting answers and footage in one case is that the desk can do that check in seconds.
A review that takes under three minutes, in order:
- Read the four required answers first. Twenty seconds. You now know when, what it shows, what's been tried, and whether the engineer can reach it.
- Play the video against the answers. Pause on the display and compare it to answer two. Watch whether the "reset at the panel" the customer ticked was the right panel.
- Read the transcript for what the closed questions missed. The spoken explanation is where "it only does it when the second pump kicks in" turns up.
- Decide. Resolve it remotely with an instruction back to the customer, dispatch with a brief, or send a retake request that names the one thing you still need to see.
- Write the one-line brief. Skill, likely part, access note, and the view link to the case so the engineer opens the footage in the van instead of asking the four questions again.
In Venta Capture every submission is a case with your own reference number, the answers listed per question, the video and photos, the transcript, and the timeline of who opened, claimed and commented on it. Reviewers assign or claim, leave internal notes, set a status, and copy a view link for a colleague who has no login. The review and retake page walks through it.
Run this way the intake stops being a queue of descriptions and becomes triage. With Venta Capture, support and field service teams handle and close 4 out of 5 issues the same day, and Aquant's benchmark puts the remotely resolvable share at 1 in 5 cases (Aquant). That is the share your desk can take off the dispatch board without a van.
The same pattern runs after the visit. A completion checklist with video (what was replaced, is it running, film the repaired area) gives you proof of work in the same case as the intake, which the post on proof of work in field service covers in detail. The field service page shows both halves side by side.
Where a checklist doesn't help
Some faults can't be shown. An intermittent electrical fault inside a sealed unit, a noise that only happens at 3 a.m., a safety-critical site where the customer must not open a panel. The checklist still captures when, what's been tried and whether the site is accessible, and the desk dispatches better informed, but the diagnosis stays with the engineer.
Some customers won't do it. Your fallback is the process you run today, so the worst case is your current baseline.
And the checklist never decides. Venta Capture gives the person with the expertise better visual access; the judgement about what to send stays with them. Remote-first, not remote-only, which is also the theme of the post on reducing truck rolls and the one on remote diagnostics in field service.
The questions sit inside a guided video capture, and the whole submission lands as one structured service case.
Frequently asked questions
What is a service checklist with video?
It is a short set of structured questions the customer or site contact answers while recording a guided video of the fault on their own phone. The answers and the footage arrive together as one case, so the desk can decide who to send, with what, or whether to send anyone, before the visit is booked.
Will customers actually complete a checklist?
Yes, when it is six to ten closed questions asked at the moment they are already recording, not a form emailed afterwards. Closed questions complete at a higher rate than open ones, and there is nothing to install or sign up for, so the friction is the questions themselves. Keep them short and it holds.
How many questions should a service checklist have?
Four required dispatch questions, one required video, and three to five equipment-specific items, most of them optional. If you are past twelve, something on the list would not change a dispatch decision and should be optional or cut.
Should the questions be closed or open?
Closed for anything the desk will filter, route or brief on: timing, display, what's been tried, access, equipment type. Open for the spoken explanation during the video and one "anything else" at the end. Research on self-administered questionnaires shows open questions produce more missing data, so use them where a gap costs nothing.
Can the checklist branch depending on the answer?
Yes. A yes/no or single-choice answer can steer which step comes next, so a customer who reports a code is asked which one and skips the steps that don't apply. Standard flows are yours to adjust in the builder; branching flows are set up by the VentaVid team around your process.
Is this the same as an inspection checklist?
No. An inspection checklist is a compliance record whose questions are set by a regulation (fire doors, lifting equipment) and has to stand up in an audit, while a service checklist with video is an intake tool for triage and dispatch. Keep them as separate flows.
Does the customer need an app or an account?
No. The secure, personal capture link opens in the phone's browser, the flow runs in the customer's own language, and the submission is sealed on receipt with a server-side timestamp. Prices are not published; there is a free plan with no credit card required.
Talk to us
If your dispatch board still runs on four-word tickets, build one checklist first. Pick the fault type you dispatch most, put the four questions and one video step in front of the next twenty customers who report it, and count how many engineers arrived already knowing what the customer had tried.
What it takes to start.
- Free plan, no credit card, and you can be live in 10 minutes.
- Nothing for your customers to install: the link opens in the browser they already have.
- Stuck? Book a free setup call and we build your first flow together.
Venta Capture is built by the VentaVid team, who have spent years putting video into sales and service workflows for teams in 43 countries.
Start for free and build your first service checklist today, or book a demo and we'll design the question set for your top fault type with you.