Horizon Travel
An all-in-one travel management system that replaces fragmented WhatsApp coordination with automated itinerary delivery, calendar sync, and proactive client alerts.
一站式旅行社管理系統，用自動化行程交付、日曆同步與主動通知取代碎片化的 WhatsApp 溝通。
Opens in new tab · Installable PWA
Full Page Showcase
完整頁面展示
Why travel agencies are losing client trust to fragmented communication
旅行社為何因碎片化溝通而失去客戶信任
A travel agent manages dozens of simultaneous trips. Every client has a different flight, hotel, and itinerary. When a flight changes at 2am, the agent must notify 8 clients manually — one by one, via WhatsApp. Messages get missed. Calendars don't update. Clients show up at the wrong terminal.
旅行社代理同時管理數十個行程。每位客戶有不同的航班、酒店和行程。當航班在凌晨 2 點更改時，代理需要逐一手動通知 8 位客戶——通過 WhatsApp。消息被遺漏。日曆未更新。客戶走錯航廈。
The problem isn't that agents are bad at their jobs — it's that their tools force them to act as human notification systems. Every itinerary change requires manual coordination across multiple channels. WanderSync automates that entire layer so agents can focus on planning, not pinging.
問題不是代理工作不努力——而是他們的工具強迫他們充當人工通知系統。每次行程變更都需要跨多個渠道手動協調。WanderSync 自動化整個層級，讓代理專注於規劃，而不是不停傳訊息。
The Stack & the Hard Parts
技術棧與解決難題
Next.js with SSR is the right choice because the client booking portal needs SEO, and server-side rendering keeps itinerary data out of the client bundle for security. Node.js handles the Google Calendar API orchestration and notification dispatch on the backend. The notification layer uses a webhook pattern rather than polling — changes propagate in seconds rather than on the next client request.
Next.js 配合 SSR 是正確選擇，因為客戶預訂入口需要 SEO，而伺服器端渲染也讓行程數據遠離客戶端捆綁包以確保安全。Node.js 在後端處理 Google Calendar API 編排和通知分發。通知層使用 Webhook 模式而非輪詢——變更在數秒內傳播，而不是等待下次客戶請求。
All itinerary changes flow through the Admin panel, never directly from clients. This creates a full audit trail (every change logged with timestamp + agent ID) and prevents partial updates where the client's calendar drifts ahead of the agent's records.
所有行程變更都通過 Admin 面板流轉，而非直接來自客戶。這創建了完整的審計追蹤（每次變更記錄時間戳和代理 ID），並防止客戶日曆超前於代理記錄的部分更新。
When an agent updated an itinerary while a client simultaneously opened the portal, two Google Calendar API writes fired in parallel — one from the agent save, one from the portal's onMount sync. The Calendar API created two events instead of updating the existing one. Fixed with idempotency keys: every itinerary item has a stable UUID used as the Calendar event ID, making any write an upsert rather than a blind create.
當代理更新行程且客戶同時打開入口網站時，兩個 Google Calendar API 寫入並行觸發——一個來自代理保存，另一個來自入口的 onMount 同步。Calendar API 創建了兩個事件而非更新現有事件。解決方案是冪等鍵：每個行程項目有一個穩定的 UUID 用作日曆事件 ID，讓任何寫入都是更新插入而非盲目創建。