For system integrators bidding for mining, energy and aid accounts, and the vendors that bid with them

Bid the whole integration, SAP to seat.

UnityTrip is the component that lets a system integrator bid a client's whole travel programme, from the SAP posting to the seat on the company aircraft, instead of the commercial half the booking tool can see. The other half, owned, wet-leased and dry-leased aircraft, vessels and camps, is a structural requirement for energy, mining and aid clients and sits outside what the booking tool, the TMC platform and the expense stack produce. An integrator who bids without it leaves the middleware between the booking tool, the charter manifests and the ERP to be built and maintained by someone, usually at the integrator's margin.

UnityTrip is one booking engine, one PNR and one policy layer for fleet and commercial travel, feeding bookings, manifests, policy decisions and spend upstream into the client's consolidation as structured events and webhooks. Policy is enforced in the engine, not in the integration layer, so each exception that would have needed hand-written glue is a line in the client's policy document instead. The connection to SAP is in production: master data in over RFC each day, postings for approved claims back through middleware, and SAP stays the master ledger.

• The scope you can price. Standardised integrations such as GDS and NDC are built once; the SAP connection is personalised to each client's configuration; onboarding is configuration measured in weeks, not a migration. The bid is a governed capability, not point-to-point plumbing.
• The margin you keep. The middleware an integrator would otherwise build and maintain between the booking tool, the manifests and the ERP is replaced by the model, and the maintenance tail that follows hand-written glue does not exist.
• The record the client keeps. The ERP keeps the ledger. Concur or the booking tool keeps commercial content and expense claims as the parent; UnityTrip is the child for the leased and chartered legs, takes the approval from the parent and hands the leg and its cost allocation back.

What an integrator can bid with it

• One programme, one bid. Ledger to seat, commercial and company-operated, under one policy and one record, rather than the half the booking tool can book.
• A policy engine in the bid, not a coordinator. Priority, quotas, booking windows, displacement and penalties executed deterministically with the reason recorded, which is what the ten evaluation questions a tender should ask are written to test.
• Proof the buyer can check. The public policy schema, the API and webhook specifications and the evidence page. The pattern has run within Amadeus Cytric and Amex GBT environments; the integrations in production are SAP, Thomalex, Elina PMS, Chevin FleetWave, and Stripe and Paystack for payments. The systems named are work UnityTrip has built and delivered, not partnership endorsements.
• Under your name or ours. UnityTrip runs as a white-labelled hub under the integrator's delivery, or as a named component. Either way UnityTrip owns the booking engine, the policy enforcement and the audit trail underneath.

Put together, that is a bid that covers the whole of a client's movement and spend, on an integration already running in production, with the governance in the engine rather than in the engagement.

What an integrator can ask the client

One question: which legs of a rotation does your booking tool not book, and who reconciles them today? If the answer is a desk with a spreadsheet and the charter invoices, that is the half of the programme the bid can now cover.

What it needs from you

One decision, taken with the client: which system is the parent for commercial content and expense claims, and which holds the ledger. Everything else is configuration. Where the engagement starts with a programme review, the review reads the client's record with you and returns the ten largest recoverable opportunities ranked by money, which is the scope of the bid.