场景一 · 跨语言沟通
读懂客户的话，再确认自己的回复
来信中一个型号、否定或交期读错，就可能带来错误承诺。辅助翻译帮助阅读；润色只改善表达，不能替员工决定价格、交期或业务条件。
- 客户原文
- 中文辅助阅读
- 中文起草
- 客户语言草稿
- 人工确认后发送
合成内容示例 · 非真实邮件、软件界面或 AI 运行结果
原文中的限制不能被“润色”掉
Please quote 20 units of model MH-X2. Do not ship before 15 November.中文辅助阅读：请报价 20 台 MH-X2。不要在 11 月 15 日前发货。型号 MH-X2、数量 20、单位、否定和日期都需与原文逐项核对；年份未知，不自行补全。
中文回复草拟：我们已收到需求，将核对报价；交期另行确认。这不是承诺已经备货或同意交期。
We have received your request and will check the quotation. The delivery schedule remains to be confirmed.译成客户语言后仍是草稿。员工核对收件人、条件和附件后再发送；若润色，必须保留同一事实和承诺范围。
公司内部有人工邮件翻译与 AI 辅助实践；这不证明全部场景已验收，也不是公开部署脚本附带的完整模块。附件翻译、WhatsApp 和自动主动开发不能据此宣称已公开可用。
原文、业务记录与人工复核的边界 →场景二 · 客户与业务历史
客户是谁、谈过什么、下一步是什么
- 来源与联系方式
- 核对企业和联系人
- 沟通与需求
- 商机和负责人
- 报价与订单背景
同一家企业可能有多个联系人，一封邮件也不一定代表新商机。先保留原始来源，再由人确认身份与需求，避免误合并或把不确定内容直接写成正式业务事实。
报价发生修订时，记录版本、条件、确认责任和对应需求。进入订单后，再核对销售与采购协作的实际范围，不把“有销售对象”写成“出运、质检和收款全部已自动完成”。
客户、销售和采购对象有 Odoo 基础；茂亨公司有内部实际使用。公开安装环境究竟开放哪些模块和权限，仍须按版本验证。
一条业务信息链
从询盘到订单，先让信息与责任接得上
客户从网站、平台、邮件或其他渠道出现后，团队需要知道：谁是客户、谈过什么、谁负责下一步、报价与订单依据是什么。MORHON 围绕这些关系持续适配，而不是声称所有渠道和动作已自动同步。
保留来源与需求，由人确认客户身份和接收责任。
把公司、个人与原始邮件上下文区分开，避免误合并。
核对版本、条件、承诺和当前状态，保留可追溯背景。
按实际版本衔接采购；收款、售后和复购等后续范围持续完善。
这是一条业务组织路线，不是当前公开下载包的完整功能清单。可用模块、权限与集成须按具体部署核验。
功能与状态
哪些有平台基础，哪些仍需验证？
Odoo 提供相关基础业务对象；MORHON 的实际启用、配置和验收范围依版本而定。
茂亨公司有内部使用实践；邮件身份、翻译和资料写入仍强调来源与人工确认，不能当作公开脚本附带模块。
网站、平台和社媒是上游接触点。自动接入、营销归因、完整出运或收款流程不能据此视为现成功能。
逐项状态与证据见能力与状态；公开仓库当前提供的是固定 v7.0 部署脚本和安装说明，不是公司内部定制的完整导出。
企业资产与团队协作
人员变动时，业务上下文仍应留在企业
交接不只是导出联系人，还要确认原始沟通、当前需求、最新报价、未完成承诺、账号权限、接手责任与验收。数据整理和迁移从脱敏小样、备份与回滚开始，不能把不确定记录一次性写入正式系统。
先画清资料来源、接收人、记录位置和去重规则；并非每个渠道都需要实时自动打通。
报价、订单和采购之间保留责任与状态，让接手者能够回到已核对的业务背景。
场景三 · 有理由、有边界的客户跟进
先有营销事件，再选择合适的客户与渠道
- 新品 / 库存活动 / 公司事项
- 为什么联系
- 相关客户
- 可用渠道
- 草拟与翻译
- 人工审核
- 记录结果
客户是否相关、有没有适用的联系方式、该渠道是否已退订，都要先核对。没有邮箱就排除 Email；不能因为有手机号或社媒账号便默认可以营销。各渠道的授权和停止联系规则分别保留。
这是开发与规划方向，不是已开放的操作台。个性化营销、WhatsApp、附件翻译和 AI 结果分析尚待验收；没有自动群发或一键获客按钮。
营销事件与可审计跟进 →先用现有工具，还是测试 MORHON？
如果记录量小、责任清楚、资料能统一备份，现有表格仍可继续使用。当客户关系、沟通历史、报价订单采购和分权交接已成为反复出现的难题，再用合成数据评估 MORHON 是否适合。不要因为看到系统页面就直接迁移真实客户数据。