Bookings in every format except the one you need
By half ten the bookings inbox has a builders' merchant's spreadsheet with fourteen rows and different column names from last week, three emails that each say 'one pallet to the usual place', a PDF delivery note, and a phone photo of a whiteboard.
Each one has to be read, understood and typed into the network portal: consignee, address, postcode, pallet size, weight, service, any tail lift or booking-in note. Questions go back to the customer by email. By the afternoon the collection runs are being planned from half-entered bookings.
Why customers will not use your portal
You have offered them the network portal or your own booking screen. Some use it. Many do not, for reasons that make sense to them.
- Their own system produces a spreadsheet, and copying it into a web form is tedious.
- The person booking changes, and nobody remembers the login.
- They book so rarely that learning a screen is not worth it.
- They are a valued account, so you do not want to insist.
So the work lands on your office, and it arrives in whatever shape the customer happens to use.
What retyping bookings costs
Typing errors in postcodes and weights turn into misrouted pallets and re-weigh charges later. Vague bookings cause back-and-forth that delays collection planning. And the office is doing data entry during the hours it should be answering the phone.
Late bookings also squeeze the rest of the day. Collection drivers are sent out on runs that change after they leave, the trunk manifest is built from bookings that were keyed in a hurry, and anything left over at the end of the day becomes tomorrow's problem. The customers who send the messiest bookings are often the biggest, so the problem grows as the depot does.
How we read and check incoming bookings
- We connect to the bookings inbox in Microsoft 365 or Google Workspace.
- Each email, spreadsheet, PDF or photo is read, and consignments are extracted using a language model such as OpenAI or Anthropic Claude, guided by rules for each regular customer.
- Postcodes are checked against a postcode lookup, weights against the size band, and 'the usual place' against the customer's saved addresses.
- Clean bookings go into an approval queue with the original message beside them. Anything uncertain is highlighted, not guessed.
- Approved bookings are sent to the network portal through its import or API where available, and to your own system.
- Customers get an automatic acknowledgement listing what was booked, so errors are spotted by them early.
| Incoming format | What we extract | Typical check |
|---|---|---|
| Customer spreadsheet | Rows of consignments | Column mapping per customer |
| Plain email | One or two consignments | Saved address match |
| PDF delivery note | Consignee and goods | Postcode and weight |
| Photo of a list | Handwritten lines | Always sent to a person |
A person approves every booking before it reaches the network. The system does the reading and checking, not the deciding.
The bookings inbox afterwards
By mid-morning the queue shows the day's bookings, already read and checked, with the doubtful ones marked. Your staff spend their time on the few that need a phone call rather than typing the many that do not.
Customers carry on booking the way they like, which is the point.
Recognise your inbox?
- Most bookings arrive by email rather than the portal.
- Customer spreadsheets change layout often.
- Postcode and weight typos cause problems later.
- Collection planning waits for bookings to be keyed.
- Customers never get a confirmation of what was booked.