Chiho AI
当客户可以进入预设的自动对话时，选择 Telegram 机器人。当主要工作是在同事之间协调回复时，选择共享收件箱。当团队需要跨对话保留长期关系上下文、优先级和跟进工作时，选择 Telegram CRM。然后检查产品如何连接 Telegram：类别名称本身并不说明它能访问哪些聊天。
这些方式可以重叠。共享收件箱可以使用机器人连接；CRM 也可以包含收件箱和自动化。先确定必须支持的对话，再评估围绕它们的工作流程。
**发布方披露：**Chiho 发布本指南，并提供 Telegram CRM。本文比较的是方式，不是独立的产品排名。平台和供应商文档于 2026年九月7日 检查；Chiho 的描述依据当前源代码和文档核查。以下示例仅用于说明，不宣称客户绩效成果，也未声称实际操作测试过竞争产品。
比较各方式应完成的工作
将这份决策清单作为起点。分配、历史导入、导出和批准控制等能力取决于具体实现；请在你实际打算使用的产品和连接中验证。
机器人：预设入口或自动互动
- **适合从这里开始的情况：**客户可以联系机器人提问、提交请求或按引导流程操作。
- **需要检查：**支持的互动、升级转交路径，以及机器人实际收到的消息。
- **不能据此推断：**能访问销售人员已有私聊、提供团队工作队列，或保留长期客户记录。
- **运营工作：**必须有人负责机器人应用或供应商配置、故障和更新。
Telegram 将命令、按钮和 Mini Apps 作为组织机器人互动的方式写入文档。这些只是构建模块；应用仍需决定存储什么，以及何时由人工接手。见官方机器人功能。
共享收件箱：协同处理传入对话
- **适合从这里开始的情况：**多位同事处理同一批传入请求，需要知道下一位回复者是谁。
- **需要检查：**分配、内部备注、同时回复、交接，以及支持的 Telegram 对话类型。
- **不能据此推断：**连接每位员工的账号、完整导入历史聊天，或提供销售管道。
- **运营工作：**明确负责人、值守覆盖、升级转交，以及同事离职时的处理方式。
一个类别重叠的具体例子是：respond.io 的 Telegram 文档描述了连接 Telegram 机器人并通过其平台回复。目前文档称不支持 Telegram 群组。这只能证明该文档所述集成的情况，不能作为所有共享收件箱或所有 Telegram 机器人的规则。不要直接假设入围供应商能支持基于群组的客户流程，先检查其连接说明页。
CRM：关系上下文与下一步行动
- **适合从这里开始的情况：**难点在于确定哪段关系需要关注、承诺过什么，或同事接手前需要知道什么。
- **需要检查：**持久备注、标签或优先级、任务、团队上下文，以及返回对话的链接。
- **不能据此推断：**采用特定 Telegram 访问模式、提供无限历史记录，或自动发送消息。
- **运营工作：**约定团队如何记录下一步行动，并保持客户记录更新。
只有记录能帮助人采取行动，CRM 才有用。更广泛的选择标准见 Telegram CRM 购买指南。本文侧重在选择产品之前选择方式。
比较功能前先检查对话访问
需要向供应商提出三种不同的连接问题。
**普通机器人连接：**哪些对话会到达机器人？Telegram 的机器人常见问题说明，机器人接收发给它的私信，群组可见性则取决于隐私模式、管理员身份等设置。添加机器人并不会让它成为已登录的同事账号副本。
**已连接的商业机器人：**账号持有人授权了哪些聊天和权限？Telegram 支持已连接的商业机器人，它们接收商业消息更新，并代表已连接用户执行允许的操作。收件人设置和授予的权限很重要。不要将其视为普通独立机器人，也不要假设每家收件箱供应商都实现了这种机制。
**已连接账号：**登录的是哪个 Telegram 账号，导入哪些可访问对话，保留什么？Chiho 的账号连接路径通过 mtcute 使用 MTProto。这与机器人令牌集成不同。能访问账号仍不足以证明全部历史消息或 CRM 字段已成功导入。
请供应商用获准使用的样本做一次演示：已有私聊、客户群组，以及新传入对话。逐一记录是否支持、显示哪些历史记录，以及回复会使用哪个身份。未测试的情况标为未知。一个私聊中的成功演示不能证明群组或旧历史记录的情况。
区分访问、团队共享与操作许可
这些是独立的决定：
- **Telegram 访问：**连接能否读取目标对话？
- **工作区访问：**哪些同事能看到导入的上下文和内部备注？
- **操作许可：**谁或什么能够修改记录、发送消息或更改群组成员？
在 Chiho 中，个人与团队 CRM 数据使用不同的上下文。同事能访问共享 CRM 信息，并不等于他是原始 Telegram 聊天的参与者。依赖交接前，先测试接手同事的视图。团队流程指南介绍了周边流程。
AI 自动化又增加了一层权限。不要假设每次智能体写入都会暂停等待批准。Chiho 对邀请成员和退出群组要求保存预览并获得批准；多收件人消息预览需要批准，单收件人批准也取决于配置。其他一些写入可在已授予权限和客户端控制下直接执行。使用写入工具前，请查看 AI 智能体连接指南和实际授权设置。技能描述的是流程，并不授予访问权限。
三种团队选择示例
有新公共联系渠道的支持部门
客户愿意开始专门的支持对话。先评估通过机器人连接的共享收件箱。测试同事能否从自动化接手、看到之前的交流，并避免未回答的请求被遗漏。如果客户需要在已有群组中获得支持，在评估收件箱功能之前，先将群组支持列为必须通过的条件。
在已有客户聊天中工作的销售团队
团队需要找出现有关系中的未完成承诺。先选择连接方式支持这些对话的 CRM。在示例记录中写下客户请求、下一步行动和已确认负责人。使用按优先级跟进指南评估工作队列。新的机器人入口仍可能帮助受理，但它本身不能满足已有聊天的要求。
有可重复受理流程的运营团队
团队在开始工作前需要少量结构化回答。机器人可能足以完成受理。如果请求之后需要人工队列或长期关系记录，则评估向收件箱或 CRM 的交接。测试同一个请求在流转中是否仍可识别，以及交接失败是否对操作人员可见。
进行小规模选择练习
这是评估规程，不是经过测量的研究。使用合成数据或你获准测试的对话。不要仅为探索功能就连接生产账号。
准备三个示例请求：简单问题、未解决的承诺，以及缺少细节的交接。为每个候选方案记录：
- **连接：**普通机器人、商业机器人或已连接账号；预期回复身份。
- **覆盖范围：**所需私聊和群组；最早可见的示例消息；已知导入缺口。
- **协调：**谁负责请求、另一位同事如何接手，以及内部上下文存放在哪里。
- **操作：**哪些修改需要批准，哪些可以直接执行。
- **退出：**如何撤销访问，以及保留记录和导出会怎样处理。
- **依据：**在测试中观察到、文档中声明，还是仍然未知。
演示前设定通过条件。例如：“接手同事无需让发送者复述，就能从共享记录找出尚未解决的客户问题。”不要因为供应商称自己提供 AI 或团队协作就判定通过。记录确切结果和未解决的限制。
什么时候评估 Chiho
如果你优先考虑将已连接的 Telegram 对话整理为 CRM 上下文和跟进工作，并可选使用智能体流程，就可以评估 Chiho。当前实现区分个人和团队记录，支持 CRM 整理；这些源代码依据并不承诺你的账号已完成同步，也不承诺所有请求的流程都可用。
如果主要需求是简单的机器人受理流程，先测试这个较小的要求。如果团队需要跨多个消息渠道协同值守，则将文档明确支持这些渠道的共享收件箱产品纳入候选。根据所需对话及演示出来的流程匹配程度选择。
评估 Chiho 时，创建账号，从小规模获准样本开始。检查对话覆盖，准备一次客户交接，并与接手同事验证下一步行动。在决定导入哪些客户上下文之前，阅读隐私政策。