在接入前约定归属与责任
确认账户由谁持有，客户谁负责咨询，工作室是否仅承担安装与维护。不要默认为客户代答业务问题。把恢复访问、人员离职和服务结束后的安排写进双方已有交接记录，使客户理解技术支持与业务服务的区别。
如果客户需要长期控制自己的接收端，围绕这一需求安排连接与交接。不要共享个人密码，或让一个员工的私人联系方式成为唯一可恢复入口。产品支持多个网站，不代表所有客户资料应在没有责任约定的情况下混合处理。
逐站命名与配置，避免模板式复制
项目名称应能区分品牌、用途与实际域名。逐站检查接入地址、界面语言和负责人，并记录哪些公开页面使用组件。共用模板要避免重复安装；不同客户的网站也不应因复制失误显示错误的品牌或语言。
虚构例子：工作室维护一家商店和一家服务公司。商店的问题由店主回复，服务公司的预约咨询交给其负责人。即使由同一工作室安装，也不能把两站的咨询当成同一个队列随意处理。
把验收写成可重现的步骤
每站用无个人信息的测试问题核对访客端、Telegram 接收端和回复回程。测试内容写明项目名称，检查答案出现于对应网站对话。手机端还要检查窗口不会遮挡导航、购买按钮或预约操作。
交付时提供客户能再次执行的检查步骤，说明哪里管理网站、怎样找到接入资料、哪一位负责人检查咨询。不要只交付截图：截图不能证明接收和回复链路仍然工作。若客户改变域名或模板，应重新验证真实页面。
后续维护和退出要有边界
约定工作室处理哪些技术问题，客户负责哪些内容和人员安排。遇到通知异常，先核对接入和设置，再看设备通知，不要把真实客户消息转到无关测试群。业务回复失误也不能简单归因于组件故障。
合作结束时检查客户是否能够使用账户、管理网站和维持自己的接收端，再处理工作室不再需要的访问。不要把清理访问与删除客户历史混为一谈。任何资料迁移或删除都应按双方实际约定进行，不能从普通交接推断产品具备任意导出能力。
比较与选择
| 判断事项 | 建议做法 | 需要核对 |
|---|---|---|
| 项目归属 | 安装前明确账户与运营负责人 | 技术维护不等于业务代答 |
| 多站配置 | 逐站核对名称、语言与地址 | 避免复制错误 |
| 交付验收 | 让客户重做网站到 Telegram 往返 | 截图不代替完整对话 |
| 结束合作 | 核对客户访问和接收端 | 按约定处理多余访问 |
开始前，先把这些问题说清楚
工作室一定要替客户回复吗？
不一定。接入维护和业务回复可以由不同人负责，关键是事先约定并让客户知道自己的职责。
多个网站怎样避免混淆？
使用可辨认名称，逐站核对配置，并在回复前查看来源网站与页面背景。测试应覆盖每个站点。
交接时必须导出全部历史吗？
不能假设任何导出方式都存在。先明确实际资料需求与可用能力，再按约定处理访问、连接和必要记录。