Taxi Business Automation: AI Booking Confirmations and Receipts

Keep every booking in one structured record, let AI read messy requests into its fields and draft the wording, and let templates and formulas send the confirmation text, the driver job card and the receipt. AI handles language; your system handles times, fares and licence records. Nothing is sent until the required fields are complete.

Lists of dispatch software are easy to find, and many dispatch systems already send a basic confirmation and a trip receipt, so check what yours does before you build anything. The gaps are usually messy requests arriving on WhatsApp or email, wording you cannot change, and receipts for trips someone remembers a week later. One caution runs through everything below: keep the original request, because licence conditions are written around booking records, not around tidy AI output.

Follow me on Instagram@sagnikteaches

Build one booking record before you automate any message

Every message in this tutorial is read off a single record. When a confirmation says 05:30 and the driver's job says 05:00, the cause is nearly always two copies of the booking that drifted apart. Start with a sheet, or the export from your dispatch system, with one row per booking. The last column is a prompt to check your own licence conditions: published operator conditions commonly ask for items such as the passenger's name, when the booking was received, the pick-up point and requested time, and the driver and vehicle allocated.

Connect on LinkedInSagnik Bhattacharya

Two columns carry more weight than their size suggests. "Source text" holds the customer's original words, pasted untouched and never edited. "Status" moves through received, confirmed, assigned, completed and changed, and every automation checks it before firing. That check is how you stop one customer receiving the same confirmation three times after a dispatcher fixes a typo.

Subscribe on YouTube@sagnikteaches

Where AI reads and writes, and where a formula must do the work

Give AI the jobs that are about language. Give formulas and rules everything about numbers, clocks and permission. The split is short enough to pin above the dispatcher's desk.

• AI reads and drafts: pulling fields out of a WhatsApp message, an email or a voicemail transcript; noticing what is missing or does not fit, such as no terminal, or a pick-up time that is too late for the flight; choosing the right template variant for an exception (child seat, wheelchair-accessible vehicle, return journey, account customer) and writing the one extra sentence; sorting incoming mail into receipt request, lost property, change or complaint.
• Formulas and rules do: fares, extras, tips and totals (AI is unreliable at arithmetic, so never ask it to add up a receipt); storing dates and times; pulling the plate and driver from your own tables; deciding whether to send, which is a status check and never the AI's opinion.
• A person does: works the review queue, and answers anything that is a complaint, a change of plan or a safety issue.

The principle behind the split is that standard bookings use a fixed template with no AI call at all, and AI is called only for free-text requests and exceptions. A template cannot invent a promise, costs nothing per message beyond the text itself, and behaves the same on the busiest Friday as on a quiet Tuesday.

Turning a WhatsApp request into a booking record

Most of the retyping in a small firm comes from requests that arrive as free text. This prompt turns one into fields. Notice that it asks for a null rather than a guess, gives the model the time the message arrived so that "tomorrow" resolves correctly, and leaves out the contact number, because the automation can copy that from the WhatsApp profile without any help from a model.

You turn a customer message into a booking record for a taxi firm.
The message arrived on Tue 13 Oct 2026 at 21:42, local time.

Rules:
- Use only what the message says. If something is not stated, write null.
  Never guess an address, a time or a flight number.
- Write dates as YYYY-MM-DD and times as 24-hour HH:MM. If a time could be
  morning or evening, still give your best reading and add a question to needs_check.
- Return only JSON with these keys: pickup_date, pickup_time, pickup_address,
  dropoff_address, passengers, luggage_notes, flight_or_train, special_needs,
  needs_check (a list of short questions for the dispatcher).

Message:
"""
hi can u do airport tmrw 5.30 from 14 Ash Road, 3 of us + 2 big cases. flight AB456 8.15 cheers
"""

A realistic reply, shown here as an illustration of what comes back, looks like this.

{
  "pickup_date": "2026-10-14",
  "pickup_time": "05:30",
  "pickup_address": "14 Ash Road",
  "dropoff_address": "airport, terminal not stated",
  "passengers": 3,
  "luggage_notes": "2 big cases",
  "flight_or_train": "AB456, 08:15",
  "special_needs": null,
  "needs_check": [
    "Which terminal?",
    "Confirm 05:30 is the morning pick-up, not 17:30",
    "Is 08:15 the departure time or the landing time?"
  ]
}

Three things in that output still need a human or a rule, and they are typical. First, the AI has done its job by flagging the ambiguity, but the dispatcher has to settle it with one reply to the customer. Second, "2 big cases" plus three passengers may not fit a saloon. Put that rule in the sheet as a formula that reads the passenger and large-case numbers, rather than trusting a prompt to remember vehicle sizes. Third, "14 Ash Road" has no town or area, and the model cannot tell you whether the address exists. An address lookup in your dispatch or mapping tool, or the dispatcher's own knowledge of the area, does that check.

Before anything is written to the booking sheet, run plain validation rules that have nothing to do with AI: the date falls within the next 90 days, the time is a valid HH:MM, passengers is a whole number, the pick-up is not empty. A record that fails any rule, or arrives with a non-empty needs_check list, goes to the review queue instead of the sheet. When a customer forwards a flight confirmation, have the same prompt read the flight number and scheduled time from it and flag any mismatch with the requested pick-up. For web-form bookings you need none of this, because a form already gives you fields.

A confirmation text that fits one SMS segment

For a standard booking, do not ask a model to write the confirmation at all. Fill a fixed template from the record. The weekday and the date are in the first words so that a wrong "tomorrow" jumps out at the passenger, and the last line tells them how to change anything.

Booked: {weekday} {day} {month} {time}. {pickup} to {dropoff}. {passengers} passengers, {bags}. {fare_text}. Change or cancel: reply or call {phone}. {firm}

Filled in (illustration):
Booked: Wed 14 Oct 05:30. 14 Ash Road to Airport T2. 3 passengers, 2 cases. Fixed fare $48. Change or cancel: reply or call [phone]. [firm]

With a 12-character phone number and an eight-character firm name, that filled-in text runs to 146 characters. In plain characters it is one segment. Twilio's documentation sets a single GSM-7 segment at 160 characters and says longer messages are split into segments of 153 characters each, with the rest used to stitch them together. The catch is that emoji and curly quotation marks switch the whole message to a different encoding, UCS-2, where one segment holds 70 characters and a split message holds 67 per segment. Text pasted from a word processor often contains curly apostrophes, and some accented letters in street names can have the same effect, so test your real data.

Here is what that costs. At two texts per booking (the confirmation and a "driver on the way" message), a firm taking 48 bookings a day sends 96 texts and 2,880 in a 30-day month. If every message stays at one segment, you pay for 2,880 segments. If every message is 146 characters and picks up one curly apostrophe, each becomes ceil(146 / 67) = 3 segments, and the same month bills 8,640. Multiply by your provider's per-segment rate, which is on their rate card. Twilio's page on SMS character limits has the exact figures.

WhatsApp works differently. The platform sorts messages into categories, and a confirmation you send first, outside the 24-hour window that opens when the customer last messaged you, has to use a pre-approved template in the utility category. According to Meta's pricing page, from 1 October 2026 utility templates sent inside an open window are charged too, each business number gets 1,000 free service messages (free-form replies) a month, and without a payment method on the account, service messages stop being delivered once that free allowance is used up. Rates depend on the recipient's market, so read Meta's WhatsApp pricing page instead of trusting a number in someone's article. This applies to the Business Platform, usually reached through a provider, and not to the free WhatsApp Business app. For the wiring, the Zapier and WhatsApp Business updates tutorial walks through templates and triggers.

AI earns its place on the exceptions: a record with a child seat or a wheelchair-accessible vehicle, or a booking that is a return journey. The prompt below picks the variant and adds one sentence, and it forbids the two things models like to do, which are adding services you do not offer and restating times in friendlier words.

Write one extra sentence (max 90 characters) to append to a taxi booking confirmation.
Use only the fields below. Do not add services, promises, waiting times or
greetings. Do not restate the time or the fare.

Fields: special_needs = "wheelchair-accessible vehicle"; vehicle_allocated = "WAV 3"

A good answer is "Wheelchair-accessible vehicle allocated (WAV 3)." A bad one, the kind of line models tend to add when the rule is missing, is "Your driver will meet you at the door and help with the ramp." If your drivers do not do that, the confirmation has just made a promise the firm has to break. This is the same failure the tutorial on promises AI invents in customer emails describes, and a one-line rule in the prompt plus a read-through of the first fifty exception texts catches it.

The same engine behaves differently in two kinds of firm. An airport-transfer specialist needs the flight number, the meeting point and a return-leg line in nearly every confirmation, so most of its bookings are exceptions and the template has four variants. A rank-and-phone city firm sends something closer to "Cab booked for 18:40 at [address], reply to change", needs one variant, and may find that the real saving is in the receipts.

Driver job cards: only what the driver needs

A job message that a dispatcher pastes from the booking sheet is usually either too long to read at the kerb or missing the one detail that matters. Compare the dispatcher's raw note with the card built from the record.

Raw note:
mr airport 5.30 ash rd 3 pax lots of bags pls call him when outside bell dont work

Job card (illustration):
JOB 4471  Wed 14 Oct  05:30
From: 14 Ash Road (bell broken, call from outside)
To: Airport T2 departures
3 passengers, 2 large cases (needs estate or MPV)
Flight AB456 departs 08:15
Fare: fixed $48, pay by card on board
Contact: via dispatch

The card is generated from fields, so a model has only one small job here: condensing free-text notes into a single line, such as "bell broken, call from outside". It never changes a field, and its line is shown to the dispatcher in the review queue before the first run of a new note style. Include what the driver needs to do the job and nothing more: no passenger history, no card details beyond the payment method, and the phone number only if your drivers call passengers directly. Fewer personal details in more places means fewer to protect, and it is easier to explain to a passenger who asks.

Add one rule that is not AI. Ask the driver to reply "OK 4471" or tap the acknowledge button your system provides, and flag any job with no acknowledgement 30 minutes before pick-up. Early-morning airport jobs are exactly where a missed message turns into a stranded customer.

Receipts: AI words the lines, the sheet does the sums

A receipt is a record of money, so the money comes from the sheet. Each amount below sits in its own column of the trip record, the total is a SUM over those columns, and the model is never asked to add anything. The figures are illustrative.

Where does AI help? In turning a driver's shorthand such as "wait 12" into the line label above, in writing the two-sentence email that carries the PDF, and above all in reading the request. Receipt requests rarely arrive with a booking ID: "Can I get a receipt for Tuesday's airport trip?" is typical. The flow that works has five steps.

1. The email or WhatsApp message arrives and AI classifies it as a receipt request, extracting any date, pick-up hint and name.
2. A lookup, not the AI, searches the booking sheet for completed trips that match the date and the sender's contact on the booking.
3. If there is exactly one match and the request came from the email address or number on that booking, a script fills the receipt template, saves the PDF to the trip's folder and sends it.
4. If there are none or several, or the sender is not the booking contact, the request goes to a human with the candidate rows shown.
5. The send is logged on the booking row with a timestamp.

Step three is a privacy rule as much as an automation rule. A receipt shows where someone was picked up and where they were dropped off. Sending it to whoever asks, on the strength of a plausible description of the trip, is how a taxi firm ends up handing a stranger a journey history. Match on the contact held on the booking, and make the human queue the only route for anything else. Collecting an email address with consent at booking time makes this much smoother, which is covered in the tutorial on collecting customer emails automatically.

For business customers, add a reference or purchase-order column to the record, so it prints on the receipt. Tax lines and registration numbers should come from your accounting settings or a fixed block in the template, not from a prompt. Ask your accountant which fields a business customer needs before you finalise the layout; the right answer depends on rules that AI cannot see.

Three ways to wire it up, cheapest first

Start with route A, and ask your vendor to show these rather than describe them: a confirmation sent when a booking is saved; wording you can edit with merge fields; a different template for account customers; a receipt generated when the trip completes, with itemised lines; a button for staff to re-send a receipt in under a minute; a log of every message with a timestamp; an export of booking records in a format your licensing authority accepts; and a setting for how long data is kept. Vendor feature pages commonly list automatic confirmations and e-receipts, but the pages do not tell you whether you can change the text, and that is the question that decides whether route A is enough.

Route B is where AI and the automation tool meet. In Zapier, triggers and filters do not count as tasks and every successful action step does. A Zap that sends the text, updates the status and logs the message uses three actions per booking. At 48 bookings a day that is 1,440 runs and 4,320 tasks a month. Zapier's Professional plan starts at 750 tasks for $19.99 a month on annual billing ($29.99 monthly), and the 10,000-task tier is $129 a month billed annually ($193.50 monthly). Pick the tier above your own count, and keep standard bookings free of AI steps, since an AI step can use more than one task. Make is credit-based, with a free plan of 1,000 credits a month and paid plans from about $9. Its scheduled triggers use a credit on every check even when nothing has arrived, so a sheet checked every 15 minutes burns around 2,880 credits a month before it has sent anything. Check both vendors' pricing pages before you commit, because plans change.

Route C needs one question answered first: can your dispatch system send an event, a webhook, when a booking changes status? If yes, an automation tool can listen for it. If not, you are scraping an export, which is fragile. Webhook triggers in Zapier are not available on the Free plan, so budget for a paid tier.

The sums for a nine-car firm taking 48 bookings a day

A nine-car firm logs 48 bookings a day: 30 by phone, 12 by WhatsApp or email, 6 through a web form. These timings are assumptions, so time a real week of your own before you trust them.

The time saving is real, but it comes with a cost line worth stating: 2,880 texts a month at one segment each, plus an automation plan sized to your task count, plus an hour a week of someone's time keeping templates and rules tidy. A three-car firm taking 10 bookings a day has about a fifth of this volume, saves under 20 minutes a day, and will often do better to switch on its dispatch system's built-in messages and do nothing else.

Booking records your licence may require you to keep

Licence conditions are set by whichever authority licenses you, and they differ. Published operator conditions commonly ask for a booking record covering the passenger's name, when the booking was received, the pick-up point and requested time, and the vehicle and driver allocated, and some also cover bookings that were cancelled or never led to a pick-up. Retention periods of six or twelve months are common, and some conditions let the licensing authority ask for longer. Treat that as a reason to read your own conditions, not as a rule for your firm.

Whatever your conditions say, keep four things together. The first is the original request, whether that is a WhatsApp message, an email or a call note. The second is the booking record as it stood when the job was accepted. The third is every later change with who made it and when. The fourth is the messages you sent, with timestamps. If AI extracted a field and a dispatcher corrected it, keep both versions. The AI's output is a working copy, and the original is the evidence.

Three practical habits follow. Use an append-only log tab or the dispatch system's own audit trail instead of overwriting cells. Ask the licensing authority in writing whether an electronic sheet plus a message log satisfies the condition, and keep the reply. And when the retention period ends, delete, because passenger names, addresses and phone numbers should not sit in a sheet for years because nobody owned the clear-out. Use a business-plan or API account for the AI step rather than a personal chat window, and see how to keep customer data private when your team uses AI for the settings to check.

How these automations fail on a real shift

Most failures look dull in hindsight, which is why they get through. These are the ones to plan for, with how each shows up.

• Morning or evening mix-ups. "5.30" becomes 17:30. It shows up as a passenger replying "wrong time" at 05:00. The fix is the weekday, date and 24-hour time in the first words of the text, and a rule that any bare hour without am, pm or a 24-hour format goes to needs_check.
• The night the clocks change. A small-hours pick-up can fall in an hour that happens twice, or in one that never happens, depending on which way the clocks move. Have a dispatcher review every booking made for midnight to 03:00 on that date, whatever the automation says.
• Duplicate confirmations. Editing a booking re-triggers the automation. Guard it with a "confirmation sent at" cell: send only when it is blank, or when a key field such as time or address has changed since the last send.
• A confirmation to the wrong number. A mistyped digit sends a stranger the address and time. On phone bookings, have the dispatcher read the number back, and never send to a number that failed a basic length check.
• A receipt to the wrong person. Covered above: match on the contact held on the booking.
• Cost creep. A curly apostrophe can double or triple the segments, and WhatsApp utility messages in an open window are charged from 1 October 2026. Compare each month's bill with the expected count of texts, and look at segments per message, which should sit at 1.0.
• The invented promise. A model adds a meeting point, a name board or a free waiting time you do not offer. Ban additions in the prompt and read the first fifty exception texts yourself.

A two-week check before you stop reading every message

Run it in two stages. In week one, shadow mode: the automation drafts every confirmation, driver card and receipt, a person sends them after a quick read, and every correction is logged with a reason. In week two, switch on automatic sending for standard bookings with complete fields, and keep a person on the review queue and on the exception texts.

These bars are my own rules of thumb, not an industry standard, so move them to suit your tolerance. What matters is that the decision to stop reading messages comes from a count, not from a feeling that the last few looked fine. If the wrong-detail count stays above zero for more than a week, find the pattern first, which is almost always one channel, one phrase ("half five"), or one address format, and fix that before adding volume.

If the numbers hold, the order for widening automation is receipts first, because they are low-urgency and easy to reverse, then driver cards, then confirmations for the free-text channels. Confirmations for phone bookings logged by a dispatcher are the exception and can start earlier, since a person has already read the details back to the passenger. Meanwhile, if you also want calls answered, the tutorial on AI handling taxi customer service calls covers what to hand over and what to keep.

Questions taxi owners ask before switching this on

Can an automated receipt count as an invoice for a business customer?

It depends on the fields your customer's accounting rules need, such as a tax registration number or a purchase-order reference. Build those as columns in the booking record so they print on every receipt, and ask your accountant which fields business customers need. Don't let AI write tax lines: it sees wording, not your registration.

What if a passenger replies to the automated confirmation text?

Send replies to a number or inbox that a person watches, and treat any reply that changes a time, address or passenger count as a booking edit that a dispatcher confirms. AI can sort replies into change, cancel or question, but it shouldn't alter the booking itself without a person seeing it first.

How long should I keep original messages and the AI's output?

Keep them for the longer of your licence conditions and your accountant's rule. Published operator conditions commonly ask for booking records to be kept for six or twelve months, and some let the licensing authority ask for longer, so read your own. Keep the customer's original words beside the record; the AI's extra fields are working copies, not evidence.

Is the free Zapier plan enough for a small cab firm?

Only for very low volume. The Free plan allows 100 tasks a month and two-step Zaps, meaning a trigger and one action. If each booking sends one text, you reach the cap at about 100 bookings a month, and you can't log the message in the same Zap. A firm taking 48 bookings a day needs a paid tier or its dispatch system's own messaging.

Further reads

• Restaurant No-Shows: Deposit Rules by Party Size, AI Confirmations — Confirmation and deposit rules from another booking-led trade.
• AI in Travel and Transport: Jobs a Small Coach Hire Firm Can Hand Over — Follow one coach booking from enquiry to return journey to see which admin jobs AI can draft, and which checks stay with people.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Twilio documentation on SMS segments and character encodings; Meta's WhatsApp Business Platform pricing page; Zapier and Make plan pages; published private hire operator licence conditions from several licensing authorities (booking-record fields; retention of six or twelve months, sometimes longer on request); dispatch vendors' own feature pages.