- 通过案例演示飞书多维表格如何与AI能力结合构建轻量级企业AI应用
- 飞书多维表格产品分析，以及LLM在企业应用的切入点和能力边界
你是否能区分出智能体AI Agent和低代码产品PaaS在toB软件设计上的区别，以及什么情况下该用什么产品？本文就聊聊我对两类产品形态赋能数字化业务的实践思考，以及一个模拟的案例演示。开始之前先聊一个基础概念，在《决胜B端》一书中，我将toB软件分为两类。工具型软件：聚焦于企业孤立业务场景，解决员工局部痛点问题，不涉及复杂的多人协作与业务流运作。例如会议系统、企业网盘、知识库。业务型软件：支撑了业务管理运作的落地，涉及到复杂业务流程和多人协同。例如ERP、CRM。这两类产品形态在产品特点、设计模式上有本质区别，前者更像C端产品，后者才是一般意义上的企业应用软件。但是，如果你需要构建一套支持多人协作的业务流程系统，AI Agent就无能为力了。业务系统的核心底层是数据模型，依托于数据模型和业务规则要构建业务逻辑层，在这些基础之上是列表、详情、表单等可视化展现；而这些是低代码PaaS产品擅长解决的领域。有了这些基础概念，我们来看一个案例，并选择合适的产品方案来实现。（接下来的过程中，你可以边看边思考这个案例能不能用目前的AI Agent来实现，如果能，如何实现；如果不能，为什么。）假设你和三个小伙伴一起搞了一个抖音和小红书账号，拍一些段子，卖AI产品课程。你们希望能记录管理客户线索，并且当客户提交了客诉以后，能够分配给合适的小伙伴跟进，小伙伴可以看到AI总结的客户情况，从而准确掌握背景信息。另外，如果在小红书或抖音上有差评，也能自动生成客诉发给小伙伴。围绕这个需求，我们可以综合采用低代码平台 + 大语言模型 + AI Agent实现。我自己的直观感觉，通过LLM的加持，针对这个复杂度的案例，配置工作量可比之前纯低代码平台降低60%以上。系统将客诉分配给合适的客服，并提炼总结客户的历史跟进记录（重点关注客户有不满的跟进），以便客服了解情况想看本案例的上机演示？欢迎加我微信预约周二晚上九点的直播！我们将以上原始场景需求进一步拆解成产品需求，设计两个流程，第一个是用户留资跟进转化流程，如下图：1、小伙伴记录并管理来自小红书等平台的咨询客户（预留了电话）2、客户线索会在此手工分配给不同小伙伴跟进，跟进记录需要记录并管理3、有一个公开的表单，任何客户可以访问并填写投诉或建议5、系统可以自动将待跟进的投诉，根据不同人的擅长项目和排班表，分配给不同的小伙伴6、总结该客户之前的跟进记录，尤其是重点关注客户不满意的情况，将总结信息呈现给跟进客诉的小伙伴，以便其准确掌握客户情况。7、将客诉分配给小伙伴以后，发一条飞书消息通知他跟进。8、自动监控小红书和抖音的评论，如果发现有差评，生成投诉记录，按照步骤4的逻辑执行。 1、客户管理和客诉处理，很难通过AI Agent实现，而需要构建小型业务系统（或者说需要几张有逻辑关系的数据表）。2、自动分析抖音、小红书的逻辑，可以通过AI Agent的workflow模块实现（其实理论上PaaS的工作流模块也能实现，workflow并不是Agent发明的东西，早已存在多年）。对于第1点，我们决定采用飞书多维表格，这是一个非常轻量级的低代码产品（本质上就是PaaS），而第2点，通过Coze的工作流实现。我们对以上需求文字进行颜色标注，蓝色代表用多维表格的标准能力实现，绿色代表用到多维表格的AI能力实现，红色代表用Coze实现，对需求标色后如下：1、小伙伴记录并管理来自小红书等平台的咨询客户线索（预留了电话）2、客户线索会再次手工分配给不同小伙伴跟进，跟进记录需要记录并管理3、有一个公开的表单，任何客户可以访问并填写投诉或建议5、系统可以自动将待跟进的投诉，根据不同人的擅长项目和排班表，分配给不同的小伙伴6、总结该客户之前的跟进记录，尤其是重点关注客户不满意的情况，将总结信息呈现给跟进客诉的小伙伴，以便其准确掌握客户情况。7、将客诉分配给小伙伴以后，发一条飞书消息通知他跟进。8、自动监控小红书和抖音的评论，如果发现有差评，生成投诉记录，按照步骤4的逻辑执行。业务系统的核心本质是底层数据模型，对于案例中非常简单的客户管理、跟踪、客诉处理系统，普通业务人员可能也能轻松设计之间的表逻辑。但如果是复杂的专业系统，没有受过训练的人是很难自己实现的。本文重点并不是介绍数据建模的过程，我们直接给出结论，根据对业务流程的梳理，整个业务运作涉及到四张数据表，通过ER表达其逻辑关系如下：“客户跟进记录表”记录了不同小伙伴对客户跟进后登记的跟进总结。这三张表之间存在逻辑关系，客户信息表的客户ID字段，分别是另外两张表的外键。第四张表，“客户排班表”，是一张单纯的配置表。下图展示了四张表的表结构，这四张表实现了需求1、2、3，也是后续需求实现的基础。客户投诉表（注意，客户投诉提交以后，针对客户以及之前历史跟进记录的AI总结，我们都更新在这张表的“客户情况总结”字段中了）客户排班表（注意这里描述了客服的工作强项和排班计划，后边AI做自动分配时会用到这里的信息）第3点需求，要求客户投诉表是对外公开的，任何人都可以提交记录。所以，针对客户投诉表，创建一个只采集几个关键字段的表单，其他字段内容由后续工作流逻辑管理填充。客户投诉表的对外表单设计（注意这张表单只要求客户提供手机号，后台会根据手机号查询客户ID再去关联查询其他数据）第4点需求，要求能根据投诉建议表中的具体内容，填充优先级字段，这需要用到飞书的“字段捷径”能力，其实就是结合LLM预置了一些字段定义逻辑，如下图。这几点需求，都是在客户提交客诉以后，通过自动化工作流在后台实现的业务逻辑（其实第4点需求也可以在工作流实现，但是飞书的字段捷径提供了更方便的解决方案）。接下来，我们演示如何配置工作流（如下图），实现需求5、6、7。1、当“客户投诉表”创建一条“客户投诉ID”不为空的数据时，触发工作流。2、通过表单提交的电话号码，查询客户表，找到客户ID、姓名、年龄、性别。3、如果没找到客户信息，则在“客户投诉表”的“客户情况总结”字段，填写“没找到客户信息”。5、将客户ID字段，更新到新提交的“客户投诉表”相关字段，同时查询客户的跟进记录信息，以及排班表的数据。6、设置大模型节点，通过提示词描述逻辑，总结之前的跟进记录，如下图：# 角色
你是一名客服业务人员的助手，负责根据给定的客户历史跟进记录信息，提炼总结客户的整体跟进沟通情况。
## 技能
1. 仔细分析给定的客户历史跟进记录信息。
2. 提炼总结客户的整体跟进沟通情况。
3. 着重关注并说明跟进记录中客户不满意的情况。
4. 将生成的总结要点分为跟进记录总结和跟进记录明细两部分。
## 限制
- 必须包含两部分内容：跟进记录总结（着重关注客户不满意的内容）和跟进记录的明细（包括跟进人，跟进时间，跟进内容）。
- 总结要准确反映客户的整体跟进沟通情况。
- 需着重关注并说明跟进记录中客户不满意的情况。
## 用户要求
请根据以下跟进记录的具体信息，提炼总结客户的整体跟进沟通情况：
7、设置大模型节点，通过提示词描述业务逻辑，匹配客户投诉合适的跟进人，（因为我的飞书环境组织中只有我自己，所以没有实现更加真实的指派人员账号的逻辑，而是通过处理文本的方式进行了模拟分配的过程）。如下图：# 角色
你是一名专业的客服排班助手，负责根据客诉情况、客户情况、排班情况和客服技能情况，将客诉分配给合适的客服专员。
## 技能
1. 全面综合分析客诉信息、客户信息、客服排班信息以及客服技能信息。
2. 根据客诉信息中的投诉日期自动判断是否为工作日。
3. 精准判断客诉类型和需求。
4. 细致评估每位客服专员的技能和排班状况。
## 限制
- 严格依据客诉情况、客户情况、排班情况和客服技能情况进行分配。
- 若没有合适的客服专员，默认将客诉分配给老马。
- 仅返回找到的合适客服专员的名字。
## 用户要求
客诉信息如下：
客户信息如下：
客服专员的信息（包括名字、技能和排班）：
请返回合适的客服专员的名字。
8、将负责人的姓名，以及关于跟进记录的总结，填入客户投诉表相关字段飞书收到消息提醒（注意推送中有大模型生成的跟进记录总结）工作流日志展示了处理逻辑（注意流程log中描述了大模型如何思考分配合适的客服人员）我测试了好几个案例，有不同年龄的客户填写不同类型的客诉，总体来讲LLM可以准确根据我描述的业务逻辑，匹配合适的跟进人，例如会72岁的高龄客户，按规则会分配给杨堃，严重客诉会分配给果冻，年轻人客诉会分配给豌豆，默认客诉会分配给老马。以上就是案例展示，更详细的操作和Case，会在周二的直播中演示。第一种是类似于Mendix、Salesforce、纷享销客这样的专业级别低代码平台，用对象编辑器配置数据模型，流程画布编排流程。第二类是类似于Jira、Trello这样的中低级复杂度的低代码平台，通过表单编辑器配置对象，以及类似于飞书这样的流程编辑器。第三类是类似于多维表格这样的表格型低代码产品，最容易上手，但灵活性最差。通过Excel表格形态定义数据对象，通过最简单的流程编辑器编排流程。飞书多维表格属于第三种，其实这类产品的鼻祖是国外的Airtable，几年前我第一次用多维表格，感觉和国内其他类似产品差不多，都在模仿Airtable，但是到了今天，多维表格已经完全走出了自己的特色，我认为全面超越了Airtable。用起来非常舒服，非常容易上手，很适合小团队做小型业务应用，确实可以称为神器。另外这次我也无意中发现飞书开启了独立的低代码产品，其实之前飞书一直把多维表格当成自己的低代码产品，而钉钉采用了类似于上述方案2的技术路径。但显然飞书在这方面做了一个不错的差异化竞争，表格型低代码确实很好用，而飞书又进一步补齐了方案2形态的低代码产品。1、首先是个不确定的小bug：用AI来生成多张表格，并没有自动完成主外键的构建，需要手工区配置双向关联表和单向关联表。而且用AI默认生成的表，没有自增长的业务主键，我不知道是不是因为这个原因，在最早版本的工作流中，做多表主外键关联查询总是失败，后来重新手工创建表，每个表严格定义主外键，工作流才能正确查询到数据。2、多维表格的“自动化”模块和“工作流”有冲突，感觉像是当年没有规划好，设计了两套workflow，结果最后尴尬了。这有点像早期的Salesforce，最早也有两个workflow产品，分别是Workflow Rules和Process Builder，后来强制要求用户全部切换到最新的工作流产品flow。不过以飞书的资金和实力，重复的两个组件，不论合不合并，都不是问题。3、表格形态的低代码产品虽然好用，但是在稍微复杂一些的场景上就歇菜了，比如说想做一个数据对象的详情页，里边可以展现更多外部表的关联数据，这在多维表格中是很难完成的。虽然表格模式的低代码产品有众多局限性，但他确实容易上手，非常好用。另外通过以上案例，我们也能感受低代码、大模型、AI Agent的区别。基于数据模型构建的业务性系统，依然需要PaaS类产品定义（或者纯硬编码自研）。AI Agent根本无法实现这类业务系统（当然理论上配合数据底层定义能力的Agent产品也能支持，但会非常非常别扭诡异）。LLM在文本处理、信息提炼等内容场景上很强，但是在对精确度要求很高的业务逻辑场景上需要非常慎重的使用，虽然上边的例子看起来很方便的实现了客诉智能分配逻辑，但要知道，真正的业务系统重，关于客服的排班和任务分配管理是非常复杂的模块，不是因为技术栈太弱，而是因为toB场景要求非常严谨的逻辑定义和规则配置。语言模型可以描述，但很难做到配置严谨的业务规则描述。
