A small-group tour operator I work with in Lisbon has 14 departures running every month from April through October. Each departure touches an average of 22 suppliers. Hotels, restaurants for group dinners, drivers, museum guides, cooking-class hosts, day-trip operators, the boat captain in Setúbal, the wine estate in Alentejo. That is roughly 308 supplier touchpoints per month, and every single one needs to be confirmed twice. Once when the trip is sold. Again two weeks before departure.
His operations coordinator used to spend two and a half days per week just chasing confirmations. Sending the email. Waiting. Following up. Updating the spreadsheet. Calling the ones who never responded. Updating the spreadsheet again. A printed spreadsheet, naturally, because she could not actually trust the digital version to be current.
In February she started using Claude to parse incoming confirmations and a Zapier automation to send the follow-ups. Her supplier confirmation work is now four to six hours per week. The remaining time goes to the suppliers who actually need a human touch: the three boutique hotels in Alentejo who only confirm by phone, the elderly fado guitarist who does not check email, the new caterer who needs reassurance the first six times. The exact people who should be getting more of her attention.
This post is the system. The setup, the prompts, the workflow, and the part most operators get wrong on the first try.
What does a supplier confirmation automation actually do?
It handles three jobs that used to be manual: sending the initial confirmation request, parsing the response when it comes back, and following up with the suppliers who do not reply. Claude or ChatGPT reads the inbound emails and updates a status sheet. Zapier or Make sends the outbound emails on a schedule. The operations coordinator spends her time on exceptions, not on the routine 80 percent.
The full system runs on tools you probably already have: Gmail or Outlook, Google Sheets or Airtable, Claude or ChatGPT, and Zapier or Make. Setup is one to two days for someone moderately technical, or a week of part-time work if you have never built an automation before.
What you need before you start
Three things in place before you write a single automation. None of these is exciting, but skipping them is the single biggest reason supplier confirmation systems fail.
1. A vendor master list (one document or sheet). Every supplier you regularly use, with their email address, contact person, preferred language, response pattern (do they confirm in 24 hours or 5 days), and any quirks. The Lisbon operator's quirks column has entries like "calls back instead of replying," "needs Portuguese," "ignores first email, responds to second." This file is the same vendor knowledge file that powers the proposal workflow. Build it once, use it everywhere. If you do not have one yet, start with your last six months of departures and write a row per supplier. Half a day of work.
2. A standard confirmation request template (in two or three languages if you operate internationally). Subject line, body, the booking details that change per trip. Keep it short. Suppliers do not read long emails. The template should always include: trip name, group size, date, requested service, your booking reference, a clear "please confirm by [date]." That last line matters. It gives the automation something to track.
3. A status sheet (Google Sheets or Airtable). One row per booking. Columns: trip code, supplier name, service, date, status (pending / confirmed / changed / unresponsive), last contact, days since last contact, notes. This is the dashboard. The automation writes to it. The coordinator reads it.
You can build this from scratch in a morning. The Lisbon operator's version has 11 columns and looks like a slightly fancier spreadsheet. It is not impressive. It works.
The workflow, end to end
Here is the actual flow, broken into four stages. Each stage uses a specific tool. None of the stages requires custom code.
Stage 1: The outbound confirmation (Zapier or Make sends it)
When a trip is finalized in your booking system or marked confirmed in your CRM, a Zapier automation fires. It looks up every supplier touchpoint for that trip from your vendor master list, generates an email to each one using your template, and sends them all. The email lands in the supplier's inbox with the trip details filled in.
If you do not have a CRM that triggers Zapier, you can trigger this manually: a Google Form your designer fills out when a trip is finalized, a button in your status sheet, or a tagged email in Gmail. The point is that confirming a trip should send 22 emails in 30 seconds, not 90 minutes of manual sending.
Stage 2: The inbound parser (Claude reads the replies)
This is the part that used to require a human. Claude can do it now in under a second per email.
Every reply that comes back to your confirmation address gets forwarded into a Claude workflow. The workflow reads the email and answers four questions:
- Which trip and which supplier is this about?
- Is the supplier confirming, declining, asking for changes, or asking a question?
- If they are confirming, is anything different from what we requested? (Different date, different group size, different price)
- If they are asking for changes or have a question, what specifically?
Claude returns a structured JSON object with those four answers. Zapier or Make takes the JSON and updates the status sheet. Confirmations move to "confirmed." Changes move to "needs review." Questions get flagged for the coordinator.
The prompt for this step, slightly simplified:
You are processing inbound emails for a tour operator's supplier confirmation
system. Read the email below and return a JSON object with these fields:
- trip_code: the trip reference number, if present
- supplier_name: the supplier's name or business name
- status: one of "confirmed", "changed", "declined", "question", "unclear"
- changes: if status is "changed", describe what changed in one sentence
- notes: any context the operations team should know
- urgency: one of "low", "medium", "high". Use high if the supplier mentions
cancellation, price change, or a date conflict
Email:
[email body pasted in by the automation]
Return only the JSON object, no other text.
Drop this into a Claude API call inside Zapier or Make. The whole step costs fractions of a cent per email and runs in real time.
Stage 3: The follow-up engine (Zapier sends the chase email)
Every morning at 7 AM, a Zapier automation reads the status sheet. For every row where status is "pending" and "days since last contact" is greater than three, it sends a follow-up email. After seven days with no response, it flags the row for the coordinator instead of sending another email automatically. Suppliers who get three robotic follow-ups in a row are suppliers you are about to lose.
The follow-up template is shorter than the original:
Hi [supplier name], following up on the request below for [trip name] on
[date]. Could you confirm whether you can host the group? Happy to call if
easier. Thanks, [your name]
That is it. One sentence, one ask, one clear path. It is more polite than most operators send when they are stressed, which is the second-order benefit of automating it.
Stage 4: The exceptions queue (the coordinator handles what AI cannot)
Every morning the coordinator opens the status sheet and looks at three things: rows where Claude flagged a status of "changed" or "question," rows where Claude flagged urgency as "high," and rows that have been pending for more than seven days. That is her work for the day. Maybe an hour total, instead of two and a half days a week.
She handles exceptions the way humans handle them: by picking up the phone, sending a personal email, walking down to the vendor's bar to chat in person. Things AI cannot do. Things her job is supposed to be about.
The three things most operators get wrong
I have seen this system implemented at four operators. Three of them stumbled on the same three things on the first try.
1. The vendor master list is incomplete or wrong. If the supplier list has the wrong email address, the automation sends to the void. If it does not capture each supplier's response pattern, the follow-up logic fires too aggressively or not aggressively enough. Spend the day on the vendor file before you spend the day on the automation. The system is a multiplier on the data; bad data multiplies into bad outcomes faster.
2. The Claude parsing prompt is too generic. The prompt above is a starting point. After two weeks of running it, you will have a folder of edge cases where Claude got it wrong. A supplier replies "yes for the dates you mentioned but the price has changed" and Claude marks it confirmed because it saw "yes." A supplier replies in Portuguese and the prompt was in English. A supplier replies with three questions and one acceptance and Claude picks one. Tune the prompt every two weeks for the first two months. Add explicit examples of edge cases. After eight weeks the prompt holds up across the edge cases and you can leave it alone.
3. The team does not trust the automation, so they keep doing it manually. This is the cultural failure mode. The automation runs, the status sheet updates, and the coordinator still sends the confirmations herself because she does not trust the system to have actually done it. Two of the four operators I have worked with had this problem for the first month. The fix is to run the automation in parallel with the manual process for two weeks, compare the results daily, and only switch over once the team has visible proof the automation is reliable. Skipping this step almost always costs more than running it.
What this saves and what it does not save
From the Lisbon operator, after three months of running the system:
- Coordinator time on confirmations: 18 hours per week down to 4 to 6 hours
- Confirmation response rate from suppliers: unchanged at 84 percent (good news)
- Average days from request to confirmation: 6.2 days down to 3.8 days
- Confirmation errors caught before departure: up by roughly half (the AI flags inconsistencies the human used to miss)
- Supplier complaints about being chased too aggressively: down
What it does not save: the relationship work. The new supplier who needs a phone call. The hotel owner who only confirms after a chat. The fado guitarist. Those are still human jobs and they should remain human jobs. The automation gives the coordinator the time to actually do them well.
What this means for the guest
The supplier confirmation chase is invisible to guests, until it fails. When the cooking class is unconfirmed, the guests find out at 9 AM Tuesday when the class does not happen and the guide has to invent a Plan B in the van. When the boat is unconfirmed, the guests find out when they arrive at the marina and stand around. Supplier confirmation failures are not back-office failures. They are failures on the trip.
A supplier confirmation system that runs reliably is invisible. It is the absence of a problem the guests would have otherwise experienced. The coordinator stops being the bottleneck and starts being the safety net. The guests get the trip they paid for.
What to do next
Start with the vendor master list. If you have one, audit it. If you do not, build it this week. Without it, no automation will work.
Once that is in place, build the rest in stages. Set up the status sheet. Set up the outbound automation in Zapier. Add the Claude parser. Add the follow-up engine. You can run each stage manually until the next one is built. The Lisbon operator built theirs over six weeks of part-time work, with the coordinator using each new stage as it came online.
If you want help scoping the build for your specific stack, book a discovery call. Forty-five minutes, free, no pitch. We will look at your current confirmation process, identify the automation that pays back fastest, and you will leave with a build plan.
The supplier confirmation workflow is one of twelve tour operator workflows worth automating with AI, and it depends on the same vendor knowledge file that powers AI proposal generation for trip designers. Build the vendor file once, use it everywhere.
Sources and further reading
- Arival's research on tour operator operations for benchmarks on confirmation timing and supplier management.
- Skift's coverage of tour operator technology for industry context on operations tooling.
- Anthropic's Claude API documentation for the parsing step setup.
- Zapier's tour operator templates and Make.com's automation library for the orchestration layer.
- USTOA's 2025 member survey on operations efficiency and AI adoption.