One brief produces your website, booking engine, AI team, payments and CRM
One brief becomes a bookable website, a booking engine, an AI operating team, payments and a CRM that share a single record of every trip. Once it is running, you change it the same way you started it: by telling it.
Website, WhatsApp, app, payments and operations read and write the same record.
Prices, refunds, deposits and supplier commitments wait for the right person.
No booking is confirmed on a promise, a screenshot or a chat message.
Dates, pages, prices and rules change from a sentence, inside your approval rules.
Not a website builder. An operating system where every surface reads and writes one trip record.
The pilot assembles proven building blocks around one shared travel core instead of starting from zero.
Once the platform is live, the operator does not open six admin panels. They tell the workspace what should change, in plain words, in their language. Content and availability apply at once with a record and an undo. Anything that touches money, policy or access is previewed and waits for the right person.
Tell the workspace what should change, the way you would tell a colleague. Try one of the examples below or write your own.
Rule-based demo of the behaviour, computed in your browser. In the product, the same instruction is interpreted by the AI roles, previewed on every surface, and gated by the same rules.
Text, photos, translations, availability, capacity and assistant tone. Live at once, recorded, one-tap undo.
Prices, promotions, deposits, refund policy, retiring a product, access. Previewed on every surface, then approved or rejected by the right person.
A vague instruction gets a question back, never a guess. Nothing changes until the detail is there.
Most operators already own a website, a chat app, a payment link, a spreadsheet and a voucher template. What they do not own is the connection between them. That gap is where quotes drift, deposits go unchased and travellers get four versions of one trip.
Six modules, one core. Each module is useful on its own; together they share products, policies, traveller context, money rules and evidence, so nothing has to be typed twice.
A multilingual website, phone-first booking and WhatsApp that sell the same products at the same prices, because they read the same core.
Products, seasons, capacity, extras, pricing rules and vouchers, with a booking flow built for trips rather than shopping carts.
Named roles for sales, itinerary, pricing, booking, operations and guest care, working from approved knowledge and the same trip record. Tell them what should change and they change it, inside your approval rules.
One record per traveller and trip: the enquiry, the proposal, every payment, the supplier work and the reasoning behind each decision.
Deposits, balances, refunds, commissions and margins tied to verified payment events, so a booking is never confirmed on a promise.
Approval policies, source citations and an audit trail of what the system did, what it blocked and what it handed to a person.
The brief is the only input. Everything after it is reviewed by the owner before it becomes real, and every phase has to prove itself before the next one starts.
Describe destinations, products, travellers, languages, money rules and who delivers the trip. Plain words are enough; the box above shows how little it takes.
The brief becomes a first version of your storefront and a launch plan: systems in order, AI roles, the points where a person must approve, and the questions still open. You review and change both.
The pilot proves one revenue loop with real travellers and real payments. Channels, markets and apps expand only after that loop holds.
Nine steps, one trip record. Each role hands structured context to the next, while money and commitments stay supervised.
A traveller writes on the website or WhatsApp. The message opens one trip record with language, party and dates.
The sales role asks only the missing questions, answering from approved product knowledge.
The itinerary role drafts days, stays and options that fit the brief and the season.
Seasons, margins and policies are applied. Anything outside policy is flagged, not sent.
The owner or sales lead edits and approves before anything reaches the traveller.
A deposit is collected. The booking confirms only on a verified payment event.
Requests go to hotels, guides and drivers. Commitments are confirmed by the operations lead.
Pre-trip answers, day-of changes and follow-up, in the traveller’s language, on the same record.
Every payment, refund and supplier cost lands on the trip record. Finance closes the day clean.
A website quote, a WhatsApp answer, a payment and a supplier hand-off are the same trip seen from different sides. Keeping them on one governed core is what stops four versions of the same booking.
Read the product architecturePDF · 16 pages · 50 KBEvery connector lives behind the verified connector edge. Names show the connectors intended for the pilot and for later phases, so you can see where your current tools fit. They describe the plan, not existing partnerships.
Collect deposits and balances. A booking confirms only on a verified payment event.
Every channel reads and writes the same trip record, in the traveller’s language.
Publish products and live availability once. Stop selling the same seat twice.
Net rates, partner logins and live availability for resellers and hotel desks.
Turn confirmed trips into pickups, guide briefs and supplier requests.
Reconcile every payment, refund, commission and supplier cost.
Measure which channel books, not just which one clicks.
Your data stays yours. Import it, export all of it, any time.
Logos and names are trademarks of their owners and indicate intended connectors only. Where a brand does not license its mark for this use, a neutral initial is shown instead.
Keys and tokens are stored encrypted per operator. Nobody, including the AI roles, ever sees them in plain text.
A real test payment, message or sync runs and its result is recorded. If it fails, the connector stays off.
Only then does the connector go live. The date, the test result and who approved it stay on the audit trail.
The system may draft anything. It may only commit what policy allows, and every commitment leaves evidence a person can check later.
Answers and proposals come from approved business knowledge. When the source is missing, the question goes to a person instead of becoming a guess.
Prices outside policy, refunds, discounts and supplier commitments pause for the right person, every time, with the decision recorded.
Each operator has an isolated workspace, its own knowledge, encrypted credentials and connectors that are switched on only after a verified test.
A dated trail keeps drafts, simulations, verified events and real external outcomes apart, so “done” always means something specific.
The default gate set every pilot starts with. Owners can add gates; they cannot remove these.
| Action | Approved by | Recorded |
|---|---|---|
| Send a price outside the published rules | Owner or sales lead | Draft price, rule breached, decision |
| Confirm a booking | Verified payment event | Payment reference, amount, time |
| Issue a refund or accept a cancellation | Owner or finance | Policy applied, amount, reason |
| Commit a supplier, guide or driver | Operations lead | Request, confirmation, cost |
| Answer without an approved source | Handed to a person | Question, missing source, who took it |
| Change a price, deposit or policy from chat | Owner or finance | Instruction, interpreted change, approver |
| Connect an external system | Owner, after a verified test | Connector, test result, date |
The vision is broad on purpose. The first release is deliberately narrow, and each phase ends with proof, not a date.
Turn the owner brief into journeys, modules, data, roles, policies and a launch sequence everyone has read.
Prove one end-to-end path with real travellers: enquiry to approved proposal, deposit, confirmation and supplier hand-off.
Add mobile, deeper supplier connections, partner distribution and operating intelligence once the pilot holds under load.
Anyone can bolt a chatbot onto a booking site. The hard part, and the moat, is one model of the business that every surface, role and payment obeys.
Products, markets, policies and commercial rules are described once and configure every generated surface.
The enquiry, proposal, payment, supplier work and guest support stay on one trip record from first message to review.
Every AI role and every channel inherits the same approval, evidence and tenant-isolation rules. None can opt out.
Operational outcomes improve templates and defaults, and never change policy behind the owner’s back.
A concept earns trust by being precise about its own state. These are the questions owners and technical leads ask first.
Same promise, different object. Those tools turn a description into a generic web app that you then have to run yourself. Foxes Travel OS turns a brief into a travel business: a bookable storefront and, behind it, one shared record of products, prices, travellers, payments and operations, with human gates on money. This page previews the storefront and the plan from your brief in the browser. In the pilot, the same brief provisions the real thing on your domain, connected to your payment and messaging accounts, and you keep changing it by chatting.
No. It is a working concept: a product definition, an experience and technical architecture, a governance model and a pilot plan. This page and the PDF exist so owners, technical leads and pilot operators can agree on what to build before anything is built.
A launch blueprint: which systems to launch first, which AI roles to switch on, where a person must approve, the pilot sequence and the questions still open. The demo at the top of this page is a rule-based preview of that. A real blueprint is written with you and reviewed before building starts.
No. You tell the workspace what should change, in plain words, in your language. Text, photos, translations, availability and capacity apply immediately, are recorded and can be undone in one tap. Anything that changes what a traveller pays, who gets a refund, or who has access is previewed on every surface and waits for the right person to approve. The chat demo above shows the exact rules.
It is designed not to. Every instruction is interpreted into one scoped change and previewed before anything happens. Vague instructions get a question back, not a guess. Money, policy and access changes never apply without approval, and every change keeps a before-and-after record with undo.
Not in the pilot. Every quote, itinerary and commitment is reviewed by a person before it is sent, and any answer that has no approved source is handed to a human. Autonomy is widened only where the evidence trail shows it is safe.
It never leaves your browser. The blueprint is computed on this page by fixed rules; nothing is stored, sent or used to train anything.
Destination management companies, tour operators, excursion and activity sellers, transfer companies and cruise agents. The first pilots are shaped around Egypt and its main inbound markets, which is where the design decisions come from.
Because the revenue loop has to be proven once, end to end, before it is copied to another surface. A bookable website with real payments proves products, prices, policies and operations in weeks. Apps then reuse the same core rather than starting a second version of the trip.
Map your business at the top of this page, download the blueprint, read the architecture PDF, and bring both to your next conversation with the Foxes Technology team. A pilot begins with the brief, not with a contract.
Map your brief, download the blueprint it produces, read the architecture, and bring both to the pilot conversation. That is how the first Foxes Travel OS operators will start.