- 行业: 酒店业
物业: 位于葡萄牙里斯本的一家180间客房的独立酒店，约60%的客人来自国外
挑战: 在不扩充员工的情况下提供一致的多语言客户沟通
解决方案: PolyTalk，一个自托管的语音翻译平台，用于实时客户与员工的对话
部署: 自托管，以保持客户数据在酒店自己的基础设施上
涉及部门: 前台、礼宾、客房服务、餐饮、客户服务
结果: 以前需要四分钟的入住对话，现在对于非英语客户只需不到九十秒，而以前需要两到三次电话才能解决的客房请求，现在通常在第一次就能解决
一目了然：
- 一个工作流程，六个面向客户的部门，不同情况没有单独的工具
- 没有新的硬件或IT改造，运行在酒店已经控制的基础设施上
- 客户音频和对话数据从未离开物业自己的服务器
- 从前台到五个部门的全面推广花费了三个月
问题：语言障碍正在减缓客户服务
前台的一位客人在提问中间切换到西班牙语，询问关于延迟退房的事。帮助她的工作人员只会说英语和葡萄牙语。片刻之后，她听到了英语的提问。她正常回答。客人在她说完下一个句子之前听到了西班牙语的回复。
这一时刻每周在接待国际客人的酒店中发生数十次，长久以来，这都是工作中最具干扰性的部分之一。
这家酒店距离里斯本的海滨仅几分钟路程，吸引了来自欧洲、中东、北美和亚洲的客人。大多数员工英语说得很好，但并不是每位客人都能说。
这种差距无处不在：
每当员工需要通过翻译应用程序解释付款细节或房间政策时，入住登记的速度就会减慢，而不是自然地交流。
礼宾请求暂停，直到有人找到会说客人语言的同事。
客房清洁和维护请求有时需要多次对话才能理解问题。
在紧急情况下，例如医疗问题或护照丢失，几乎没有时间在手机上输入信息。
这一切都不是服务失败。正如前台经理在审查前台工作流程时所说的：
"我们的员工知道如何照顾客人。他们只是并不总能理解他们。"
这个区别很重要。酒店并不需要更多的多语言员工。它需要现有的员工能够清晰地实时沟通，无论客人说哪种语言。
为什么翻译应用程序和客人消息传递不足以解决问题
酒店已经使用了两种工具：一个用于确认和提醒的客人消息平台，以及用于实时对话的手机翻译应用程序。
消息平台在其设计的用途上运作良好，发送信息，而不是进行对话。翻译应用程序才是真正的瓶颈。客人会问一个问题。工作人员会打开一个应用程序，讲出内容，等待，然后大声朗读翻译。一个简单的交流本应花费十秒钟，却接近一分钟，而这种来回的交流让对话感觉像是交易，而不是个人交流。
核心问题不是缺少某个功能。缺少的是一种工具类别，旨在进行实时的口头对话，而不是书面信息或应用程序中介的交流。
实时语音翻译如何融入日常酒店运营
酒店首先在前台部署了PolyTalk，然后将其扩展到面向客人的各个部门。关于那次延迟退房的工作流程很简单：
客人说 → 语音实时翻译 → 员工用自己的语言听到回复 → 员工回应 → 客人用自己的语言听到回复。
没有手机。没有尴尬的停顿。没有寻找双语同事。对于客人和员工来说，互动感觉就像正常的对话，而不是翻译练习。
融入每个部门，而不仅仅是前台
一旦前台试点证明成功，三个月内在其他面向客人的团队中引入了相同的工作流程。
同样的模式出现在客房服务中。一位客人用普通话打电话询问空调故障。值班的客房服务员只会说葡萄牙语，但她像客人说的是自己的语言一样轻松地接受了请求。一个技术人员在一小时内到达，没有回拨前台，也没有同事被拉去翻译。
部门 | 发生了什么变化 |
前台 | 非英语客人的入住时间从平均4分钟降至90秒以内 |
礼宾部 | 客人可以直接询问餐厅或交通推荐，无需等待翻译 |
客房服务 | 房间请求和维护问题的平均对话次数从2-3次减少到第一次就解决 |
餐厅与用餐 | 员工可以解释饮食选择并接受特殊请求，而无需猜测 |
客户服务 | 在整个住宿期间的常规请求由值班人员处理，而不仅仅是多语种员工 |
紧急情况 | 医疗请求和旅行中断得到了这些时刻所需的清晰处理 |
每个部门都使用相同的工作流程。员工不需要为每种情况学习不同的工具。
为什么自托管部署在这里很重要
客人的对话涉及支付细节、护照信息和个人请求。这使得部署成为一个真正的决策，而不是事后考虑。
酒店选择了自托管的设置。语音识别、翻译和语音合成都在酒店自己的基础设施上运行。没有任何内容经过第三方云服务。
PolyTalk的自托管堆栈使用三个组件：faster-whisper用于语音转文本，一个兼容Ollama的翻译模型，以及Piper用于文本转语音，所有这些都在酒店自己的环境中运行。
对于一个每周处理数十种语言的敏感客户数据的物业来说，将这些数据保留在内部并不是可有可无的事情。这是他们能够采用的供应商与无法采用的供应商之间的决定性因素。
实际情况的变化
在第一次前台部署后的三个月内，差异在日常中变得可见，而不是戏剧性的：
前台员工不再需要打断附近的同事来帮助进行多语言对话。
客房清洁和维护请求在一次对话中解决，而不是两次或三次。
曾经需要在翻译应用中输入的客人开始正常说话，员工注意到对话再次感觉个人化，而不是交易性的。
服务不再依赖于谁在值班。任何员工都可以处理任何客人的对话。
正如前台经理总结的那样：
"我们不是为了语言而招聘的。我们是为了款待而招聘的。这只是让这一点以应有的方式展现出来。"
为酒店选择实时语音翻译软件：需要注意什么
评估的酒店经理实时语音翻译在选择平台之前应该考虑四个实际问题：
它处理实时对话，还是仅仅处理消息？
客人消息和语音翻译解决不同的问题。你可能需要两者。它适合你当前的工作流程，还是创建一个新的工作流程？
员工不应该需要学习针对国际客人的单独流程。音频去哪里了？
如果客人的对话中包含支付或身份证明信息，仅云处理可能无法满足您的隐私要求。自托管或混合部署让您对此有发言权。它能在各部门之间扩展而无需重新培训每个人吗？
仅在前台工作的工具只能解决问题的一小部分。
PolyTalk 围绕这四个优先事项构建：实时语音翻译、最小化工作流程干扰、自托管部署，以及一个在每个面向客人的部门都能工作的单一平台。 这也是我们更广泛的酒店业用例 概述。
想知道这个工作流程如何适合您的物业吗？
看看 PolyTalk 如何实现实时语音翻译 → 而不改变您员工已经工作的方式。
常见问题
在这家里斯本的酒店，非英语客人的入住时间从平均4分钟降至90秒以内，一旦前台员工使用了 PolyTalk。
客人消息是为书面、计划的沟通、确认、提醒和更新而构建的。实时语音翻译是为现场、面对面的口头对话而构建的，这正是这家酒店最大的瓶颈所在。
是的。PolyTalk支持自托管部署，因此语音和翻译处理可以保留在酒店控制的基础设施上，而不是通过第三方云服务传递客人的音频。
客房服务和前台看到了最快、最可衡量的改善，客房服务请求的平均对话次数从两到三次减少到一次。礼宾和餐饮在员工适应工作流程后也随之改善。
寻找实时对话支持（不仅仅是书面翻译）、适合现有操作的工作流程、对敏感客人数据的部署灵活性，以及覆盖每个面向客人的部门，而不仅仅是前台。
不完全是，这两个解决不同的问题。PolyTalk并不替代您的预订引擎或PMS，它与之并行运行，处理国际客人在您员工面前时发生的实时对话，从入住到退房。
最有效的方法是将实时语音翻译与现有的客人消息工具结合起来，用于书面更新。语音翻译使员工和客人在入住、礼宾请求和服务电话期间能够使用自己的语言交流，而无需增加多语言员工。