A message is not a job. This is what turns one into the other.
A service request holds what you are actually being asked to do: the service, the address, the machine, the answers that have to exist before anyone can be sent. Ven collects them; your operator corrects anything it got wrong, and can see why it thought so.
Boiler service · 90 min
M. Berger · WhatsApp
Service address
Lindenstr. 14, 10969 Berlin
Equipment
Vaillant ecoTEC plus
Last service
Question sent
Access
Not known yet
Next question: parking and key handover
Service 0.94
Not setBoiler service
Urgency 0.81
NormalThis week
Next action 0.90
—Ask about access
The operational state a conversation never had.
A shared inbox tells you a customer wrote. It does not tell you whether you know their address, whether the boiler model is the one you carry parts for, or whether anyone has asked how the technician gets in. Those are the facts a dispatcher hunts for by scrolling, and they are exactly what a service request holds instead.
It is a record with a state machine, a version and an owner — not a tag on a ticket. Requests are created idempotently from an inbound message, so a customer who follows up on a second channel adds to one request rather than opening another.
Everything the next person needs, in the order they need it
Answers that carry their own evidence
Every field records where it came from — which message, which photo — and how confident the model was. Correcting one is a normal edit with an audit entry, not a fight with a chatbot.
Boiler service · 90 min
M. Berger · WhatsApp
Service address
Lindenstr. 14, 10969 Berlin
Equipment
Vaillant ecoTEC plus
Last service
Question sent
Access
Not known yet
Next question: parking and key handover
You decide what complete means
Each service carries its own required questions. Readiness is checked against that template, so a request is never “ready” because the model felt it was.
Boiler service
Must be answered before booking
- Service address
- Boiler make and model
- Date of the last service
- How the technician gets in
One request per job
Follow-ups on other channels join the request instead of starting a second one.
Address and equipment reused
Properties and assets live on the customer, so returning work starts half-filled.
Attachments become evidence
A photo of a rating plate is linked to the request and the equipment it identifies.
Every change is attributable
Who set a field, on the strength of which message, and when — for as long as you keep it.
From an unclear message to something you can dispatch
The steps are the same ones your dispatcher already does. What changes is that the typing, the chasing and the checking are no longer theirs.
- 01
The request is created
An inbound message on any channel opens exactly one request, linked to the conversation and the customer it came from.
- 02
Ven fills what it can and asks for the rest
It extracts what the customer already said, marks what is missing, and asks the next approved question rather than all of them at once.
- 03
A person confirms or corrects
Your operator reviews the proposal field by field. Accepted changes apply atomically against the version they reviewed, so a stale write cannot land.
The AI is a fast first draft, not the record.
Software that treats a model's output as truth makes every mistake permanent and every correction a workaround. Here the request is the record and the proposal is an input to it — which is why an operator can disagree with Ven in two clicks, and why the disagreement is itself logged.
A state you can act on
New, qualifying, ready, held, booked — with the missing fields named at each step.
A boundary the model cannot cross
Ven proposes structured changes; policy and schema decide whether they apply.
A history that answers questions
What was known when, who changed it, and which message it came from.
Stop reading conversations to find out what the job is
Start free, in Observe mode — watch Ven build requests from real messages before it touches one.