A morning of messages
By eight the controller has an inbox of booking emails, some with details in the body and some in an attached spreadsheet. The office WhatsApp has five messages from regular customers: 'usual pick up, 2 boxes to the Manchester site today pls'. A text from a builder with a photo of a delivery note. The phone rings with a new booking every few minutes.
Each message becomes a job typed into the system. Addresses are copied, postcodes are guessed, the customer's reference is left out. When the driver arrives at 'the Manchester site', it turns out the customer has two.
Why customers do not use the portal
Booking portals ask for a lot of fields, and a regular customer sending the same kind of job every day finds it quicker to send a message. They know you know where 'the usual' is. Your system does not.
| Booking channel | Why it causes rework |
|---|---|
| Email body | Free text, details scattered |
| Email attachment | Spreadsheet or PDF in the customer's own layout |
| WhatsApp or text | Short, relies on shared understanding |
| Photo of a delivery note | Needs reading and typing |
| Phone call | Written on a pad, then typed |
Forcing customers onto the portal risks losing the ones who value how easy you are to deal with.
What retyping costs
Controller time that should go on planning. Mistakes that send drivers to the wrong site or without the right reference. Bookings missed because a message was read and forgotten. And slower confirmations, which matter for same-day work where the customer is waiting to know if you can do it.
Missing references cause invoicing problems at month end too.
Messages also live on individual phones. When the office WhatsApp is on one controller's handset and that controller is off, bookings sit unread, or get answered from memory by someone who does not know that 'the usual' for this customer changed last week.
And there is no record of what was asked for. If a driver collects two boxes and the customer says they booked three, the evidence is somewhere in a chat history, if nobody has cleared it.
The intake we build
- Connections to your booking channels: a bookings email address, a WhatsApp Business number through its official API, SMS through Twilio or similar.
- Extraction from message text, attachments and photos of delivery notes: collection and delivery addresses, times, goods, quantity, weight, customer reference.
- Customer memory: 'the usual' and 'the Manchester site' resolved from the customer's saved addresses and past jobs, with the match shown.
- Validation: postcodes checked, times feasible, required references present for that customer.
- A reply to the customer asking for anything missing, in the same channel.
- A draft job in your courier software or dispatch board, confirmed by a controller with one action, and a confirmation sent to the customer.
Extraction uses a language model such as OpenAI or Anthropic Claude, with its output checked against your data. Nothing becomes a job without a controller confirming it.
What controllers get
Bookings from every channel in one list, already structured. Missing details chased automatically. Customers keep booking the way they like. Controllers confirm rather than type, and have time for the jobs that need their judgement.
Signs you need this
- Controllers retype bookings from emails and messages.
- Regular customers book by WhatsApp or text.
- Drivers are sent to the wrong site of a multi-site customer.
- Booking references are often missing at invoicing.
- Some bookings are missed in a busy inbox.