您的 CRM 能完成大部分工作，但有一项任务总会转到电子邮件或电子表格中。先弄清这项任务，再决定该改什么。调整设置、增加受支持的功能、连接其他工具和更换系统，解决的是不同问题。
您的 CRM 可能很适合管理联系人、销售机会和后续跟进。可一到续约，折扣需要有人批准，工作便转到了电子邮件里。
这说明续约任务值得调查，但还不能据此判断应调整设置、增加受支持的功能、连接其他工具，还是更换 CRM。
先观察一个人如何完成这项任务，包括其中不顺手的环节。记下他们输入什么、去哪里找信息、由谁决定，以及大家如何知道任务已经完成。另列一份清单，写下 CRM 目前做得好的事。任何改动都应保留这些能力。
设想一个假设情景：销售代表准备续约方案，经理批准任何折扣，代表再将商定的报价发给客户。目前，代表把续约信息复制到邮件中，之后再将决定录入 CRM。
大家的抱怨很直接：“我们总在催审批。”但原因还需要仔细查。
不同答案会导向不同改动。增加一个界面解决不了员工找不到任务的问题。连接系统也解决不了续约被存成错误记录类型的问题。
请管理员或供应商用您实际购买的产品版本，以及员工实际拥有的权限，演示整个任务。更高价版本的演示并不能证明您目前的订阅包含这些功能。
先检查设置和培训。现有字段、视图、任务或权限设置或许就能填补缺口。让销售代表和经理按说明实际操作。如果他们能正确完成任务，下一步可能是改善界面或培训，而非开发。
如果确实缺少某项能力，再研究以受支持的方式扩展现有产品。确认供应商支持哪些扩展接口、您的版本允许什么、谁来维护新增功能，以及产品更新后如何测试。销售页面上写着“可定制”，只能作为提问的起点。
微软的 模型驱动应用指南 提供了一个范围明确的例子：建立数据模型、定义流程、构建应用和设置安全角色是不同的工作。它描述的是该平台，并不能证明每种 CRM 都提供相同的控制能力。
针对这个假设的续约场景，决策记录可以列出以下三个选项。每个选项都说明何时可能适用，以及做决定前需要什么证据。
先测试现有设置和培训。如果仍无法完成任务，再评估在 CRM 内增加续约审批的受支持扩展。
所需证据：使用代表性记录及员工实际权限进行演示；确认版本和许可限制；明确扩展、支持和更新测试的负责人。
继续用 CRM 管理客户和销售工作。如果独立审批工具更适合这项决定，且有明确的使用理由，就考虑使用它。
所需证据：哪个系统负责续约和决定、哪些信息通过连接传递、谁能查看，以及如何发现并纠正丢失或冲突的更新。
如果必要的记录或规则无法通过可接受的配置或受支持的扩展适配当前产品，就考虑更换。
所需证据：不匹配的实例、拟更换产品能处理这些实例的演示，以及保留有用历史、权限和现有有效流程的计划。
对于这个假设案例，暂定决定可以这样写：“先测试 CRM 现有的审批功能。我们尚未确认当前版本是否支持所需权限和续约历史。如果试验验证了这两点，就继续使用；如果缺少特定能力，再评估扩展或连接。若必要的合同和续约记录无法适配，就研究更换系统。”
如果每个系统都有明确职责，连接就值得考虑。以续约为例，也许一项独立服务已经保存了审批所需的合同条款。将相关信息带入审批过程，可能比在 CRM 中复制这项服务的全部工作更合理。
但要先约定信息的含义。“已批准”是指经理批准了建议折扣，还是客户接受了续约？谁能修改状态？批准后续约内容变了又该怎么办？
微软关于 系统间概念转换的指南 解释了不同系统可能对同一业务概念有不同理解，也指出了维护这种转换的额外工作。您无需采用其中的特定架构，也应问清：谁负责让这些含义保持一致？
在选择独立工具之前，先证明相关产品及版本支持所需连接，再确定谁处理更新失败的情况。第二项订阅和一个连接器也需要有人负责。
所谓核心不匹配，是指产品无法充分表示企业必须管理的事项，或这些事项需要遵循的规则。
例如，一位客户可能有多份合同，每份合同都有自己的续约、审批和历史。如果拟议方案只是在客户记录中反复覆盖一个“续约日期”，就要问其他续约如何保存。先查明产品是否支持所需的关联记录，再判断是否必须更换。
如果支持，采用受支持的扩展可能合理。如果不支持，接连使用变通办法可能仍无法解决根本问题。这比单纯觉得界面难用更能支持更换系统的决定。
更换系统也意味着工作：迁移记录和附件、保留有用的历史、设置权限、重建必要的连接，并帮助员工在新系统中完成工作。在把精美的销售演示当成适用性的证明之前，先请供应商在新系统中演示棘手的续约任务。
对每个选项都要问：谁控制记录，谁能导出记录，导出的内容实际包括什么？查看合同并检查一份导出样本。能打开某个界面，并不能说明离开系统时历史、附件或定制功能会怎样。
对三个选项都问同样的问题：谁能发起和批准续约？谁维护方案？供应商更新后会怎样？还有哪些持续费用？
按实际情况计入订阅及所需版本、配置或开发、员工培训、支持、连接维护，以及最终退出时的工作。使用针对这项任务的实际条款和估算。小型扩展也会带来持续责任；更换系统带来的工作可能远超最初引发问题的那个功能。
英国政府的 技术采购指南 将改造现有产品和开发软件，与需求、能力及持续的供应商管理一起考虑。它提供了有用的比较框架，并没有为商业 CRM 决策指定普遍适用的赢家。
选择可能真正解决已确认缺口的最小方案。在受支持的测试环境中使用虚构但有代表性的记录。让试验避开真实续约、客户消息和生产环境更新；在试验足以支持扩大使用之前，保留现有流程。
针对续约示例，测试正常批准、驳回、修改报价后重新审批，以及无审批权限的人尝试操作。如果涉及另一系统，还要测试更新丢失及其恢复。事先决定如何停止试验、删除测试记录和设置，并保留试验发现。不要让试验依赖撤销真实客户决定。
有用的结果应当具体：代表能看到待办事项，正确的经理能作出决定，续约记录保留决定及其背景。记录剩余的人工步骤，为每一步指定负责人，再用试验结果更新决策记录。
我们提供 定制软件 和 API 集成服务。如果您希望获得 CRM 缺口评估方面的帮助，请带上棘手的任务、一份示例记录，以及现有系统中希望保留的部分。范围、许可、交接及后续维护均按具体项目商定。
可以，前提是当前版本已经支持完整任务，而且相关人员凭实际权限能够使用。请供应商演示，并让员工亲自尝试。如果缺少某项能力，应将受支持的扩展与设置和培训分开评估。
当 CRM 仍能很好地完成主要工作，而且另一工具有明确职责时，可以考虑连接。确认产品支持该连接，约定每项记录和决定由哪个系统负责，并指定处理更新失败或冲突的负责人。
这取决于产品、版本和定制方式。批准工作之前，确认受支持的扩展接口、供应商支持条款、谁负责测试更新，以及谁负责修复不兼容问题。不要假定新增功能无需维护就能持续运行。
上一期通讯：如何从你已经拥有的订阅制网站或应用中赚到更多。
再上一期：如何从真实的成功案例中识别 AI 的胡扯。
感兴趣吗？
每周 或者告诉我们，我们就按你的意愿调整。这样可以吗？
