Winning a corporate account is the start of the work, not the end of it. Once a corporate client has selected a TMC and asked for a corporate booking tool, what determines success is the implementation — the journey from responding to the tender, through demos and data migration, to a live platform that the corporate's travellers actually use. This is where deployments quietly fail. The tool itself is rarely the problem; the problem is a half-configured platform, a GDS connection that was never properly set up, real bookings that behave differently from the demo, and travellers who were never trained. Most CBT vendors hand over a login and disappear. The TMC is left to carry the implementation alone.
This article is for TMCs that have won — or are competing for — a corporate account and now have to implement a corporate booking tool successfully. It covers the implementation journey stage by stage, and where a capable CBT partner should be working alongside the TMC rather than leaving after the sale. It assumes the choosing-and-building decision is already made; for that earlier decision, see Corporate Booking Tool: A TMC's Guide for 2026.
Start With the Tender: What the Corporate Is Actually Asking For
Before any implementation begins, the TMC has to understand precisely what the corporate tender is asking for — because the answer shapes everything downstream. A tender that looks like a simple "we need an online booking tool" usually hides several distinct requirements that must be surfaced early.
• User types — Who will actually use the tool? Travellers booking for themselves, travel arrangers booking on behalf of others, approvers, finance viewers, and administrators each need different permissions and views.
• Group structure — Does the corporate have subsidiaries or related companies that also need self-service booking? A holding company tender often implies rolling the tool out to several entities, each potentially with its own policy, approval chain, and cost-centre structure.
• Policy and approval complexity — How many approval levels, how many policy variations by grade or department, and how much exception handling the corporate expects.
• Content and payment expectations — Which airlines and hotels, NDC and LCC requirements, and which settlement methods the corporate uses.
Getting these wrong at the tender stage means re-configuring during implementation, which is slower and more visible to the client. Getting them right means the implementation that follows is mostly execution rather than discovery.
The RFP Stage: Where Most CBT Vendors Are Absent
When a corporate issues a request for proposal or request for quotation, the TMC has to respond with specifics: what the platform does, how it enforces policy, what content it reaches, how approval works, what the implementation timeline looks like, and what the service levels are. Many of these answers depend on the CBT itself — yet most CBT vendors do not involve themselves in the TMC's RFP response at all. They sell a subscription and consider the TMC's tender process the TMC's own problem.
This is one of the clearest signals of a CBT partner worth having. A vendor that helps the TMC respond to the corporate's RFP — supplying accurate platform capability detail, supporting the demo, and standing behind the implementation timeline being promised — materially improves the TMC's chance of winning, and ensures the promises made in the RFP are ones the platform can actually keep. A vendor that stays out of the RFP leaves the TMC to make commitments on the vendor's behalf, with no guarantee the platform will deliver them. When evaluating a CBT partner, the willingness to participate in the tender process is a question worth asking explicitly.
The Implementation Journey, Stage by Stage
Once the account is won, a successful implementation moves through a predictable sequence. Each stage builds on the previous one, and skipping or rushing any of them is where deployments go wrong.
1. Introductory demo
The implementation opens with a demo that shows the corporate's stakeholders — travel managers, finance, and often a sample of travellers — what the tool does and how it will fit their process. This is not the same demo used in the sales cycle; it is oriented to the specific corporate's policy and structure, so stakeholders see their own scenario rather than a generic one.
2. Detailed walk-through
Following the demo, a detailed walk-through goes deeper into configuration: how policy rules will be set up, how the approval chain will be modelled, how cost centres and departments map, and how exceptions will be handled. This stage surfaces the gaps between what the corporate assumed and what the tool actually does — gaps that are far cheaper to resolve now than after go-live.
3. Collecting real-life data
This is the stage most often underestimated. A demo runs on demo data; a live tool runs on the corporate's real travellers, real policy, real cost centres, real approval hierarchy, and real negotiated fares. Collecting and loading this real-life data — and testing the tool against it — is what reveals whether the configuration actually works. Bookings that behaved perfectly with demo data often behave differently with the corporate's real policy edge cases. Catching this before go-live is the difference between a smooth launch and a launch that erodes the corporate's confidence in the TMC.
4. Implementation and configuration
With real data in hand, the platform is configured to the corporate's specifics: policy rules, approval chains, user roles and permissions, cost-centre structures, content sources, and payment methods. For a group with subsidiaries, this is repeated per entity. This is the stage where the GDS configuration problem (covered below) most often surfaces.
5. Onboarding
Onboarding brings the corporate's users onto the live platform: creating accounts, setting up profiles, configuring delegation relationships, and validating that each user type sees the right interface and permissions. Phased onboarding — a pilot group before full rollout — reduces risk, especially for large or multi-entity corporates.
6. Training
Finally, the corporate's travellers, arrangers, and approvers are trained on the tool. Training is not a formality: a tool that travellers find confusing is a tool they will route around, and off-tool booking defeats the entire purpose of the deployment. Effective training is tailored by user type — travellers need to book quickly, approvers need to act before ticketing deadlines, administrators need to manage the programme.
The GDS Configuration Problem TMCs Underestimate
A corporate booking tool is only as good as the content behind it, and that content flows through the GDS. Getting the GDS configuration right — the PCC setup, the certified workflows, the access to negotiated and private fares, the ticketing permissions — is one of the most common points where an implementation stalls. It is also technical, GDS-specific work that many TMCs do not have the in-house expertise to resolve alone. For the fundamentals of why GDS connectivity sits at the centre of the stack, see What Is GDS in Travel?.
This is the second area where a capable CBT partner earns its place. A vendor that helps the TMC work out the GDS configuration — liaising directly with Sabre, Amadeus, or Travelport during setup, sorting out PCC and certification issues, and making sure the right fares and ticketing permissions are in place — removes the single most common technical blocker to go-live. A vendor that leaves GDS configuration entirely to the TMC is leaving the hardest technical part of the implementation to the party least equipped to handle it.
The content and procurement side of this — which GDS, which NDC airlines, which LCC aggregators — is covered in Travel Booking Engine: A Buyer's Framework.
Asia-Pacific Specific Considerations
Implementing a corporate booking tool in Asia-Pacific carries some specific complications that single-market deployments do not face.
• Multi-entity, multi-market tenders — A regional corporate may tender for a tool that serves entities in Singapore, Malaysia, Hong Kong, and beyond, each with its own policy, currency, and local content needs. The implementation is effectively several implementations sharing one platform.
• Dual GDS setups — Many APAC TMCs operate across more than one GDS, which multiplies the configuration work and makes vendor GDS liaison more valuable.
• Local content and payment — Regional LCCs, local payment methods, and country-specific tax and invoicing requirements all have to be configured correctly per market during implementation.
• Subsidiary self-service — Where a holding company's subsidiaries each need their own self-service booking, the onboarding and training effort scales with the number of entities, not just the number of users.
Conclusion
Forecepts does not just hand TMCs a login. Its SWIFT CBT onboarding supports the TMC through demo, configuration, and collecting feedback from the corporate client, and includes hands-on help liaising with Sabre and Amadeus during GDS setup — addressing the configuration step that most often blocks go-live. Because Forecepts develops only travel technology and does not sell travel itself, its commercial interest is aligned with the TMC rather than competing with it. This level of support is available under a commercially negotiated arrangement. Other vendors take different approaches; the point is that implementation support, not just the tool, is what determines whether a deployment succeeds.
