案例研究:甲米府旅行社全套自动化系统

1. 客户情况

甲米府的中型旅行社,每天接待 50-80 位客人,提供 snorkeling、sunset cruise 与跳岛游 (4 islands、Hong islands、Phi Phi)。团队由 1 位老板 + 3 位行政 + 约 15 位合作的导游与船长组成。

discovery 阶段遇到的问题:

LINE 预订溢出: 通过 LINE OA 接收每日 100+ 条咨询和预订,3 位行政轮班回复,9:00-11:00 仍跟不上。
Excel 排期: 船期表在 Google Sheets 中跨团队共享,没有锁机制 — 旺季每周 2-3 次重复预订。
无实时库存: snorkeling 与跳岛游有时共享同一艘船,但 Excel 不维护依赖,行政只能靠记忆。
银行转账 + 凭证: 客户转账到 SCB 后用 LINE 发凭证,行政打开银行 App 逐笔查,每张 5-10 分钟。
取消混乱: 取消/改期记在笔记本上,未同步到 Excel,多次被投诉。
税务/月报困难: 月末核算账目要 2 整天。

客户试过 2 个现成方案:

TourCMS: 行政端 UX 是西方风格,泰国团队不熟练,且不支持 PromptPay。
Bokun: 约 $800 USD/月 + 每笔佣金,超出预算,而且多产品库存需要变通处理。

明确目标: 将行政耗时从每天 6 小时 → 1.5 小时,并把超售锁定为 0。

2. 为什么通用方案不奏效

PromptPay 是关键卡点: 现成 SaaS 如 TourCMS、Rezdy 只支持信用卡和 Stripe,但 80% 的泰国客户通过 PromptPay/银行账户转账,系统需要按订单动态生成 QR 并自动核验凭证。
多产品库存盘根错节: 多个产品共享资源 (同一船、同一导游、大船上的同一座位),把 tour 视为独立产品的通用系统无法建模,需要把 “resource” 与 “tour product” 分开的 schema。
行政能理解的泰语 UI: 35-50 岁的行政团队主要用 LINE,从未用过英文 CRM/SaaS dashboard,需要”像 LINE 一样”的 UI — thread-based,全泰语,无术语。

3. 我们的方案

技术选型:

Next.js 14 (App Router) — 行政仪表板 + 客户预订页放在同一代码库
tRPC + Prisma + PostgreSQL — 端到端类型安全,schema 迁移容易
Cloudflare Workers — 用于 LINE webhook + 凭证核验队列的 edge functions
PromptPay QR library (promptpay-qr) — 按订单动态生成 QR
Google Cloud Vision API — 泰国银行凭证 OCR
LINE Messaging API + Webhook — 聊天机器人和确认推送

向老板呈现的 ROI:

选项	第 1 年	第 2 年	第 3 年
SaaS (Bokun ~$800/月)	~$9,600	~$9,600	~$9,600
定制 (一次性 ~$9,500 + 托管 $200/月)	~$11,900	~$2,400	~$2,400

第 8 个月回本 — 之后定制每年便宜 ~75%,且是公司的资产。

方案的 4 大支柱:

实时库存引擎 — WebSocket 在新预订时广播,所有浏览器会话立即看到座位数更新 + 数据库级别的锁防止竞态
PromptPay 自动化 — 按订单生成 QR,通过 OCR 核验凭证 (Google Vision 读取账号 + 金额 + 时间戳)
LINE webhook 聊天机器人 — 回复模式明确的 FAQ (价格、出船时间、集合点),复杂预订流转到行政
手机优先行政仪表板 — 行政有 70% 时间在用手机,UI 设计从移动断点开始

Discovery 流程: 在写代码前,我们的团队要求做整整一天 (8:00-18:00) 的 shadow-day,坐在每位行政旁记录所有 pain points。结果发现行政有 40% 时间花在”找历史预订”上,因此在 dashboard 加入 search-first 设计。

4. 周计划

第 1-2 周: Discovery 与架构

与行政团队 shadow 一天
与老板 + 行政主管利益相关者访谈
数据库 schema 设计 — 15 张表 (bookings、tours、resources、schedule_slots、customers、payments、slip_verifications、line_messages 等)
用户旅程映射 4 个角色: walk-in customer、repeat customer、agency、owner

第 3-5 周: 后端核心

Next.js + tRPC 脚手架 + Prisma migrations
认证 (admin + agency tier)
预订领域逻辑 + 库存锁
支付集成: SCB Easy Net API + PromptPay QR generator
关键单元测试: 预订竞态、库存溢出

第 6-8 周: 前端与实时

行政仪表板 UI (泰语优先,移动端断点优先)
面向客户的预订流程 (3 步: 选 tour → 填资料 → 付款)
通过 WebSocket 的实时库存 (Cloudflare Durable Objects)
日历视图 + 拖拽改期

第 9-10 周: LINE 与 OCR

LINE webhook 设置 + 意图分类 (规则 + GPT fallback)
12 个高频问题的 FAQ 聊天机器人
预订确认推送 + QR code
OCR 凭证核验管线 + 人工审核队列

第 11 周: 迁移与 UAT

Excel 导入工具 (导入最近 6 个月遗留预订约 2,400 条)
与 3 位行政 UAT — 发现 8 个 critical bug (3 高、5 中),4 天内全部修复
基本渗透测试 (SQL injection、auth bypass)

第 12 周: 上线

软上线: 通过 feature flag 50% 流量 3 天
行政团队培训 4 次 (每次 1 小时),全部泰语
正式上线 + 前 24 小时监控仪表板
知识转移文档 + runbook

5. 遇到的问题

OCR 准确率仅 87%: SCB/Krungthai 标准格式凭证读取良好,但手机银行截图凭证 (尤其旧版本 Kbank app) 信心度低 — 解决:对信心度 <90% 的凭证加入 人工审核队列,行政一键确认,每张平均 15 秒 (比原来的 5-10 分钟大幅缩短)。
项目中期出现 scope creep: 第 7 周老板要求新增 agency tier pricing (向送客的旅行社分佣) — 不在原 scope。团队评估需 +1 周,签订明确合同补充 (+25,000 泰铢,时间线推迟 5 天),老板在开工前同意 — 关键是不做免费,否则会打开 scope creep 的口子。
行政团队接受慢: 前 2 周仍有 1 位行政每日 3-4 次呼叫 hotline — 解决:8 部泰语视频教程 (每部 2-3 分钟) + 1 个月的 hand-holding (4 小时响应 SLA),第 4 周降至每周 0-1 次。

6. 上线后效果 + 持续

第 1 个月的效果:

行政耗时: 6 小时/天 → 2 小时/天 (-67%)
重复预订: 2-3 次/周 → 0
LINE 响应时间: 4 小时 → 8 分钟 (聊天机器人处理 60% 咨询,行政专注预订)
凭证核验: 5-10 分钟/张 → 15 秒/张 (OCR 自动确认 87%)
月末报表: 2 天 → 30 分钟 (从 dashboard 导出)

经验总结:

泰国旅行社需要”像 LINE 一样的”工具 — 最初我们设计了 Notion 风格的干净 UI,行政说”看起来太简洁,不知道哪个重要”。我们调成 card-heavy + 熟悉的 emoji,接受度立刻提升。
Shadow-day 最划算 — 下场跟班 1 天获得的洞察比 5 轮需求收集会议更多。
人工审核队列不是失败 — 用户反而喜欢,因为有”可控感” — 教训是 100% 自动化并不总是目标。

持续合作: 我们以维护服务方式继续支持 每月 8 小时,涵盖 bug 修复、小功能 (上季度新增了 voucher 系统 + 预订页多语言 EN/CN)、安全补丁与监控。上线第 6 个月开始讨论 phase 2 — 新增 supplier portal 让船长通过手机为客户 check-in。