勤策7.3.15产品更新

面向CPG行业的产品更新

CPG(Consumer Packaged Goods)行业产品适用于快消、耐消、医药、建材、农牧等泛消费品行业,帮助品牌商精细化管理经销商、终端执行、渠道费用等渠道分销全过程。

1. 渠道销售管理(SFA)产品更新

1.1 拜访客户自动校准门店地图点位

【需求场景】
在传统线下业务中,客户信息虚假、门店“有名无实”是风控与管理的核心痛点。
在业务员现场拜访门店抵达时,可完成系统内门店与地图点位的校准,帮助管理层基于真实、可信的门店数据做出精准决策。
【功能介绍】
  1. 智能绑定地图点位:开启企业参数后,业务员拜访抵达即自动触发地图点位绑定流程,校准门店信息。
  2. 店招识别与精准匹配:通过门头照智能识别店招文本,并基于当前位置半径范围,自动关联对应地图点位,确保数据准确性

1.2 门店验真报备审批通过后自动绑定地图点位

【需求场景】
门店验真中,业务员频繁反馈目标地图点位已被其他同事绑定,导致无法完成核验,严重影响工作效率。此情况下的归属权争议,往往需要层层上报至管理层进行人工判断与协调,引入了标准化的审批与自动处理机制,管理层通过报备审批后即可自动解绑原门店与地图点位的绑定关系,自动建立报备门店与该地图点位的绑定关系。
【功能介绍】
  1. 触发审批流程:企业配置报备审批流后,当业务员在门店验真中报备“点位被他人绑定”时,将推送一条审批任务至指定管理层。
  2. 智能解绑与再绑定:报备审批通过后,系统将自动执行后续操作:解绑原门店与该地图点位的关系,并将当前报备的门店与地图点位进行绑定,全程无需人工干预,确保数据及时更新。

1.3 陈列评估Agent

【需求场景】
陈列标准设置功能中,规则设置(IF/THEN模式)已经无法满足企业复杂多样的陈列标准要求,需要更灵活的陈列规则设置引擎,所以我们将引入AI大模型来解决这个问题。
【功能介绍】
在勤策AI Agent平台配置陈列要求,将门店陈列规则转化为提示词(不会写提示词可以用AI写),当陈列数据采集后即可调用这个“陈列评估Agent”进行判断陈列是否合格或给出评估分数。
AI Agent陈列规则配置、陈列得分详情

2. 营销活动管理(TPM)产品更新

2.1 直接创建核销支持费用未税模式

【需求场景】
1、企业价税分离原则:成本费用按不含税价入账,进项税单独计入应交税费
2、直接创建核销场景承载坏货处理等临时性的费用报销,实际业务中也会纳入到营销费用体系,须提供费用发票,费用管理须具备未税模式
【功能介绍】
1、根据不同客户的费用管理要求,直接创建核销场景提供未税和含税两种费用管理模式,客户可根据实际业务场景调整
2、直接创建核销新增预设字段“发票金额、关联专票税额、关联含税金额” 。当企业采用未税费用管理模式,核销关联的发票为专票时,“关联专票税额”系统默认取所有关联专票的税额,该税额不计入费用,单独计入企业进项税作为后续的增值税抵扣
3、直接创建核销发起时,通过支付方式配置,控制对应支付方式允许关联发票
4、直接创建核销支持核销发起时关联发票,同时也支持后补发票(满足实际业务中发票先到和发票后到的业务场景)

2.2 根据AI窜拍结果更新执行评价结果

【需求场景】 
目前系统支持通过AI照片智能识别结果,通过匹配活动政策,自动判断是否合格,自动给出评价结果。但由于部分照片存在后续被识别为窜拍的情况,部分启用AI评价的客户希望系统可根据窜拍识别结果实时更新评价结果
【功能介绍】
1、增加企业参数“活动上报照片识别窜拍后是否更新评价结果”
2、当上报记录中的照片被是识别为窜拍后(通常为第二天识别完成),系统自动更新对应上报记录评价结果:
     如果初评、复评均未评价,则初评结果评价为不合格;
     如果做了初评,复评未做,则初评结果合格的更新为不合格;
     如果初评、复评均已完成,则复评结果合格的更新为不合格;
3、自动更新评价结果,评价人更新为系统,评价意见固定“对应上报照片存在窜拍”

3. 经销商管理(DMS)产品更新

3.1 分销订单新增【抄单助手】功能

【需求场景】
1、门店老板微信发来一长串订货需求的语音或文字,业务员要在勤策APP和微信间来回切换手动录入,耗时费力,还容易看错、抄漏。
2、业务员现场语音下单要求普通话标准才能准确识别,方言转文字的识别率较低,又不会说普通话,导致业务员不会使用语音抄单功能。
【功能特色】
1、多种方式,轻松抄单: 支持直接粘贴微信文字或现场语音输入,后续还将支持图片识别订单,满足企业多样的业务场景需求。
2、AI理解自然语言,自动过滤无效信息: 借助AI大模型能力,像“人”一样理解客户“说大白话”的下单需求(如“来10箱那个常卖的快乐水”),自动屏蔽无关内容,精准抓取有效商品和数量信息
3逻辑灵活定制,符合企业习惯: 企业可自定义识别规则(提示词/规则引擎),融入自家常用话术、商品昵称映射等,让识别更贴合企业的实际业务
【功能介绍】
1、企业根据自己需要,修改提示词,包括: 大模型的识别逻辑、匹配中的注意事项、企业自身的常用关键词、特殊情况下的兜底机制等等。
2、业务员在分销订单下单页面中唤起AI抄单助手,通过语音、粘贴方式输入下单需求;AI大模型识别后展示商品列表,业务员进行调整;调整完成后带回下单页面中。

3.2 分销订单支持【供货商确认】环节

【需求场景】
分销订单最终会由【供货商】进行订单履约,部分企业下单是由客户自主下单或品牌商业务员进行代下单,供货商在这个过程中对订单信息没有进行判断和过滤,可能导致后期订单无法正常交付。
因此本次更新后,在分销订单提交完、客户确认后,进入企业内部流程审批前,需要单据上的【供货商】角色对单据进行确认
【功能介绍】
供货商确认环节需要企业自行开启;支持设置需要进行供货商确认的单据范围;符合条件的分销订单在进行勤策端流程审批前,会先流转到经销商门户中,由供货商确认完成。

面向IG行业的产品更新

IG(​Industrial Goods)行业CRM产品适用于装备制造、化工化纤、服务业等B2B销售模式,帮助中大型企业精细化管理大客户销售过程和交付过程。

1. 线索到商机管理(LTO)功能更新

1.1 拜访内置子任务-新增线索、线索跟进

【需求场景】
为支持IG行业客户实现真正的“业务All-in拜访”管理,业务员在一次拜访中,即可无缝衔接完成从客户洞察、线索开拓到商机跟进的全流程,无需在多个功能模块间切换,有效解决了以往销售动作碎片化、数据记录分散的痛点。
【功能介绍】
  1. 拜访内置线索任务:支持在拜访模板中配置“新增线索”与“线索跟进”两类子任务,将线索管理深度融入标准拜访流程。
  2. 强制的闭环跟进机制:执行“线索跟进”任务时,业务员必须从该客户名下所有线索中选择并填写跟进内容,确保每次互动均有记录。

2. 订单到回款管理(OTC)产品更新

2.1 信用额度管理

【需求场景】
在B2B销售中,信用额度是企业对客户进行授信管理的核心机制。它基于对客户信用资质的综合评估,授予其一个在特定账期内可循环使用的交易限额。这不仅赋能销售团队在额度内高效地执行“先货后款”,提升客户体验与粘性,也为公司锁定了最高风险敞口,实现了增长与风险的精妙平衡。
【功能介绍】
  1. 支持正式、临时信用额度。正式信用额度无有效期,一个客户+币种仅支持一条正式信用额度。临时信用额度有有效期,一个客户+币种可以有多条临时信用额度。 
  2. 客户信用额度,按【客户+币种】取【正式信用额度+当前在有效期内的临时信用额度】,同一客户不同币种之间的信用额度独立使用。

2.2 客户余额管理

2.2.1 客户余额

【需求场景】
在企业的信用与资金管理中,“客户余额”是衡量客户实时财务能力的核心指标。它代表客户在当前时点,其“预存款”与“信用额度”之和,扣除所有“已占用资金”(如未结算订单)后,所剩余的、可用于新交易的有效额度,直接反映了可用于继续交易的资金与信用空间。
【功能介绍】
  1. 当未开启多币种时,一个客户存在一条唯一的客户余额记录。当启用多币种时,一个客户+币种存在一条唯一的客户余额记录。
  2. 预存款余额:按【客户+币种】取【资金池类型=预存款的资金池余额】,如果有多个池子,进行汇总相加。
  3. 信用额度:按【客户+币种】取【正式信用额度+当前在有效期的临时信用额度】。
  4. 订单占用金额:仅当企业参数自动生产应收=发货自动生成应收时,才做订单的占用。订单占用为“订单新增审批状态=审批中+已通过,且未删除的订单”待发货金额的累加。
  5. 待结算金额:按【客户+币种】汇总【应收单的未核销金额】,即已经生成应收但未结算、未核销的金额。
  6. 客户余额:预存款余额-待结算金额。
  7. 可用额度:预存款余额+信用额度-订单占用金额-待结算金额。

2.2.2 客户余额校验规则设置

【需求场景】
客户余额校验机制,是将风险控制前置化的关键手段。它通过在下单、发货环节设置系统自动化校验规则,确保每笔新增交易都不会突破客户的实际支付能力。这实现了从“事后催收”到“事中阻断”的风控模式转变,从根本上约束了过度赊购行为,是保障企业销售质量与现金流安全的核心防线。
【功能介绍】
  1. 增加客户余额校验规则,在单据提交/审批时按照设置的规则进行校验,并进行“预警提示”或“取消交易”。(若未配置客户余额校验规则,则认为是不校验)。
  2. 业务单据:支持配置销售合同、订单、发货申请单、发货单这4个单据进行客户余额校验。
  3. 业务单据范围:支持配置对应单据的单据范围,比如针对外贸类型订单进行校验。
  4. 信用校验时机:支持配置在提交还是审批的时候校验。如果提交、审批均需要校验,那需要配置2条规则明细。
  5. 信用校验强度:预警提示即弱控制,提示可用额度不够,但仍然可以继续提交/审批通过。取消交易即强控制,提示可用额度不够,不可以继续提交/审批通过。
  6. 使用人员范围:配置该条规则适用于哪些操作人,比如审批的时候只有财务审批环节才做客户余额的校验。
  7. 一个客户如果匹配到多个规则,那按照优先级+创建时间取一条。

2.2.3 订单校验客户余额

【需求场景】
企业的销售人员和大客户合作时,如果缺乏客户信用额度的系统化管理,会面临以下风险:
  • 回款逾期与坏账风险
          部分客户在累积多个订单后,实际应付款额已远超其偿付能力,导致回款困难,甚至形成坏账,直接影响公司现金流和利润。
  • 依赖人工判断,效率低下
          销售人员在接单时,无法快速、准确地判断该客户当前的总欠款是否在安全范围内。审批流程依赖财务人员手动核查历史账款,响应慢,影响订单处理效率。
  • 风险控制滞后
          风险往往在客户已经逾期后才被发现,缺乏事前预警和事中控制机制,处于被动应对状态。 因此,企业希望系统能够实现对客户风险的前置管控,确保订单在安全信用范围内执行。
因此,企业希望系统能够实现对客户风险的前置管控,确保订单在安全信用范围内执行。
【流程介绍】
订单校验客户余额流程主要是:客户授信 → 订单校验 → 自动审批/人工干预 → 安全发货/风险规避
【功能介绍】
1、在客户余额中设置校验规则,单据类型选择订单;
2、在对象布局中将客户余额、可用额度字段拖到界面上;
3、创建订单时即可查看客户可用额度,如下图:
4、提交订单时,进行客户可用额度校验
弱校验:当订单金额>客户可用额度时,仅弹框提示,确认后可继续提交订单;强校验:当订单金额>客户可用额度时,不能提交订单。 
5、客户余额更新逻辑说明
客户余额更新逻辑:
客户可用额度 = 预存款余额 - 待结算金额 + 信用额度 - 订单占用;
订单占用金额=订单未发货金额=∑(订单明细行优惠后金额-已发货金额 (不包含超发货订单));
注意:仅当企业参数设置为发货生成应收时,会更新订单占用额度;设置为其他参数时,仅使用应收单更新客户待结算金额。

2.3 新增发货申请单

【需求场景】
在IG行业中,销售人员下单后,还需要跟进订单中产品生产进度,确保产品可以在交付日期准时交付。当销售人员确认产品已完成生产入库,就可以在CRM中操作发货申请,通知到仓管人员进行发货。 仓库管理员依据发货申请单在ERP中进行发货,系统将发货单同步至勤策CRM。
【功能介绍】
新增/编辑发货申请单时,选择客户后支持快速选择订单。
客户余额设置了发货申请单校验余额规则时,支持发货申请单创建时校验客户余额。
发货申请单同发货单,支持商品组合ATO和PTO的交付模式(即:仅可单独发货的商品行支持填写申请发货数量);
发货申请单审批完成,通过接口同步至ERP系统中。仓管员根据发货申请单进行发货,在ERP中生成发货单,发货单会通过接口同步至勤策CRM中,支持发货单同步时关联发货申请单(本期仅做关联,不进行发货数量、发货金额校验)。

基座平台(PaaS)产品更新

基座平台是SaaS系统的底座PaaS平台,让SaaS系统更加灵活、强大,以便满足中大型企业的个性化需求。

1. aPaaS产品更新

1.1 支持前端自定义组件

【需求场景】
当标准字段组件或平台内置业务组件无法满足企业个性化或复杂业务场景时,可通过自定义组件功能,自主开发符合业务需求的字段组件或独立业务模块,实现前端界面的灵活定制与功能扩展。
【功能介绍】
 自定义组件是个性化模块,可用于构建特定功能的UI元素。
1、多端适配:组件支持网页端与移动端,可自动适配不同终端设备。
2、技术栈:基于 React 框架进行开发,遵循统一的组件规范。
3、组件类型
  • 字段组件:需绑定到数据对象中的具体字段,用于该字段的输入、展示或交互。
  • 业务组件:可设计为通用组件,也可限定在特定对象中使用,通常作为独立模块嵌入详情页页面。
2025-10-17
68