The dispatch manager pasted a customer's complaint into a chatbot, got back a polite reply in perfect English, and sent it. The reply promised delivery by evening. The truck had broken down near Behror two hours earlier. The chatbot had no way of knowing that, and it did not say so.
That small failure explains the whole debate. A chatbot produces words about your work; an agent reads and changes your records, so the real question is not how clever it is but what it may read, what it may draft, and what it must never do alone.
A chatbot answers from text, an agent acts on records
A general chatbot is trained on public text and answers from patterns in that text. It is useful for drafting an email, summarising a long circular or explaining a GST rule in plain words. It does not know where your trucks are, what a customer owes or which e-way bill expires tonight.
An agent is connected to your systems. It can look up a vehicle, read an LR's status, propose a Part-B update or prepare a bill. That makes it far more useful, and also far more dangerous if nobody has decided its limits. A chatbot's worst mistake is a wrong sentence. An agent's worst mistake is a wrong entry.
Reading is the safe first job, if access is checked first
Most of an operations office's messages are read questions. Where is the truck. Has the POD come in. What does this customer owe. Is this e-way bill still valid. An agent that answers these from the records saves hours of phone calls, and the risk is low as long as one rule holds: access is checked before the answer, not after.
A driver should not see customer rates. A customer should see their own LRs and nobody else's. So the agent must know who is writing, from your own user, driver and contact masters, and what that role may see, before it reads anything. Our guide on AI agents for transport companies lists the jobs where reading alone pays off.
Drafting is where the hours are saved
The second tier is drafting. The agent prepares the next record from the one before, and a person reviews it. An LR with a vehicle becomes a trip-start draft. Delivered LRs with POD become a bill draft. A finished trip becomes a settlement draft. Nobody retypes, and nobody loses control.
The useful design is a switch per task with three positions: Off, Draft or Auto. Every task starts in Off or Draft. It moves to Auto only after the team has watched it be right for long enough to trust it, and only for tasks where a mistake is cheap to reverse.
An illustrative day of messages
Here is a made-up example. Say a transport office of four people handles 120 WhatsApp messages a day.
| Message type | Count | Minutes each by hand | Handled by the agent | Minutes saved |
|---|---|---|---|---|
| Read questions (status, POD, dues) | 70 | 2 | Answered from records | 70 × 2 = 140 |
| Instructions (advance, status update) | 30 | 3 | Drafted, person confirms in 0.5 | 30 × 2.5 = 75 |
| Disputes, negotiations, odd cases | 20 | 6 | Passed to a person | 0 |
| Total | 120 | 215 minutes |
That is about three and a half hours a day returned to a four-person office, without the agent deciding anything that matters. Notice the last row. The twenty hardest messages still go to people, and that is by design. Your own mix will differ, so count a real week before you believe any figure, including ours.
A chatbot's worst mistake is a wrong sentence. An agent's worst mistake is a wrong entry in your books.
Some actions must always wait for a person
Write the "never alone" list before switching anything on. Ours for an operations team looks like this:
- Money: no advance, payment or refund above a set threshold without a named person confirming, with a PIN.
- Rates and terms: no change to a freight rate, credit limit or contract term.
- Access: no granting or widening of who may see what.
- Promises: no delivery commitment the records do not support.
- Irreversible steps: no cancellation or deletion without confirmation.
The list is short on purpose. Short lists get enforced.
A language model should classify, not calculate
The safest agents use the language model for one narrow job: understanding what the message is asking. "HR55 kahan hai", "where is my truck" and "gaadi ka status batao" are the same request. The model recognises that. The answer, the location, the ETA and the amount owed, comes from the database, never from the model.
This matters because language models are fluent even when wrong. If the model is allowed to produce numbers, it will one day produce a confident, plausible and false one. If it only classifies, the worst case is a misunderstood question, which a confirmation step catches.
The case for a plain chatbot
There is a fair argument for keeping it simple. A general chatbot costs little, needs no integration and cannot damage your records because it cannot reach them. Staff already use one for drafting emails. An agent with access checks and confirmations is slower to set up and adds a step to every write.
We accept all of that. For writing, summarising and explaining, a chatbot is fine. But it cannot answer "where is the truck" honestly, and the office still has to make those forty calls a day. The confirmation step is not friction. It is the point at which a person stays responsible. Judge any agent by its audit trail: every message, who sent it, what was read, what was changed and who confirmed it.
What to do this week
- Export one week of your office's WhatsApp messages and sort them into read, instruction and judgement.
- Write your "never alone" list in five lines and get the owner to sign it.
- Pick one drafting task, such as bills from delivered LRs, to try in Draft mode first.
- Decide the money threshold above which a PIN is required.
The WhatsApp assistant in SCM for Transporter runs those checks on every message: identity, intent, access, action and confirm. The SCM for Transporter guides cover the rest of the desk. Start with reading, earn the right to draft, and keep the last word with a person.