技术前沿

CRM+AI 的思考与实践

2024 年 5 月 9 日

本文3133字，预计7分钟读完。

23年初，AIGC概念开始席卷全球，同年Q2季度，我司启动【AI CRM】项目，旨在探索AI在CRM领域中的潜在应用场景。

笔者有幸能成为其中一员，经过了1年的探索与实践，落地了几款AI应用。

计划通过这个系列的文章，来梳理自己的些许思考，并跟大家分享一些有趣的落地案例。

前言

对于国内SaaS厂商而言，GPT-3.5的面世是AI技术的一个转折点，在此之前SaaS厂商围绕AI领域提供的解决方案，主要是通过传统的机器学习+规则引擎的方式组合成技术底座，期间也取得了一定的成果，但在处理复杂的自然语言（NLP）任务时仍存在一定的局限性。

随着GPT-3.5、BERT等基于Transformer架构预训练语言模型的出现，极大地提升了自然语言处理任务的性能，为软件厂商提供了更加强大的AI能力支持。

23年3月，GPT-4.0发布后，国内的头部科技企业陆续推出了自家的大语言模型（以下统称为LLM），如：百度的文心大模型、科大讯飞的星火大模型、阿里的通义大模型等。

▲陆续落地的大语言模型

作为通用型SaaS CRM厂商，从边际效益角度考虑，入局中游的算法模型产业并不现实，更多应该以国内通用的LLM为基础，聚焦在AI场景应用的探索工作中。

那么，在AIGC的时代，LLM之于ToB软件而言，带来了怎样的改变？

笔者的答案是：交互

交互的改变，背后源于LLM在自然语言处理能力上的显著提升，使得AI可以尝试理解用户的真实意图。

以往在CRM系统中，用户执行一个操作（如：搭建报表、写日报、跟进总结等），先要进入到对应的应用模块，并在模块里进行各种点击交互，直至最终进入到落地页（如：报表配置页、日报填写页），再执行一系列操作（如：填写、确认、提交）才可完成业务。

利用LLM的能力，可以尝试把多个页面以及繁琐操作进行简化，比方说：

把产品分为左右两个部分，左边是功能应用页面，右边是一个智能助手。用户可以通过Chat（对话命令）的方式，也就是打字/语音描述需求，完成一个完整的业务操作。

▲智能助手的框架

但如果把LLM之于CRM理解为一个“输入框”，让所有的业务起始于用户的描述，这并不是一个很好的方案。

原因引用白鸦老师有关「AI如何改变产品体验」分享中的一番话：

▲白鸦老师的分享

笔者理解：在ToB软件中，场景是复杂的，有时候用户也不知道该如何描述他们的需求。产品应该利用AI的能力在理解用户的真实意图后，给用户提供选择题（命令）而非填空题。

接下来，笔者以最近参与的一款AI应用「报表智能分析」为案例，分享我的浅薄理解，旨在抛砖引玉。

想法的诞生

这是报表产品一天的活跃轨迹图：

▲智能报表日活跃趋势

可以看出一天中，产品的使用高峰期在17-18点这个时间段，我们不妨问一下AI原因。

▲AI的回答

在这个场景下，用户的使用意图是明确的：在下班前，对当天工作进行数据分析与总结，从而调整次日的工作策略。

但目前从打开报表到经过一系列筛选和钻取操作获取初步分析结果，用户需频繁切换多个不同页面，操作过程略显繁琐。

针对这个场景，利用AI的能力，能否浓缩到一个页面中完成呢？比方说：

1、点击【总结】得出结果

2、基于结果，提供钻取分析提问

3、面向存在的问题，提供针对性的解决方案

▲侧边栏承接数据总结分析业务

这样，用户就可以在一个页面中通过几次简单的点击，来完成数据分析的完整链路闭环。

技术可以实现吗？

有了初步的想法后，接下来就要考虑如何把想法落地。然而，在落地过程中，历经了不少曲折与摸索。

比方说：数据总结区别于客户跟进总结：

「客户跟进总结」通常以纯文本形式存在，只要在Promot中定义好角色、背景、目标后，把总结内容套进去，AI即可按照Prompt中预设的要求生成总结。
「数据总结」通常以结构化的形式存在，如果转化为纯文本进行描述，会导致信息冗余，并且极大地消耗token。

因此一开始，团队便排除了“调用LLM文本生成接口”这个方案，另辟途径。

庆幸的是，当时合作的LLM刚好上架了ChatFile插件，支持基于doc、pdf的格式传参，这解决了我们的痛点。

方案大概是：把看板的数据以表格的形式生成一份doc，然后利用ChatFile的能力，让LLM解析doc后再进行总结分析。

▲LLM支持ChatFile插件

刚开始，流程顺利跑通了，但问题又接踵而来，由于插件服务还处于初期阶段，并不支持流式输出，导致每次从上传、解析到总结，平均耗时30秒以上。

▲漫长的30秒

“让一个用户在看板页面停留30秒等待结果的生成，是一个糟糕的体验”

我们只能重新寻找替代方案，比如：把看板数据转化为纯文字描述的报告，对报告进行分割后存储在向量数据库。基于用户的提问，从向量数据库中检索出最相关的片段，再组装Prompt，调用LLM文本生成接口（后面出于其他因素考虑，也没有采用此方案）。

通过不断地尝试与探索，兜兜转转还是回到起点。把看板的数据经过业务侧的算法模型清洗一遍后，转化为Markdown的格式组装Promot调用LLM。这个方案在确保token消耗可控的前提下，极大地缩短总结时长，平均耗时5秒以内。

意味着技术层面已具备实现的可能性，也算是成功迈出了至关重要的第一步。

选择题而非填空题

对数据看板进行AI总结后，仅仅完成了第一步，解决了用户what的需求。接下来，就要探索有关when、who、why层面的需求。

在报表分析这个场景，简单来说，就是「钻取分析」，比方说：

when：客户联系跟进趋势如何，哪个时间段是峰值？
who：哪些员工业绩数据下滑了？
why：业绩数据为什么下滑了？

尽管AIGC时代中，“输入框”的作用很大，能够替代许多传统的点击和页面切换操作，但仅仅依赖打字来描述所有问题并不智能。因为用户仍需投入成本来梳理需求并打字描述问题，这在一定程度上降低了效率与便捷性。

根据LLM返回的初步分析结果，我们基于用户角色、使用轨迹、数据偏好以及看板配置等多维数据进行大数据分析与建模，提炼出潜在的钻取分析提问。在可视化层面上，呈现给用户是一个又一个的选项（命令）。

▲通过潜在提问帮助用户进行钻取分析

后续的使用过程中，系统会基于用户选择提问类型的频率反馈给权重算法模型，再通过动态调参的方式，持续优化推荐效果。

但并不意味要抛弃输入框，在方案中仍然要保留“输入框”功能来解决用户的个性化问题。

应用连接，形成闭环

最后，就是解决how的问题，比方说：作为一名销售管理者，当发现员工数据发生下滑时，该怎么做呢？

基于规则引擎，根据钻取分析的结果，支持连接不同的业务应用来提供针对性的解决方案：

面向数据下滑的员工，创建一个会话讨论；
面向业绩压力大的员工，适当调整销售目标；
面向客户跟进不积极的员工，创建一个客户跟进任务；

▲连接业务应用，形成闭环

从而实现了在1个页面中完成以往需要在4~5个页面以及一系列繁琐操作才能完成的事情。

以下是笔者录制的一个演示视频：

看到这里，也许有伙伴会疑问，接入LLM，是否意味着“后续ToB 软件的产品交互都要由GUI（图形用户界面）统一替换为LUI（语言用户界面）？”

但笔者认为，两者之间并非为互相替代的关系，应该是相辅相成，互相融合。毕竟用户看重的是产品能否高效地解决他们的问题，并非产品具体引用怎样的交互。

结语

最后，跟大家分享笔者的两个观点：

近两年，AI的发展不断刷新我们的认知，但在ToB软件层面上，厂商仍需要保持克制，适当控制好LLM的含量。目前来看LLM对于业务的逻辑理解还是不够，并非所有的功能模块都要上AI。作为产品经理，要以“给用户交付的方案是有用、易用、好用”为前提，客观评估功能模块接入AI的实质性价值。
AI场景化应用，本质上是AI+场景化应用，大部分软件厂商在AI大模型的选择上，倾向于与LLM厂商合作。意味着，产品的核心竞争力在于「场景化应用」上，这要求产品经理对不同行业用户的业务场景，有足够深刻的理解，能从中挖掘对应的需求；其次，提高「数据思维」，尝试通过厂商沉淀的数据基础来弥补通用化AI模型无法覆盖的能力边界，“AI+大数据”也许是一条不错的路子。

最后的最后，跟各位分享一下笔者最近阅读的一本书，杜雨老师、张孜铭老师的《AIGC：智能创作时代》，适合刚开始接触AIGC的同学（这不是一条广告）。