Group Travel Decisions Beyond the Nightly Rate.
Acquire a group and business travel application that connects actual room demand, hotel quotes, policy and a lasting decision record. Groups and Teams and Business Travel are both included, in one workspace, at one price.
Teams · A group or sports travel operator, an organization that travels, or a vertical software company.
- Asking price
- Price on Request
- One-time acquisition.
- Availability
- Available
- No acquisition has been agreed, and none is in progress.
This is an application asking price. It is not a valuation of a business: there is no revenue, no customer base and no trading history behind it, and none is implied by the figure.
Teams comparing two hotel quotes on Group Fit and data confidence rather than on nightly rate. Photographed from the application running against a seeded database. The packaged standalone Teams repository, which contains both Groups and Teams and Business Travel.
Two workflows, one application, one price.
Both arrive together. Neither is a separate acquisition, and neither requires acquiring any other application on this site.
The roster is never the travelling party, and a room count built from roster size is wrong before it is calculated.
Roster and event
Organizations, rosters, events and travel parties are modelled separately, because a travel party is a different list from a roster and is derived rather than assumed.
Who is actually travelling
Household responses arrive at different times. A household that has not answered shows as pending, never as zero demand.
Confirmed room demand
Hotel demand is derived from the real household and travel-party context, not from how many names are on the roster.
Quote comparison on total known cost
Room capacity, total known cost, the cost components that are missing, straight-line distance to the farthest venue, and evidence confidence. A quote whose pricing inputs are incomplete stays unknown rather than becoming zero.
An institutional decision
The decision and the factors behind it persist, so the following season starts from a record rather than from somebody's memory.
The same workspace, a different question: whether a trip is justified, within policy and approved.
A work objective
A trip exists because of what it is for, and that reason is the record everything else attaches to.
Commitments
What the trip actually obliges, held against the objective.
Policy
Policy versions are explicit, so a decision can be read against the policy that was in force at the time rather than today's.
Approval
An approval workflow with its own history, scoped to the workspace and requiring real membership to act.
Receipts and reporting
Receipts recorded against the trip, with reporting and audit history over them.
Three screens, in the order you meet them.
- Screen 1 of 3, showing
- Screen 2 of 3
- Screen 3 of 3
The roster is kept separate from who is actually travelling, because for a group those are never the same list.
What you are actually buying, in four states.
No readiness percentages. A capability either runs in the version being sold, waits on something you supply, waits on rights we do not hold, or is not there at all.
Demonstrated in This Version
Present and working in the packaged repository this sale delivers, confirmed against its source.
Both workflows are in one application at one price
Groups and Teams and Business Travel share a workspace. No separate acquisition of Family Travel is required, and neither mode is sold apart from the other.
Hotel demand derived from household context, not roster size
Travel parties are distinct from rosters, and room demand follows the households that answered.
Group Fit is the minimum across known dimensions
Unknown dimensions remain explicitly unknown, and if no dimension is known the result is unknown rather than a default.
Quote economics only ranks totals it can actually compute
A missing pricing input stays unknown. It never becomes zero, and a quote missing components never wins by being cheaper than one that disclosed them.
Quote evaluation persists the factors behind its explanation
The explanation is read back from what was actually scored rather than written separately.
Business Travel objectives, commitments, policy versions, approvals and receipts
With reporting and audit history over them. Application services require acting and editing membership, and every event is scoped to its workspace.
A roster that does not out minors
The minor-status badge was removed and a regression guard exists to keep it removed. The repository's own listing facts document still described it as present; this page follows the code and the guard.
Requires Buyer Configuration
In the delivered code, but inert until the buyer supplies an account, a credential, or a deployment of their own.
Hosting, a database and file storage
No hosted deployment is recorded for the standalone repository. Blob storage is undemonstrated there.
Email delivery
Live email has not been demonstrated in the standalone repository, and the hotel quote flow is an email flow.
A hosted model provider for document extraction
Hosted-model extraction of a quote document is undemonstrated in the standalone repository.
Social sign-in
Configured but not demonstrated in the standalone repository.
A phone layout fix
The shared navigation is a single fixed-height flex row, and the handoff's phone-overflow finding remains plausible from the current code. It has not been remeasured in a browser. A buyer demonstrating this to parents on their phones should fix it first, and nobody should present phone readiness as proved until they have.
Operational hardening
Rate limits are per process. There is no observability or backup integration.
Requires External Licence
Needs rights VoyantIQ does not hold and cannot transfer. The buyer licenses it themselves or does without it.
Hotel supply and negotiated rates
The application requests and compares quotes. It carries no inventory, no rate agreement and no supplier relationship, and none can be transferred.
Not Included
Not in the delivered version. Listed here so it is read before the purchase rather than discovered after it.
Booking supply or managed travel operations
No inventory, no agency service, no travel desk. HotelPlanner, Engine and Navan all operate at that layer; this application does not.
Parent payments
There is no collection, no split payment and no family billing.
Tournament registration or group chat
Neither is modelled.
Commercial billing, a public API or a webhook system
None of the three exists in the standalone repository.
The VoyantIQ company, brand, platform or accounts
Not the parent brand, the shared platform, provider contracts, domains, trademarks, hosting accounts, credentials or any participant data.
What this page does not claim.
Each of these is a sentence a page like this could easily say about Teams, and the reason it would be wrong.
Venue distances are straight-line estimates
Calculated as haversine straight-line miles to the worst-case venue. They are not driving times, routed distances or verified journeys, and every surface that shows one says so beside the number.
Getting quotes for a team is not the distinctive part
HotelPlanner already markets group quote requests and negotiated rates, Engine markets side-by-side group proposals with contract help and consolidated invoicing, and Navan markets policy and approvals with its own supply. What is specific here is the owned decision record linking household demand, multi-venue context, known total cost and uncertainty.
One transfer checker did not prove every platform
The transfer checker skips browser tests because its container lacks the second browser's system libraries. Local and continuous-integration browser runs are a separate evidence source, and the pack should be read as both.
What you receive
Built on Next.js, TypeScript, PostgreSQL, Drizzle ORM. A transfer check runs against a clean clone before any of it changes hands.
Full application source, commit history included
Group stay evaluation and travel readiness engine
PostgreSQL schema and migrations
Hotel quote request and document extraction flow
Architecture and decision documentation
What you can look at first
A seeded group event: travelling households against a roster, hotel quotes compared on total known cost, and the missing components named rather than estimated. Venue distances shown are straight-line.
A deployed, standalone preview of the packaged application is not published. One is arranged during diligence, against the actual sale commit, rather than kept running here. A reasoning scenario and a deployed preview are different things, and naming both is better than letting one stand in for the other.
The recorded transfer evidence, dated.
Recorded 24 to 25 October 2026.
- 373 unit tests recorded as passing.
- Four browser tests across two viewport projects.
- 62 tables in the shipped schema.
- An import-independence check.
- No hosted deployment, commercial billing, public API, webhook system, observability or backup integration on record.
These are the repository's own recorded results from that date, not a fresh verification. The transfer process is re-run against the actual sale commit before any handover, and the current results are what the acquisition agreement refers to.
The schema and test counts shown elsewhere on this site — 62 tables, 373 passing — were measured on 30 October 2026. A skipped test is never counted as a passing one.
None of this establishes product quality, demand or revenue, and the pack itself says so. It establishes that the application builds, migrates and passes its own tests from a clean clone.
Teams is available.
A request starts a conversation. It is not a reservation, it holds nothing, and it commits neither of us to anything.