ThinQ.travel
Home / Platform User Manual
Platform documentation

ThinQ Travel Platform User Manual

A public operational guide to platform modules, controlled workflows, security rules, validation, approval boundaries, and current release behaviour.

Current release rule

Visible does not always mean operational.

A control or module may be connected, guided, preview-only, or planned. Confirm its release status before treating it as a production system of record or an authorised write action.

01

Purpose and scope

The ThinQ Travel Platform is a governed workspace for travel product, contract, mapping, rate, distribution, policy, and operational-intelligence workflows.

  • Use the platform to make ownership, readiness, validation, and blockers visible.
  • Treat connected records as operational data and preview surfaces as guidance only.
  • Follow your organisation’s approval and segregation-of-duties rules.
02

Access and security

Access is browser-based and identity-controlled. Use an authorised individual work account and a current browser.

  • Never place passwords, API keys, session cookies, or tokens in notes, screenshots, exports, or support messages.
  • Use approved source-connection workflows for credentials and restrict them to authorised administrators.
  • Sign out when using a shared device or when access is no longer required.
04

Module availability

Each module is labelled as connected, guided, preview, or planned. That status determines what can be relied on operationally.

  • Connected: reads or writes an approved operational source.
  • Guided: supports structured work but may require export or review.
  • Preview or planned: demonstrates intended behaviour and is not a system of record.
05

Properties

Use Properties to review portfolio master data, completeness, mapping quality, operational exceptions, and readiness signals.

  • Filter by status or exception before reviewing records.
  • Open a property to inspect identifiers, content completeness, and operational context.
  • Resolve source conflicts before treating a record as authoritative.
06

Product-definition builder

The guided builder structures product-definition work, validates required inputs, and prepares controlled output for review.

  • Select the intended product and market scope.
  • Complete required hotel, room, rate, and distribution inputs.
  • Resolve validation errors before generating an export or submitting for approval.
07

Contracts

Contracts provides a structured view of agreement lifecycle, worksheet inputs, validation state, versions, and publication readiness.

  • Create or open the correct contract record before editing.
  • Confirm ownership, currency, market, validity, and source documentation.
  • Use validation status—not visual completeness alone—to determine readiness.
08

Contract metadata and date logic

Contract dates must represent the commercial agreement accurately and must not overlap in ways that create ambiguous operational output.

  • Check selling, travel, booking, and cancellation windows independently.
  • Confirm inclusive and exclusive date boundaries before publication.
  • Record exceptions explicitly rather than relying on free-text assumptions.
09

Contract worksheet

The worksheet organises rooms, occupancies, rates, supplements, restrictions, and validation into a controlled working view.

  • Complete required fields before adding dependent pricing or policy rules.
  • Keep source-document references attached to the relevant section.
  • Use comments for context, not as a substitute for structured data.
10

Rates and seasons

Rates and seasons define the commercial price periods and the conditions under which they apply.

  • Avoid gaps and unintended overlaps in season coverage.
  • Confirm currency, board, room, occupancy, and market scope.
  • Review calculated outputs before approval or publication.
11

Occupancy and additional passengers

Occupancy rules define permitted adult and child combinations and any additional-person pricing logic.

  • Keep booking-age rules separate from pricing-age bands.
  • Validate maximum occupancy against room configuration.
  • Document exceptions that require downstream handling.
12

Supplements and reductions

Use structured supplements and reductions for mandatory or conditional price adjustments.

  • Specify whether the rule is per person, per room, per stay, or per night.
  • Set eligible dates, markets, occupancies, and stacking behaviour.
  • Review interactions with base rates before publication.
13

Save, validate, approve, and publish

Saving preserves work. Validation checks structure. Approval confirms accountability. Publishing releases an authorised version.

  • Do not treat Save as approval or publication.
  • Resolve blocking validation findings before requesting approval.
  • Publish only the approved version and preserve the rollback reference.
14

Audit trail and documents

The audit trail records meaningful state changes, ownership, decisions, and supporting material.

  • Attach the correct source document to the correct record.
  • Use versioned evidence for material commercial or operational changes.
  • Do not upload secrets or unrestricted sensitive data.
15

Mapping

Mapping reconciles internal, reference, and supplier identifiers and surfaces confidence, conflicts, and unresolved exceptions.

  • Review low-confidence and conflicting matches before acceptance.
  • Preserve the source and rationale for manual overrides.
  • Do not merge records solely because names are similar.
16

Availability, rates, and inventory

The ARI view supports date-level inspection of availability, rates, inventory, restrictions, and stop-sale state.

  • Confirm the source timestamp and market context.
  • Distinguish displayed observations from authorised write actions.
  • Escalate persistent source discrepancies rather than manually masking them.
17

Distribution

Distribution controls define channel access, market scope, sales windows, and operational restrictions.

  • Confirm the intended channel and market before enabling access.
  • Use global stop-sales only through the authorised approval path.
  • Record the effective time and owner of material changes.
18

Policies

Policies centralise cancellation, payment, billing, legal, and operational terms with review status and audit context.

  • Use structured terms wherever the platform supports them.
  • Flag conflicting or incomplete source language for review.
  • Keep legal approval separate from operational data entry.
19

Governance

Governance covers users, roles, secure sources, permission boundaries, approvals, and audit events.

  • Apply least-privilege access.
  • Review privileged access regularly and remove it when no longer required.
  • Never bypass an approval boundary to accelerate a routine task.
20

Insights and diagnostics

Insights surfaces operational patterns, anomalies, comparison views, and diagnostic evidence to support decisions.

  • Treat insights as decision support unless explicitly labelled authoritative.
  • Verify source freshness and scope before acting.
  • Preserve diagnostic evidence when escalating an issue.
21

Partners and bookings

These areas may appear as roadmap or preview modules. Their presence does not mean that operational workflows are enabled.

  • Use only features explicitly labelled connected or released.
  • Do not enter production data into a preview surface.
  • Check release notes before relying on new capabilities.
22

Tooltips and help

Use tooltips for field-level guidance and this manual for broader operational rules and workflow boundaries.

  • Report unclear or outdated guidance with the page, field, and screenshot.
  • Do not include credentials or sensitive data in support evidence.
  • Use the latest published manual version.
23

ThinQ Desk Support

ThinQ Desk is a persistent enterprise support agent accessible from every screen. It responds to operational questions with text and optional voice output, and can be dragged, resized, or minimised freely.

  • Use Desk Support for contract rules, scoring guidance, season dates, and configuration questions.
  • Enable or disable voice output from the panel header controls.
  • Drag the widget to any screen position; it will stay within viewport boundaries on resize.
  • Minimise to the floating launcher when switching focus; unread messages show a badge count.
  • On mobile, the panel adapts its height and width automatically.
24

Help Center and documentation access

The Help Center provides structured access to the platform user manual, keyboard shortcuts, investor documentation, and live support status from the header and profile menus.

  • Open the Help Center from the question-mark icon in the header navigation.
  • Use 'User Manual' for module-by-module operating guidance.
  • Use 'Keyboard Help' to view available shortcuts for the active workspace.
  • The 'Platform Support' entry shows a live status indicator and opens ThinQ Desk.
  • Admin users can access the Investor Product Deck from both the help and profile menus.
25

Mobile and tablet behaviour

The platform adapts its layout across mobile (below 767px), tablet (768px to 1199px), and desktop (1200px and above) breakpoints.

  • Contract lists display as swipeable stacked cards on mobile instead of data tables.
  • Navigation collapses into a categorised two-column grid accessible from the hamburger menu.
  • Text scale controls are available in both the header and the mobile navigation panel.
  • The Desk Support widget resizes to fit mobile viewports and repositions automatically.
  • Landscape orientation is detected and may adjust layout behaviour on supported devices.
26

Troubleshooting

Start with identity, source freshness, validation state, and release status before escalating a platform issue.

  • Refresh the page and confirm the active account and browser session.
  • Record the module, action, timestamp, expected result, actual result, and non-sensitive evidence.
  • Contact hello@thinq.travel when an issue persists or affects controlled execution.