Executive summary
From first enquiry to published itinerary.
A leading luxury African travel specialist designs tailor-made journeys across East and Southern Africa: safari lodges, tented camps, boutique hotels, island stays, fly-in safaris and gorilla treks. Every trip is bespoke, and every itinerary carries the operational detail a traveller depends on at the far end of a long journey. The business runs on consultant expertise, and consultant time was the bottleneck everything else bumped into.
iTechCloud Solution built the AI-led enquiry and itinerary platform on Salesforce. It uses Agentforce in three distinct places, on web chat, on email and inside the consultant's own workflow, with Salesforce Data Cloud keeping what consultants approve. Together they take a traveller from first enquiry to a personalised itinerary, and a booked trip from raw logistics to polished, client-ready day notes.
Repetitive work moved to the agents and consultant time moved to judgement, under strict factuality guardrails and human approval before anything reaches a client. Every approved note is archived, so institutional knowledge becomes platform state rather than something that lives in one consultant's head.
- Client
- A leading luxury African travel specialist (anonymised in the source)
- Industry
- Travel and hospitality: tailor-made safaris and destination travel
- Users
- Travellers enquiring on the website or by email, and the travel consultants and lead owners working inside the platform
- AI & data
- Agentforce (three agents) and Salesforce Data Cloud for the approved supplier-notes archive
- Platform
- Salesforce Sales Cloud, Agentforce on Messaging and Web Chat, Agentforce email handling, a Lightning consultant workspace, Wetu and Calendly integrations
- Scope
- Conversational lead capture, personalised itineraries, email lead enrichment, Calendly hand-off, AI day-by-day notes, two-way Wetu sync, Data Cloud knowledge capture
The situation
Consultant time was the bottleneck at both ends of every trip.
A tailor-made safari starts with a long conversation and ends with pages of precise logistics, and historically both depended on consultant time. The pieces worked individually. Together they capped how fast the business could grow and how many trips one consultant could carry. Six problems shaped the engagement.
Incomplete enquiries
Leads arrived with only part of what a consultant needs: group size, destination, budget, accommodation style or length of stay. The rest was chased by email, one lead at a time.
Slow first response
A traveller asking for ideas waited until a consultant was free before seeing anything. Interest cooled while they waited, and other operators got there first.
Generic suggestions
Matching a budget and a preferred class of lodge to the right destinations and activities lived in consultants' heads, not in any system. Two consultants would propose two different trips to the same traveller for reasons neither could easily explain.
Hours of note writing per trip
For every booked trip, consultants hand-wrote arrivals, meet-and-greets, transfers, flight connections, activity timings and supplier contacts for every day. The itinerary platform held the structure; the operational prose was written stage by stage, by hand.
Real risk in a wrong detail
Day notes are operational, not marketing. A guessed transfer company, a wrong room type or a mis-stated meeting time can strand a traveller at an airstrip in the middle of a safari region. Any AI help had to be strictly factual.
Knowledge that did not stay
Well-written supplier notes sat inside individual itineraries with no shared library to reuse or learn from. Institutional memory lived only inside the consultants who wrote it.
Our approach
Three agents, one Lead model, strict human approval.
The principle running through the engagement was to take repetitive, time-consuming work off consultants without taking away their judgement. In practice that meant deploying Agentforce in the three places where consultant time was going on work that could be automated, while keeping a human in the loop everywhere a traveller-facing commitment was made.
Underneath the two traveller-facing agents sits a single Lead data model, so someone who starts in web chat and finishes by email never repeats themselves: both channels write to the same fields. Alongside it sits a Data Cloud archive of consultant-approved day notes, which turns knowledge that used to live inside individual itineraries into a vetted library that grounds the next draft.
The right question for Agentforce is not what the agent can do. It is what the agent should decide, and what belongs to a human. Get that line right and the AI earns its place; get it wrong and you have built a liability.
Subhash Panchani, Founder & CEO, iTechCloud Solution
The final principle was strict factuality. Operational day notes are not marketing copy, so a hallucinated transfer time is not a stylistic problem, it is an operational failure. The agents are configured with no-guess guardrails: if a detail is not known it is left out, never invented. Every AI-drafted note goes through side-by-side human review before it reaches a traveller. The platform is AI-first, not AI-only.
What we built
The three-agent travel platform, end to end.
Agentforce on web chat, for conversational lead capture
The first agent greets the traveller on the website and works through what a consultant needs in a continuous loop: name, email and phone to create or update the Lead and give the owner a way to follow up; number of travellers to size rooms, vehicles and activities; destination, chosen from the predefined list so the itinerary is always built from bookable places; budget per person to set the class of accommodation; accommodation preference, from five-star to tented camp to boutique; and number of nights to split the stay across places.
It checks what is still missing after each answer and asks only for that, saving every answer to the Lead as it arrives, so nothing is lost if the traveller leaves mid-conversation. Once everything is captured it returns a personalised itinerary built from live Salesforce records: the right number of days at each place, the accommodation at each stop, the activities available there, and images pulled from the accommodation records. It runs at any hour, in the traveller's own time zone, and hands the consultant a qualified Lead with an itinerary already attached.
Agentforce on email, for autonomous lead enrichment
The second agent handles leads arriving by email from predefined sources. It reviews the Lead, works out which details are missing, and emails the traveller asking only for those. The reply routes back through the email service; the agent reads it in natural language, picks out each detail present and writes it to the Lead, then follows up for anything still outstanding and repeats until the Lead is complete. At that point it emails the personalised itinerary with a Calendly link scoped to the lead owner, so the consultant's first call starts from a complete Lead, an itinerary the traveller has already seen, and a time the traveller chose.
The day-by-day note assistant, beside the consultant
The third agent is consultant-facing. The consultant enters an itinerary reference; the platform pulls the full structure from Wetu, the travel industry's standard itinerary platform, including travel dates, accommodation legs, planned activities, flight routes, road transfers and supplier IDs, and sends it to Agentforce. The agent drafts client-ready notes for every day under fixed guardrails: consultant tone rather than marketing, step-by-step logistics, supplier contacts in a structured format, strict factuality, and narrative continuity so the whole trip reads as though one specialist wrote it. The consultant then reviews the original notes beside the AI-generated ones, day by day, and adjusts, reformats or rewrites before anything is final.
Two-way sync, so there is only ever one version
The integration runs both ways: the raw itinerary structure flows in to be drafted, and the consultant-approved notes flow back out to update the live, client-facing itinerary with a single action. No re-keying of trip logistics, no copying between a draft tool and the final platform, and no risk of the AI-drafted version diverging from the one the client actually sees.
A Data Cloud archive that makes knowledge stay
Every approved day note is archived in Salesforce Data Cloud in a dedicated supplier-notes dataset, with the supplier content IDs preserved alongside the text. Over time that builds a library of vetted, consultant-approved notes and past itineraries: a reference consultants can draw on for new trips, a canonical source for supplier messaging, and the grounding data future drafts learn from. Good writing stops living inside individual itineraries.
One Lead model, and the records the itinerary is built from
The Lead holds the traveller and their trip parameters. Alongside it sit Destination, Accommodation and Activity records holding the offer: the predefined destinations, the lodges and hotels at each with their class and images, and the activities available at each place. Because itineraries are assembled from these records rather than written by hand, a change to a lodge, an image or an activity shows up in the next itinerary the agents send. The system stays in step with what the business can actually sell.
The outcome
Enquiry, itinerary and day notes on one platform.
Website enquiries
What was a form submission and a wait is now a conversation that collects every detail and returns an itinerary straight away. First response moved from "when a consultant is next free" to seconds, at any hour.
Incomplete leads
Consultants no longer chase missing details one lead at a time. The email agent requests, reads and records until the Lead is complete, then hands over something actually ready to work.
The first itinerary
Generated from live destination, accommodation and activity records against the traveller's budget and preference. A higher budget sees premium lodges and matching experiences; a tighter one sees a different, equally real plan. Both are built from bookable places.
Booking the first call
The back-and-forth to agree a time is replaced by a Calendly link inside the final itinerary email, scoped to the lead owner.
Day-by-day notes
Hours of manual writing per booked trip became AI drafts generated from the live itinerary data, reviewed side by side, and published back with one action. Hours of writing become minutes of review, with consultants keeping full editorial control.
Accuracy
Previously dependent on each consultant's own checks, now reinforced structurally: no-guess guardrails stop the agent inventing transfer companies, room types or times, and human approval is the final gate before anything reaches a traveller.
Knowledge retention
Approved notes are archived with their supplier content IDs, building a shared, vetted knowledge base over time instead of leaving good writing inside single itineraries.
Platform & tooling
What's under the hood.
Salesforce Sales Cloud
The Lead object as the shared data model across all three agents, with the consultant workspace in Lightning.
Agentforce on web chat
Deployed on the Messaging channel and web chat, running a conversational loop over the trip details and writing to the Lead live.
Agentforce on email
Attached to the Salesforce email service, triggered on predefined lead sources, parsing natural-language replies and enriching the Lead autonomously.
Agentforce for consultants
The day-by-day note assistant, configured with no-guess guardrails and consultant-tone style instructions.
Salesforce Data Cloud
The supplier-notes archive: every approved note with its supplier content IDs, as a reference library and as grounding for later drafts.
Offer records
Destination, Accommodation and Activity records holding what the business can sell, so itineraries are assembled rather than written.
Wetu integration
Two-way: itinerary structure in for drafting, approved notes back out to the live client-facing itinerary.
Calendly integration
A booking link scoped to the lead owner, sent inside the final automated itinerary email.
Working with iTechCloud
How the engagement ran.
The hard part of an Agentforce build is not making an agent answer. It is deciding what the agent is allowed to decide. Most of the design effort went into drawing that line: which details an agent may ask for and record on its own, which outputs a human must approve before a traveller sees them, and what the agent must do when it does not know something. The last one matters most in operational content, and the answer here is always the same: leave it out.
Engagement model
A full-lifecycle Agentforce and Data Cloud build, followed by managed services as the destination map, the accommodation list and the agent instructions evolve. The three agents were delivered in sequence rather than together, each one proving its guardrails before the next was attached.
Why the human stayed in the loop
In luxury travel the cost of a wrong operational detail is not a bad impression, it is a traveller stranded somewhere remote. Side-by-side review was treated as a design requirement rather than a phase-one compromise, and the archive of approved notes exists so that the system gets better at drafting without anyone loosening that gate.
