Everything you need to onboard a new client end to end. Follow the steps in order. When in doubt, the three golden rules below cover 90% of issues.

The three golden rules

1. Every client needs their own unique, real email. Never reuse an email across clients (it is how the system knows who is who). Deploying a known email updates that person.
2. Deploy = Save. Nothing is saved until you press Deploy. Any edit, big or small, needs a Deploy.
3. Test in Incognito (Ctrl + Shift + N). It always shows the very latest, so you never chase a cached old version.

Onboard a new client, step by step

1. Open Deploy Romy. Left menu → Deploy Romy. If you are editing an existing client, go to Clients and click Edit on their row instead.
2. Import the documents. Click Import documents and select all of the client’s booking PDFs at once (e-tickets, hotel and transfer vouchers, the meeting schedule). Romy reads and merges them. You can keep importing more; each one adds to the trip.
3. Review “What Romy read”. Check the flights, hotels, activities. Delete duplicates with the ✕. Relabel any meeting with the dropdown (meeting / dining / experience). In the Documents box, rename a document or remove one.
4. Fill the details. Client name(s); a unique Email; a short unique Personal link (their app address); the Trip name shown big on their app (e.g. “ILTM 2026”); Destination; Departure and Return dates; Travel style & interests (Romy uses this); a Spotify playlist link (optional; a default plays if blank).
5. Deploy. Press Deploy Romy → Build their app. This saves and builds their app, fills their SOS, weather and checklist, and stores the documents.
6. Preview. On Clients, click Preview to open their app exactly as they will see it. Check the itinerary, weather, SOS, documents and checklist.
7. Send the welcome. On Clients, click Send welcome to email them the branded intro with a one-tap sign-in link.

What fills automatically

• Itinerary — a day-by-day, grouped by city, built from the documents.
• Weather — a live 7-day forecast for every destination city.
• SOS — local emergency numbers per country, the Australian embassy, the DFAT 24/7 line and your Travel Project line.
• Checklist, Documents, Spotify, Profile — all populated from the trip.
• Romy — knows the whole trip and proactively offers to fill gaps (like a missing airport transfer).

If something looks wrong

• Old data or blank: open it in Incognito, or clear site data once on the app site. The app now auto-updates after that.
• “Personal link is already taken”: that email already has a client. Use their email to update them, or a different unique email for a new client.
• Empty app: you deployed before importing. Import the PDFs (the panel should show the trip), then Deploy.
• Need to add more later: Clients → Edit → import more PDFs or change fields → Deploy.

A client moves left to right: Discover → Enquire → Quote → Book (human) → Travel. Each stage is owned by one arm; Safari Portal is the operational spine they all read and write. One shared foundation and one shared supplier core underneath.

The three arms

Shared foundation: Netlify (hosting + git-push deploys) · Supabase (Postgres, auth, storage, RLS) · Claude (extraction/AI) · Resend (email).   Shared supplier core: HotelBeds · Stuba · Mozio · (Room-Res being added).

Hello Romy — the engine (server-side Netlify functions)

Romy's tools (ElevenLabs server tools): check entry requirements, remember about guest, notify designer, get insurance quote (parked), suggest experiences (parked) — all secured by a shared secret header + a client_ref variable so she can only ever act for the guest in front of her.

Foundation & integrations

Security model — the pattern that repeats everywhere

• No secret ever reaches the browser. The client gets only the Supabase publishable key; every supplier key and the service role live only in serverless function env.
• All privileged writes go through functions using the service role. RLS + column grants stop client roles writing sensitive fields.
• Tenant isolation is derived server-side from the staff row, never trusted from the request.
• Travellers see only their own trip. RLS keys on their profile row; documents are private via owner-scoped signed URLs.
• Romy's tools are authenticated by a shared secret header; the guest is identified by a client_ref variable, so she can never target another guest. The designer's email for escalation is resolved server-side, never exposed.

Maxi re-prices every refundable watched booking once a day across suppliers and emails the designer when the rate drops past its threshold. It never books — you rebook in your own agent login. Add a booking below (a HotelBeds code lets Maxi re-price it; without one it can only be tracked).

Bookings with a supplier final-payment date (e.g. Expedia "Pay later"). Pay by = 5 days before the due date. Red = pay now or overdue, amber = within 7 days. Mark each paid once done.

Runs each certification search against the live Stuba HAPI (HotelSearch / RegionSearch) and shows the raw response to screenshot for the certifier. The list below is an editable template — set each case's dates, occupancy and region/hotel IDs to the exact values in the cert doc (or send me the doc and I'll lock them in). Requires STUBA_API_KEY + STUBA_BASE on the studio site.