For a B2B travel portal, our recommended evaluation starts with two people: an agent trying to complete a sale and an administrator supporting the account. Ask the provider to show both sides of the same booking. That makes it easier to spot a missing handover between what the agent sees and what the operating team needs to do.

Write the essential requirements before the demonstration and use invented customer details in the provider’s approved test environment. The checklist below is a proposed buying framework. It is not a claim that every portal includes each function.

Check accounts and access

Ask how an agency is approved, how users are added and how access is removed. If you need different roles, prepare a simple list of what each person should be allowed to see and do. Then test those permissions with the relevant accounts.

Include an attempt to open another agency’s record through the normal test interface. Agree the permitted test method with the provider. The purpose is to verify separation of access, not merely confirm that a role setting appears on a screen.

Compare the actual offer shown to the agent

Use a product and rate arrangement relevant to your business. Ask the provider to explain the amount visible to the agent, the amount visible to the end customer where applicable and the information retained for the operator. Check the applicable currency and conditions at each stage.

For hotels, verify the property identity before comparing offers. GIATA’s MultiCodes documentation illustrates how different supplier property codes can be linked to a common hotel identifier. Follow that with separate checks of the room, meal basis and terms, because your comparison needs the complete offer. Source: GIATA: how MultiCodes identifies hotels

Test a successful booking and an exception

The normal journey should show the selected offer, the final booking instruction, the recorded supplier result and the information returned to the agent. Record the supplier reference and the portal’s reference so the team can trace the transaction in both places.

Travelgate’s documented flow separates Search, Quote and Book, with Quote refreshing the selected rate and conditions. Use the equivalent stages for your proposed suppliers when preparing tests. Do not assume an earlier search result alone establishes the final offer. Source: Travelgate: checking a hotel offer before booking

Ask for an unavailable offer and an interrupted response as well as a successful sale. Check who can find the affected record and what action is safe next. The agent should receive a useful status, while the support team should have enough evidence to investigate.

Check retry and notification handling

If a connection supports idempotency, ask how repeated requests are recognised. Stripe documents idempotency keys as a way to retry without repeating an operation, but support and rules are provider-specific. Ask for the actual travel integration’s documented behaviour. Source: Stripe: idempotent requests

Where booking changes arrive as notifications, ask how the portal identifies and processes them. Expedia’s Rapid notification service is one example of event messages for booking updates. Test the receiving workflow, including an update that requires someone’s attention. Source: Expedia Group: booking notifications

Follow the booking into documents and finance

Ask the agent to retrieve the customer documents and the administrator to locate the corresponding operational and financial records. Have finance specify the checks for your commercial model, including commissions, credit arrangements or supplier settlement if relevant.

For an illustrative test, amend a booking after the first documents have been prepared. Check which record is current, which outputs need replacing and how the team sees any resulting action. This tests coordination across the workflow without assuming the portal performs every task itself.

Ask about the operating limits

For API-based connections, request the provider’s limits and recovery guidance. Stripe’s documentation shows that limits can apply to an account, an endpoint or concurrent operations. Use this as a reason to ask precise questions, not as a numeric limit for the portal you are evaluating. Source: Stripe: API rate limits

Agree how to test expected demand, which support route applies and who is responsible when a supplier connection fails. Include those responsibilities in the buying record alongside the software functions.

Make the decision from an evidence sheet

For each essential requirement, record the scenario, expected result, actual result and any unresolved gap. Separate functions demonstrated now from work proposed for later. Give each gap an owner and decide which must be resolved before agents begin using the portal.

The Travelgenix B2B travel portal overview is a starting point for a product discussion. Bring this checklist and your intended agency model to the demonstration so the assessment stays tied to the work you need to complete.

Written and updated by Travelgenix. Sources checked on 16 October 2026. Worked examples and checklists are editorial illustrations and recommendations, not customer results.