低代码开发已经在全球范围内的不同行业、不同企业中得到应用，并且使用的场景、角色等也在不断拓展。本文介绍低代码在零售领域的应用：构建敏捷的客户服务管理案例。此案例中不仅介绍了明确的人物角色和场景背景，还阐述了如何使用低代码开发赋能企业和角色，帮助您解决实际问题，实现业务需求，从低代码开发中受益。

随着技术的发展变化加快，技术驱动业务、数据驱动业务变得越来越重要。过去 10 年、20 年持续稳定增长的生意模式，如今可能几个月就会变得完全不同。很多零售企业的业务方向会有不同，有些是 2B，有些是 2C，但无论哪种形态，这些企业会发现，顾客的购买行为已经从单纯的购买这个动作扩展为一个持续不断的端到端模式。产品质量、品牌影响力并不能完全决定顾客的购买意愿，售前、售中、售后的购买体验，客服人员的专业程度，都会影响潜在顾客的购买。因此从数据中获取价值，及时了解销售环节中顾客端的反馈和市场趋势，及时发现问题并不断调整，才不会在当今数字化转型的大潮中掉队。

下面以宜家瑞典销售团队联合合作伙伴凯捷基于 Power Platform 和 Dynamics 365 开发的 2B 销售端管理应用为例，带大家了解如何利用模型驱动应用快速实现应用开发，改变原有销售中用到的工具，提升员工效率，提高数据价值。

痛点和挑战

本需求来源于对数据的迫切需要。过去一个月，在门店销售过程中，为什么顾客没有买宜家的厨房家具？过去一个季度，有哪些增长的潜在 2B 客户？2B 客户的市场规模和增长情况如何？诸如此类的问题，在原有的运作模式及工具体系下，并没有一个很好的答案。因此，区域销售经理才迫切希望引入技术力量来解决问题，从数据中找答案。

整个 2B 的销售过程涉及几个团队的协作，销售部门利用定制的电子表格来追踪相关的预约、潜在客户、正在进行的项目以及项目中涉及的厨房用品的采购流程等。同时，销售团队还会利用电子表格来追踪相关订单，并统计厨房相关产品的销售情况。原有方式的一个主要问题在于数据并没有被很好地利用，缺乏统一的格式以及结构化的组织，无法实时看到整体的销售情况及客户情况。表格内容的示例见图 11-1。

图 11-1　原有业务逻辑下统计 Excel 表格的示例

此外，销售团队还要与后端客户支持中心合作。客户支持中心主要处理用户的相关预约、相关问题的报备。针对预约的流程，原本也是利用电子表格进行手动记录，客户支持中心会接到客户预定需求，并在线咨询当地商店，协调时间，再返回给电话端的客户。因此，减少销售团队及技术支持团队在销售流程中的手动操作，将销售过程中涉及的全部数据记录下来，是销售区域经理迫切的需求，也是当前的痛点。客户当前的痛点有如下几条：

• 复杂的购买流程涉及大量的手动操作，历时可能长达 4 个月之久；

• 每天需要花费 3 小时进行预约安排和管理；

• 与客户之间缺乏协调一致的沟通过程，导致销售损失；

• 缺乏移动性，B2B 销售团队在外地时无法访问系统；

• 缺乏用于计算和预测收入的汇总数据；

• 报告能力欠缺，无法全面了解销售情况；

• 缺乏基于职能的数据安全性，因为所有信息都保存在 Excel 表格中。

其实，以上都是特别常见的问题，利用 CRM 软件或通过编写代码都是可以解决的。但宜家瑞典销售团队还遇到了两个问题：IT 团队并没有足够多的资源和时间来处理以上问题，利用代码解决上述问题花费巨大，且耗时久；在考虑 SaaS 化软件的过程中，客户也需要一定程度的定制及后期基于业务的扩展，因为自定义的难易程度也是比较重要的。

解决的实际问题

整个解决方案是由宜家瑞典销售团队、合作伙伴凯捷以及微软架构团队共同完成的。这是低代码开发过程中典型的团队模式：业务人员直接参与，能力合格的 Power Platform 实施伙伴及微软架构团队在平台化治理、安全、性能上不断给出建议并协助优化。经过问题梳理，该团队最终开发了几款应用（统称为“宜家销售工具”）来解决痛点问题。宜家销售工具先期在瑞典销售团队中进行了试点，后续推广到宜家在瑞典的所有门店，多达 90% 的目标员工在积极使用该解决方案。宜家销售工具包含 4 个应用。

Kitchen App

这是 Power Apps 模型驱动的应用，利用了 Dynamics 365 现场服务功能。这款应用主要在门店内使用，用来浏览客户的预订信息，协调店内人员分工，并安排临时客户与销售专家会面等门店日常活动。商店经理和团队经理使用该应用报告统计关键数据。该应用提供了适用于宜家特定要求的 Dynamics 365 现场服务功能的子集。它使用资源调度模块来管理调度板、可预订资源等。Power Automate 用于简化用户体验：每次同事在会议中点击开始或结束时，都会触发一个流程，以自动计算和记录会议的持续时间并更新状态。Azure Functions 和 Logic Apps 用于连接到宜家的 SMS 传递系统，并将短信通知发送给客户。Dynamics 365 工作流用于发送电子邮件。该团队计划最终迁移所有工作流程以使用 Power Automate。应用示例页面如图 11-2 及图 11-3 所示。

图 11-2　同事分配的任务在应用中的展示页面

图 11-3　业务数据的统计视图

Co-Worker App

宜家员工在内部都被称为 Co-Worker（同事）。店内销售专家使用此 Power Apps 模型驱动的应用来启动和结束店内客户会议，添加会议记录，更新收入详细信息以及进行重访。利用 Power Apps 开发的模型驱动应用，同事首次能够使用单个工具在一个地方查找客户信息和状态。他们还可以查看每个同事的销售进度。他们计划通过为同事添加目标管理功能来继续扩展这一目标。除了使用 Power Apps 外，同事在日常工作中还使用了其他两款工具来设计厨房和下订单。这两款工具都是第三方工具，一款工具是用来设计客户的厨房方案的，另一款工具是用来进行订单管理的，叫 ISell。通过结合 Azure 中的服务使用，业务人员能够将这两个第三方系统中的数据进行汇总，供 Power Apps 使用，店内的同事可以通过一个应用来查看并完成绝大部分工作。Azure Functions 用于从 ISell 系统中提取重复的数据并发布到 Microsoft Dataverse 中，从而使所有厨房订单信息可以直接在 Power Apps 应用中使用。应用示例如图 11-4 及图 11-5 所示。

图 11-4　用于管理客户会议的 Co-Worker App

B2B App

这是一个由 Power Apps 模型驱动的应用，它利用了 Dynamics 365 销售功能，管理 B2B 销售渠道，可以为宜家的 B2B 客户创建单一客户视图，并从多个来源合并数据。B2B 销售人员负责将宜家产品销售给大小企业，供它们在办公大楼中使用。他们使用 Power Apps 模型驱动的应用，该应用利用 Dynamics 365 销售功能来跟踪销售渠道并提供有关其 B2B 客户的见解。该应用还使销售团队能够保持持续的沟通并与客户建立良好的关系。现在，所有 B2B 销售代表都使用新应用来输入新客户和现有客户的信息，这使团队和宜家管理层可以了解谁在照顾客户、活跃的商机和一般的客户渠道，还可以跟踪销售活动，例如收入、预计完成日期等。应用示例如图 11-6 所示。

图 11-5　同事可以使用日历视图来预订重新访问

图 11-6　B2B App 使用页面展示

客户支持中心 App

客服人员利用 Power Apps 模型驱动应用开发了客户支持中心 App，帮助用户管理预约信息。后台数据显示，在过去一段时间，这个 App 的活跃用户从 6 个增加到了 20 个，并且还在不断增加。虽然这只是很小的一部分用户，但这个应用的推出使宜家的客户服务中心在客户预约方式和流程上进入了更加数字化的阶段。如今，客服人员不再需要通过电话的方式帮助客户沟通门店预约，直接利用开发好的 App 就可以完成所有操作，大大提高了效率。在接听客户电话、帮助客户预约的同时，客服人员还能够查看客户过往的沟通信息，并利用这些信息主动与客户沟通，挖掘更多商机。同时，公司也可以通过集中管理的客户信息与客户建立起长久的服务关系（不再是原来单纯的买卖关系），为客户持续不断地提供优质服务。应用示例如图 11-7 所示。

图 11-7　客户支持中心 App 页面

带来的收益

宜家的家居销售工具投入生产还不到 6 个月。尽管至少需要一个 6 个月以上的销售周期才能收集到更详细的影响指标，但以下早期指标已经反映出该解决方案的优势和影响。

• 为销售团队提供了一个自动化系统，可以查看预约、重新预约和管理从初始到厨房安装的销售流程。

• 减少了资源规划、收集说明和整理数据的时间。

• 客户资料得到了集中整合，能够更好地长期管理客户。

• 由于获取和跟踪 B2B 客户的销售管道，销售额增加。

• 随着 B2B 部门的拓展，新销售代表的培训时间缩短。在某些领域，培训时间可缩短至原来的 1/3。

• 利用集中的数据来计算和预测收入，能够全面了解销售情况。

• 对销售、预测、员工绩效、客户留存等进行更高级、更精细的统计。

• 预期该解决方案的实施投入将在一年内获得正回报。

• 能够优先关注精准的客户，从而提高转化率。例如，在繁忙的 12 月，可以关注那些处于购买旅程末端的客户，在淡季则跟进新客户。这是宜家此前一直无法做到的。

解决方案小结

如上所述，整个解决方案实现了用 4 个 App 来优化当前销售过程。整个解决方案的系统架构如图 11-8 所示。

图 11-8　基于 Power Apps 所开发的应用的系统架构

任何一个解决方案的实施都需要考虑如下问题，此解决方案也不例外。

（1）团队的构成

整个解决方案的开发及部署都是由合作伙伴凯捷来完成的；前期业务流程的规划设计是由宜家瑞典销售团队与合作伙伴一起梳理和规划的；在应用的技术实现、性能方面，微软架构团队提供了很多基于最佳实践的分享。

（2）工具的采用

针对原有基于电子表格的方案缺乏一个客户管理系统的问题，这里采用了 Dynamics 365 Customer Engagement；考虑到不同团队的需求以及定制的复杂度，采用了 Power Apps 模型驱动应用。由于有些业务（尤其是协作办公及客户支持中心）的业务逻辑处理是 Dynamics 365 Customer Engagement 无法简单完成的，再考虑到用户体验的一致性，Power Apps 模型驱动应用就是一个好的选择。模型驱动应用孵化于 Dynamics 365，具有高度组件化、定制化的特点，可以根据用户业务需要定义每个模块的功能。当然，在每个 Power Apps 项目中，Power Automate 都会配套出现，因为现今的业务需求往往都是需要自动化实现的部分，而 Power Automate 是低代码开发中自动化流程的第一选择。

（3）数据源的梳理

选择 Microsoft Dataverse 是为了更好地发挥其业务数据库的价值。很多业务逻辑的处理、（销售团队尤其看重的）数据安全以及跨团队间数据可见性等问题，在 Microsoft Dataverse 中都可以通过配置快速解决。在应用开发初期，梳理数据源是一项必不可少的工作，了解项目中需要引用的数据后，业务人员能够更好地计划以何种方式导入数据，如何构建数据模型，采用哪种应用类型进行开发。如图 11-8 中所描述的，在本案例中，初期我们看到，整个应用需求的实现需要从官网、第三方系统、Dynamics 365 中获取数据，并汇总到 Microsoft Dataverse 中进行数据建模。了解项目事项中所用到的数据源，业务人员就可以从容地选择对应的技术来获取数据，并在 Power Apps 中实现业务逻辑。当用户看到数据从宜家官网及第三方系统中获取，自然会选择自定义连接器的方式，结合 Azure 获取数据，同时针对 Dynamics 365 中的数据，利用官方提供的 Dynamics 365 数据连接器进行连接。整个数据获取所涉及的问题就都找到了实现的方向，业务人员就可以将精力放在如何合理地构建数据模型并实现相应的业务逻辑上。

（4）与 Azure 的结合

在此案例中我们看到，除了使用 Power Apps 服务外，业务人员在开发过程中也使用了一些 Azure 服务。这其实是低代码项目在实施过程中的一个特点。我们要尽量避免进入这样一个误区，即认为低代码开发过程中利用 Power Apps 或者 Power Platform 能够解决所有问题。但当我们逐步开始一些复杂项目时，我们会发现，低代码平台往往只能够实现 20% 的功能，更多的功能及复杂的业务逻辑需要配合云平台中的技术来实现。正如此案例中描述的，在数据接入方面，我们看到需要从官网及第三方系统导入数据，这部分工作并没有写好的数据连接器来帮我们实现。调用 Azure Functions，利用 API 的方式结合自己编写的代码就能轻松实现，这在涉及实现很多复杂业务功能时特别有用。

来源 | 华章计算机公众号