“A yellow light came on this morning. I don’t know what it’s called.”
The service adviser now asks the familiar sequence: which car, which light, when did it start, does the vehicle feel different, can you send a photo, when can you come in? Half the answers end up in free text and the workshop calls back anyway.
Multimodal AI can improve this flow, but only if the job is defined correctly.
The useful role is not “diagnose the vehicle from a phone”. It is collect the customer’s observable evidence and turn it into a structured ticket that a workshop professional can review.
The first goal is a complete request, not an AI diagnosis
Modern systems can work across voice, text and images. That capability does not make a single customer photo equivalent to a workshop inspection.
A warning symbol can be blurred or overexposed. Similar icons can be confused. The meaning can depend on vehicle, state and other symptoms. A body-damage photo cannot show hidden structural damage. An audio clip of a noise does not reproduce load, temperature or driving conditions.
So the pilot rule should be explicit:
AI records and structures observations. A mechanic decides urgency, diagnosis and repair.
current realtime and multimodal AI products can combine conversational and visual information in a workflow. Vendor examples demonstrate capability, not a measured productivity outcome for Swiss garages.
Author recommendation: label the result “pre-intake” or “triage ticket”, never “AI diagnosis”, unless a separately validated regulated product and process genuinely supports such a claim.
Seven fields make a surprisingly useful garage ticket
A first version can stay simple.
- Contact: name, phone number and preferred callback channel.
- Vehicle: make/model and the minimum identifier the workshop actually needs.
- Observation: what does the customer see, hear or feel?
- Media: photo or short video of the visible indicator or damage.
- Timing: when did it start; sudden or gradual?
- Current state: vehicle moving/stationary and any pre-defined urgency signal.
- Desired next step: callback, appointment, estimate review or general question.
The assistant can ask only for missing fields. If the customer already sent a clear dashboard photo, the system should not repeat five questions that the image answers. If the image is ambiguous, it should record that ambiguity.
The output is a work-preparation artifact. It is not a repair order and not a final technical conclusion.
“Unable to assess” must be a first-class status
Image-capable models can sound especially confident. That is why the workflow needs a state that does not force the system to classify every picture.
Suppose a customer sends an overexposed photo of a warning lamp. A weak system guesses the icon from the vehicle model. A better system says the image is insufficient, asks once for a clearer photo and then routes the case to staff if the uncertainty remains.
Contradictions should also be preserved. If the customer says “the car drives normally” and later says “it has lost most of its power”, the summary should flag both statements rather than silently reconcile them.
For safety-related questions, use business-approved rules and a conservative handoff boundary. The AI should not invent driving clearance or reassurance.
This is the same operational principle as good human intake: collect what you know, mark what you do not know, and avoid pretending the initial contact is a full diagnosis.
Photos and voice notes also create a data workflow
A damage photo may contain more than the vehicle: people in the background, another licence plate, a home address or documents visible through a window. A voice note contains personal information. Vehicle/customer identifiers can be sensitive in combination.
The Swiss FDPIC emphasises transparency when personal data is collected. In practical terms, the customer should understand why the garage wants the photo or voice message and where to find the relevant privacy information.
Collect only what the process needs. If a full VIN is unnecessary for initial callback triage, do not request it merely because the form can. If an image has no purpose after the case is closed, define an appropriate retention rule.
The exact legal setup depends on your processors, storage, systems and use case. A generic chatbot design does not replace that review.
Human handoff should look like a workshop ticket, not a chat dump
Do not make the mechanic read a twelve-message conversation.
A useful summary might say: “VW Golf; customer reports yellow warning lamp since this morning; photo attached, symbol not confidently identifiable; customer says vehicle remains driveable; no technical advice issued; callback requested this afternoon.”
Separate three layers in the ticket:
- customer statement;
- observable media fact;
- system uncertainty / missing field.
Avoid turning model inference into a fact. If the system suspects a specific fault but the workshop has not validated that inference, it should not quietly appear in the “problem” field as if the customer reported it.
The staff member can then decide whether to call, book, request another photo or ask the customer to follow an approved safety path.
Minimum pilot: one request category only
Choose one narrow intake type, such as dashboard warning lights or visible body damage for callback preparation.
Build 30–50 test cases. Include clean photos, dark images, reflections, wrong angle, Swiss German voice notes, missing vehicle details, two issues in one message, contradictory descriptions and a safety-related scenario.
Track tickets complete on first intake, average missing required fields, ambiguous images correctly marked ambiguous, time to human ownership, unapproved diagnostic statements generated, and cases requiring an extra callback solely because basic intake information was missing.
Do not optimise for “AI resolved the case”. The success condition is that staff receive better evidence with less ambiguity and no false technical promise.
The practical conclusion: customers often show a vehicle problem more easily than they can name it. Multimodal AI is well suited to organising that messy input. Keep it in that role. Let the workshop professional own diagnosis, urgency and repair decisions.
Our garage AI workflow combines structured intake and callback. Immediate danger also needs a conservative emergency boundary.
Sources
- OpenAI — Introducing GPT-Live
- OpenAI — avatarin real-time agent
- Swiss FDPIC — Duty to provide information
- NIST — Generative AI Profile
FAQ
Can AI diagnose a dashboard warning light from a photo?
It can process the image, but one photo is not a reliable vehicle diagnosis. Use it as intake evidence and have a qualified person decide what it means operationally.
Should the garage request the VIN immediately?
Only if it is needed for that stage. Ask for the minimum information that supports the next action.
What if the photo is poor?
Ask once for a clearer image. If the issue remains uncertain, hand the ticket to staff rather than guessing.
Can the assistant tell the customer it is safe to keep driving?
Only within business-approved, professionally reviewed rules. Open-ended model advice should not be the default for safety decisions.
How long should photos be kept?
Set retention based on the business purpose and privacy requirements. Avoid indefinite storage with no defined reason.