关于该项目
客户的产品是B2B领域的SaaS，采用订阅费用格式运营。用户注册，通过授权，补充其帐户并使用该服务。
我们的任务是帮助客户“收集”分析。为此，有必要构建呼叫中心流程，实施CRM，并通过关键指标“汇集”端到端分析。
工艺结构
在进行分析之前，您需要准备一个收集环境：构建销售流程并建立与服务的集成。我们在流程中发现了几个问题：
- 经理因销售漏斗的不必要阶段而分心，他们的工作没有得到任何监控。
- 每天都从管理面板手动下载销售报告；
- 很少有转化事件可以收集分析数据。
接下来，我们绘制了一个包含所有系统交互结构的地图。
它显示了事件应遵循的逻辑以及分析人员将在哪个阶段进行。我们从CRM中获取主要数据，并将其与广告和转化数据相关联。将其放到myBI中，然后在Power BI中渲染。
销售渠道
客户销售在Enybox CRM中进行，我们将其转移到amoCRM以简化集成。我们设法将销售逻辑分为三个渠道。
三个连续的程序
第一个程序是咨询。我需要带客户在平台上注册。第二个渠道确定了第一笔付款。然后，用户确认他的注册。反过来，我们庆祝付款的时刻和每次新的补充。
分析应该如何工作
| 最初的“事件” | 最后的“事件” |
|---|---|
| 反馈表 | 反馈表 |
| 服务注册 | 服务注册 |
| 首次存款 | |
| 测试（可选，少量补充） | |
| 重复充值 | |
| 拒绝使用（通过OP进行热身） |
为了使分析系统正常工作，您需要收集所有事件=标记转换操作。事件已经进入分析系统，但最初只有两种类型，不足以生成报告。
显示数据
仪表板示例
收集有关转化的数据后，有必要从中进行报告。主要的数据可视化工具是Microsoft Power BI。
转换时，网站上生成了一个单独的ID，以同步广告系统和CRM。通过该ID，我们将费用和收入数据链接在一起。因此，我们将数据关联起来，并可以基于它生成报告。
单位经济学。保留
服务从
保留1到12个月的滚动保留图显示了有多少用户参与了该应用程序，以及他们返回该应用程序的频率。但是由于该服务以补货的形式工作，因此我不得不将此指标更改为滚动保留。它表示与保留相同，但表示用户一直在不补充帐户的同时也使用了该服务。
转换为第一笔存款
转换高度取决于新客户的数量及其付款的开始。在最初的9个月中，我们每月收到大约430个新注册和90个来自新用户的付款。根据12个月的数据，在注册月份，购买转换为20％。
除了标准指标
在简单过渡到站点时以及注册和进一步付款时，都可以看到客户的分析。我们积累了数据，以找到最多的转化链：
用户看到了广告→去了站点→不久后进入上下文并在上下文中进行了搜索→已注册，但未付款→进行了预热→提供了试驾→已测试→首笔付款“放弃”了OP→3年稳定付款。
出问题了
从一开始，该项目的发起者就将启动推迟到秋天（它们在春季使用）。作品中的这种“空白”不止一次发生。但是我们没有考虑它，并且认为这是理所当然的。主要问题是客户流程中的沟通和官僚主义。这样可以描述项目的整个工作周期：
发展缓慢
发展方面的差距归因于客户工作的结构。我们与客户团队一起工作，由于流程的高度安全性，某些任务只能在他一方执行。
错过了两次冲刺-输了一个月
他们身边的所有经理和开发人员都进行了为期两周的迭代。但是他们一直把我们的项目放在最后的优先位置，而且我们的任务常常没有落入“冲刺”。
沟通不畅，缺乏专业知识
在项目期间，客户经理（利益相关者）已更改五次。大概每个人都知道，当您正在从事的项目突然对客户不感兴趣时，这种感觉就变得不那么有趣了。但是即使那样也可以解决。
处理利益相关者的无能是更加困难的。其中一位是一位非常了解自己产品的高管。但是他甚至不了解构建销售流程的基本原理。我们花了几次会议说服他从销售渠道中删除状态为“您好吗？”的舞台。
想象一个销售漏斗，如上图所示。在其中一个阶段，管理者需要找出“客户的表现”。您认为这种渠道的转化分析会如何？
经理们会从客户那里了解“你好吗”，而不是通过渠道来找他，这种情况并非无关紧要。何时放置它并不明显：第一次接触后或在鉴定之后。结果，沿着漏斗来回“跳”或只是站着，而不是顺序移动。
在销售过程中，不可能设置交易将累积的中间阶段。否则，所有分析都将变成一团糟，经理将失去很多联系。
我们这边的法卡帕斯
我们没有考虑系统带宽。对于高峰期的一个平台事件，我们最多向amoCRM发送了10个请求，以执行业务流程的逻辑。
每天100,000个事件*到amoCRM的10个请求=每天1,000,000个请求/每天
1,000,000个请求/每秒10个请求（AMO限制）= 100,000秒=±27小时
结果：同步将永远不会结束
最初选择的amoCRM，作为“传递”对系统的请求限制。但是在项目的开发过程中，要求和功能不断增加，我们“陷入”了极限。
我们选择了错误的工具。AmoCRM在物理上不适合处理大量请求。另外，错误是我们在GO上开发了所有内容，并且由一位专家负责。当他离开时，有大量的遗留代码，没人能做到。但是，不幸或幸运的是，这不是必需的。
一切再次崩溃
此案例是一个项目的另一个示例，该项目已陷入审批和大量不必要的管理之中。
我们缺乏技术专长。对客户-管理的稳定性和将项目结束的愿望。
但这是经验。多亏了他，现在这样的任务看起来才显得微不足道，而且我们已经在另一个项目中重现了类似的解决方案。
如何避免失败
为了将来不再重复此类情况，我们重点介绍了与企业客户合作时必须注意的方面。
- : ; . , .
- . — . — . . .
- . KPI — .
- 提前想好。即使在开发MVP时，您也需要查看将来可能出现的瓶颈。该项目一直在扩展，并且提供一个结构以免从头重写所有代码很重要。
本文的作者是LAND PRO市场商Fyodor Anisimov。