Executive summary
Two connected modules, one measured shift.
An Africa-focused travel operator runs on a shape familiar to every specialist travel business: enquiries arrive and have to be qualified quickly, and bespoke itineraries have to be prepared before a traveller sees anything useful. Both stages ran on specialist time. Every web lead needed someone on the telecalling team to gather the trip details the website form could not capture, and every itinerary took the itinerary team around six hours to prepare.
iTechCloud Solution delivered two connected automation modules on Salesforce. The first put Web-to-Lead at the website entry point and handed the traveller onward to a natural-language Agentforce conversation that captured what the telecalling team had previously gathered by phone. The second combined Agentforce and Salesforce Data Cloud to automate itinerary preparation, with hotel booking API calls integrated into the same workflow instead of sitting outside it.
The outcome rests on one specific number. Itinerary preparation moved from around six hours to around 30 minutes: roughly a 92% reduction in elapsed preparation time, or about 12 times faster, on the reported before-and-after figures. Lead qualification capacity improved alongside it, because basic trip information now arrives through the Agentforce conversation rather than by phone.
- Client
- An Africa-focused travel operator (anonymised in the source)
- Industry
- Travel and hospitality: destination travel and safari operations
- Users
- Travellers enquiring through the website, the telecalling team qualifying those enquiries, and the itinerary team preparing each trip plan
- AI & data
- Two Agentforce agents, one conversational and one for itinerary preparation, with Salesforce Data Cloud supplying the trip context
- Platform
- Salesforce core with the Lead object as the shared data model, Web-to-Lead, Agentforce, Data Cloud and a hotel booking API integration
- Scope
- Conversational lead qualification at the website entry point, and automated itinerary preparation with booking calls inside the same workflow
- Measured outcome
- Itinerary preparation from around six hours to around 30 minutes, roughly 92% less elapsed time
The situation
Specialist time, spent on work the system could do.
Early-journey operations ran on manual handoffs at exactly the moments where travellers are least willing to wait. Trip planning starts with details that a short website form cannot collect, and ends with an itinerary that takes substantial specialist time before anything useful can be sent back. Three pain points shaped the engagement.
Lead capture depended on a phone call
A prospect submitted the website form and Web-to-Lead created the Lead. Someone on the telecalling team then had to call, ask the same foundational questions, and make the answers available for follow-up. The first qualification step waited on staff availability, repeated for every lead, and varied in which questions each caller actually asked.
A six-hour itinerary preparation cycle
The itinerary team spent around six hours preparing each trip plan. That is a long gap between understanding what a traveller wants and producing something they can react to, and it capped throughput: the business could prepare only as many itineraries as the team could run six-hour blocks for.
Hotel booking sat outside the workflow
Hotel booking actions involved API calls, but those calls lived outside itinerary preparation as a separate operational step the team worked through afterwards rather than as part of the same connected process.
Together these capped the pace at which the customer journey could move. The question was never whether the specialists added value, because they plainly did. It was which parts of their work the platform could take, so their time could move to the parts only people can do.
Our approach
Two connected modules, scoped around the specific bottlenecks.
The design principle here was deliberately narrow. Rather than attempt a full operational overhaul, we identified the two specific moments where specialist time was going on repetitive work and built automation at each, on the understanding that two focused interventions which compound beat a platform rewrite that does not finish.
The first module addressed lead capture. Instead of relying on a telecaller to extract trip details by phone after the Lead existed, we extended the lead journey past form submission by handing the visitor onward to a natural-language Agentforce conversation. The traveller gives the trip details conversationally and they land directly on the Lead record, ready for consultant follow-up with no telecalling step in between.
The second module addressed itinerary preparation. Agentforce and Salesforce Data Cloud automate the preparation itself, with the traveller and trip information from the first module feeding straight into the workflow. Hotel booking API calls were integrated into that same workflow, bringing booking activity into travel planning rather than leaving it as a step afterwards.
What makes the two modules worth more together than separately is the single Lead data model underneath. What the Agentforce conversation captures at the website entry point is exactly what Data Cloud and Agentforce reference during preparation. Nothing is re-entered, nothing is re-asked, and nothing is lost between the two stages. Better context at the enquiry stage is directly what shortens the preparation stage.
The question was never whether specialists added value, because they clearly did. The question was which parts of their day belonged to the platform. We built two automation modules around the answer, and left the specialists free to do the work only they can do.
Subhash Panchani, CEO & Co-Founder, iTechCloud Solution
What we built
Two connected modules on Salesforce.
Module 1: Web-to-Lead plus Agentforce conversational qualification
The first module turns lead intake into a four-step journey. The prospect submits the website enquiry form. Salesforce Web-to-Lead creates the Lead record automatically. The visitor is directed to a natural-language Agentforce conversation at the point of submission. Agentforce then collects the trip details that previously needed a telecalling follow-up: travel timing, meaning when the traveller intends to go; travel style, meaning how they want to travel; trip type, meaning the kind of experience they are considering; and a phone number for follow-up.
Because the conversation is natural-language, the traveller answers in their own words rather than working through a long static form. The combination connects website lead capture to a guided requirement-gathering experience, so the consultant's first call starts from a Lead that already carries the context a telecaller previously had to extract, and the team is no longer dependent on telecaller availability to get it.
Module 2: Agentforce plus Data Cloud for itinerary automation
The second module turns itinerary preparation into a four-step workflow. Travel context, which is the traveller and trip information captured in the first module, flows into Data Cloud, which makes the relevant data available to the planning workflow. Agentforce then automates preparation using that context, producing a draft itinerary that previously took around six hours of specialist time. The itinerary team moves from an hours-long build cycle to a review-and-refine role on top of an automated draft: more capacity for complex requests, the same or better output, substantially shorter turnaround.
Hotel booking calls, inside the workflow rather than after it
Hotel booking API calls were incorporated into the second module's workflow rather than existing as a separate step, which brings hotel-related booking activity into the broader travel process and takes the operational effort of handling it separately off the team. The specific hotel provider, the API protocol, the booking confirmation logic, error handling and any human approval steps are not described here. They were not part of the engagement's public project record, and this case study asserts only what that record confirms: hotel booking API calls were incorporated into the automated workflow.
The connecting data model
Both modules operate against the same Salesforce Lead data model. Travel timing, travel style, trip type and contact information land on the same Lead record that Data Cloud and Agentforce read during preparation. Nothing the first module captured is re-entered or re-asked by the second. That is the connection that makes the modules compound rather than merely coexist, because the quality improvement at the enquiry stage reduces the preparation effort at the itinerary stage.
The outcome
A measured shift at both ends of the early journey.
Faster itinerary turnaround
The headline outcome and the specific one. Itinerary preparation fell from around six hours to around 30 minutes per cycle: roughly a 92% reduction in elapsed time, or about 12 times faster, on the reported before-and-after figures.
More efficient lead qualification
Natural-language Agentforce conversations now capture the initial travel preferences and contact details that previously needed a telecaller on the phone. The telecalling team's time has moved from gathering foundational information to acting on better-contextualised enquiries. The project reported a reduction in that team's workload; no headcount figure was supplied, so none is claimed here.
Better enquiry tracking
The same questions get asked in the same way and the same fields get captured on every Lead, so consultants pick up every web enquiry with the same reliable context. For a business that previously depended on telecaller-to-telecaller variation in what was asked, that consistency is an operational improvement in its own right.
Higher team productivity
Repetitive work fell at both stages. The telecalling team spends less time on routine qualification and the itinerary team less time on routine preparation, so specialist attention has moved to the judgement calls only people can make.
Connected booking actions
Hotel booking API calls now run inside the itinerary workflow rather than as a disconnected downstream task, so the team no longer carries hotel actions separately on top of preparation. Both move together as part of the same automated flow.
Platform & tooling
What's under the hood.
Salesforce core
The Lead object as the shared data model across both automation modules.
Web-to-Lead
Website form capture, with the natural-language Agentforce conversation presented at the point of submission.
Agentforce for intake
The conversational qualification agent, collecting travel timing, travel style, trip type and contact details against the Lead record.
Agentforce for itineraries
The preparation agent, generating draft itineraries from the traveller and trip context Data Cloud supplies.
Salesforce Data Cloud
Makes the available traveller and trip data usable inside the itinerary workflow.
Hotel booking integration
Hotel booking API calls incorporated into the itinerary workflow. The provider and protocol are not described in this public case study.
Delivery
The iTechCloud methodology: discovery, design, Agile build, QA and automated release management from development through UAT to production.
A note on technical specificity: the engagement's public project record describes the business workflow and the Salesforce capabilities applied to it. Specific implementation choices, including Apex classes, Flow configuration, API provider names, exact field mappings, error handling and human approval steps, are not asserted here, because they were not part of that record.
Working with iTechCloud
How the engagement ran.
A two-module Agentforce and Data Cloud engagement rewards disciplined scope and tight iteration. This one was deliberately scoped around two specific bottlenecks in the early travel journey, enquiry qualification and itinerary preparation, with measurable outcomes defined at both ends rather than an open-ended brief to see what AI could do.
Engagement model
A full-lifecycle Agentforce and Data Cloud build delivered end to end for both modules, followed by managed services as the operational scope grows. The build ran in clearly scoped phases, each with explicit entry and exit criteria: discovery, data model and architecture design, the first module, the second module including the hotel booking integration, QA, release and hypercare.
Team shape
A solution architect with Agentforce and Data Cloud background led the engagement, supported by developers across Agentforce configuration, Data Cloud and integration work, with a dedicated business analyst and QA throughout. Subhash Panchani, CEO and Co-Founder, sponsored the engagement and stayed personally involved in the architectural and strategic decisions, as on every major client engagement.
Governance and collaboration
Regular steering reviews with client leadership, daily stand-ups inside the delivery team, and an architecture review at each major design decision. The two agents' topics and instructions and the connected Data Cloud flow were designed with the operations and itinerary teams, which is to say with the people whose work the modules were automating, so the platform's behaviour on day one reflected how the business actually ran rather than a generic chatbot or a template itinerary.
