决定要不要付款的细节，很少在第一屏
旅游产品是一组条件，不是一个价格。客人还会用不止一种语言来问。
行程、集合点和“不含”分在不同网址
客人可以喜欢照片，仍然不知道 8:15 站在哪里，或者午餐要另付。
天气和取消是挡住付款的问题
“下雨还去吗”和“取消费从哪天开始”决定订不订。埋得太深，标签页就会关掉。
儿童票和行李规则容易被说松
年龄段和行李限制是精确的。把它们四舍五入，比引用页面更糟。
国际客人在读一份给本地人写的网站
他们要的仍是同一套出发事实。翻译整个网站是另一项工作；根据已发布页面回答，是这里的工作。
留位之前人们会问的话
这些出现在付款前的那一小时。规则如果已经写在页面上，就不需要实时库存接口。
- 下雨还出发吗？
- 儿童票多少钱？
- 集合地点在哪里？
- 取消费从什么时候开始？
- 可以带大行李箱吗？
- 几点出发？
- 午餐包含吗？
- 这周六还有位子吗？
把行程、集合点和取消条件收进一次回复
客人应该能跨着你已经写好的页面来问，再到预订页确认位子。
抓取每一页会改变答案的内容
行程、集合地图、价格表、携带物品和取消条款都要有。只有相册回答不了这些。
加上客人已经会收到的 PDF
能选中文字的条款或出发说明可以加到符合条件的方案。助手不能编造文件里没有的天气决定。
用访客的语言，但依据仍是你的资料
多语言回复必须来自你连接的页面和文档。这不是承诺每个网址都有正式译文。
空位交到你公布的预订步骤
网站没有实时空位，聊天就不能编。指向预订页或联系方式，让客人自己确认。
实时空位和当天天气决定留给经营者
已发布的规则可以重复。当天的运营不能猜。
- 不要说某个出发日还有位子，除非你连接的页面写了这个状态
- 不要在出发当天决定取消或照常，如果网站只给了一般雨天政策
- 不要改儿童年龄段、行李限制或包含项目
- 不要承诺取消表以外的退款金额
从“看起来不错”到“下单”之间的核对
预订留在你的预订页。聊天是下单前的核对。
一家人为明天的票算价
两个大人和一个孩子。回复使用已公布的年龄段和价格，再链到那个日期的预订页。
预报有雨
页面如果写小雨照常、暴雨停止，那就是答案。聊天不会看明天的雷达。
带着箱子还要赶火车的客人
行李限制和集合点来自出发说明，如果“不含”会改变计划，那一句也要带上。
出发前一周想取消
按你公布的日期引用费用表。聊天不办理取消。
抓取旅游页面，再用客人真正会发来的问题测试
规则如果在 PDF 或第二个网址里，只有一张漂亮落地页是不够的。
- 01
创建旅游站点
小组件上用客人认识的经营者名称。
- 02
抓取行程和条款
包括集合点、价格、包含项目和取消页，不只是照片故事。
- 03
客人依赖出发 PDF 时再上传
文字必须可选中，并与当前在售行程一致。
- 04
问候语针对具体细节
邀请对方问天气、儿童、行李和集合地点。
- 05
装到行程页和预订页
最后的疑虑出现在这里。
- 06
测一个周六空位问题
回复应把人送到预订页，而不是编造余位。
用页面确认雨天安排，而不是用实时看板
示例引用政策，并拒绝实时空位。
下雨还去吗？周六还有位子吗？
行程页写明小雨照常出发，只有暴雨预警才停止。这里没有列出周六余位，请到预订页确认那一天。
预订页