Not ready yet
Products lack stable identifiers, current sale status, consistent dates or a clear pricing basis. Discovery can map the gaps, but recommendation output must not be presented as saleable inventory.
TripCopilot integration readiness
Can your product data support an honest recommendation journey?
A useful prototype needs a bounded, representative product sample with stable identity, saleability and commercial meaning. This guide helps a travel business and its technical team identify gaps before any connector or timescale is promised.
Do not upload data here. This public page does not accept inventory. Do not send API keys, credentials, private supplier links, customer records or confidential commercial files through the website enquiry form.
Three honest readiness levels
Ready for a prototype
A representative slice has stable IDs, valid dates, duration, departure and occupancy rules, current status, a traceable price basis and an authoritative customer action.
Production candidate
The source also has defined freshness expectations, deterministic eligibility, duplicate handling, monitored failures, consent-aware handoff and accountable data ownership.
Minimum representative sample
What must be understood before ranking begins
Field names differ between platforms. The point is to identify an authoritative meaning and validation rule for each concept, not to force every supplier into one invented API shape.
| Area | Evidence needed for a bounded prototype | Fail-closed behaviour |
|---|---|---|
| Identity | Stable product, departure, property, room or package identifiers and the relationship between them. | Reject missing IDs and quarantine collisions instead of merging records by name. |
| Sale status | Active, paused, sold-out or withdrawn state from the authoritative system. | Anything unknown, stale or unavailable cannot be recommended as saleable. |
| Dates and duration | Departure or stay dates, nights, booking window and timezone meaning where relevant. | Reject malformed dates and products outside the customer's valid window. |
| Departure and transport | Departure points, transport mode, connection or transfer facts and included baggage where sold. | Do not infer a departure, direct service or inclusion the source does not state. |
| Party and occupancy | Adult and child limits, child-age rules, room occupancy and single supplements. | Exclude combinations that the source cannot price or accommodate reliably. |
| Board and inclusions | Normalised board basis plus authoritative inclusions and separately payable components. | Never promote a less inclusive basis as satisfying a firmer customer requirement. |
| Price | Amount, currency, pricing basis, occupancy assumption, inclusions, checked time and source. | Do not show a price when its basis or freshness cannot be established. |
| Product fit | Destination, trip format, accommodation, pace, family evidence, accessibility evidence and specialist attributes. | Missing evidence remains unknown; it is not silently converted into a positive fit. |
| Customer action | Validated enquiry, adviser, appointment or booking destination tied to the authoritative product ID. | No generated or guessed product link, lead destination or completed action. |
| Freshness and provenance | Source version, last successful update, expected cadence, owner and correction path. | Stop or degrade the affected product when the freshness contract is breached. |
Coverage, not volume
Choose a sample that can expose failure
Include genuine variationUse several destinations, dates, durations, boards, room or occupancy patterns, price points and product types.
Include unavailable recordsA prototype must prove that paused, sold-out, malformed and stale products are rejected rather than merely showing happy paths.
Include identity collisionsSimilar names, repeated hotels, alternative departures and package variants test whether stable identifiers survive the mapping.
Include difficult customer briefsTest no-match, tight budgets, child ages, specialist seasons, accessibility needs and conflicting preferences.
A useful first conversation
What to establish before sharing files
- Authoritative systems: where product identity, price, availability and customer actions actually come from.
- Supported access: documented API, scheduled feed, CMS export, database view or another approved route.
- Representative boundary: a small but commercially meaningful slice that can be isolated and withdrawn.
- Success criteria: agreed inclusion, exclusion, ranking, no-result and adviser-handoff scenarios.
- Data responsibilities: owner, refresh cadence, retention, corrections, credentials and incident handling.
- Commercial boundary: how campaigns or preferred products may influence credible ties without overriding customer fit.
Share the checklist with your technical teamThe CSV lists the discovery fields and minimum evidence without asking for any private data.
Download readiness checklistNext step
Discuss a bounded inventory fit check
Start with your business type, current product source and the customer outcome you want. A data sample or system access should only follow an agreed secure route after the first conversation.