一张订单排到月底,客户临时改期,计划表上“预计交货”那一栏被改成了下个月。
改的人知道,业务员不知道;业务员不问,客户也不会主动说,等到发货那天才发现货没好。
这类信息的难点不是算不出来,是没人会天天去翻那张表。这张表就跑在勤哲 Excel 服务器上,数据是准的,问题长在人的注意力上。
勤哲 Excel 服务器从 2016 版起提供与微信的接口,可以在手机上填报、查询、审批、收消息。这套能力落到这个场景,答案很朴素:让系统每天主动把“可能延期”的单,发到相关人的手机上。
一张订单排到月底,客户临时改期,计划表上“预计交货”那一栏被改成了下个月。
改的人知道,业务员不知道;业务员不问,客户也不会主动说,等到发货那天才发现货没好。
这类信息的难点不是算不出来,是没人会天天去翻那张表。这张表就跑在勤哲 Excel 服务器上,数据是准的,问题长在人的注意力上。
勤哲 Excel 服务器从 2016 版起提供与微信的接口,可以在手机上填报、查询、审批、收消息。这套能力落到这个场景,答案很朴素:让系统每天主动把“可能延期”的单,发到相关人的手机上。
消息发给谁,比消息写什么更需要先想清楚。想不清这一层,推送很快就会变成骚扰。
第一类是订单负责的业务员,属于动态接收人:张三不该收到李四负责的单,人被换掉,接收关系也要跟着换。
第二类是相关领导,属于相对固定但要能增减的接收人:今天加一位分管副总,不应该去改公式。
两类人的处理方式完全不同。后面所有的视图设计,其实都在解决这个差别。
数据源是系统里的《出货计划表》,由各地业务员维护更新。这张表有一百多列,客户、品名、数量、各段时效、责任人都在里面。
微信消息装不下一百列,也不需要。先按条件把预计延期的订单挑出来,只留单号、客户、原交期、新交期这几项。
这一步用 SQL 视图完成。视图不动原表,筛选逻辑单独存一份,条件要改只改视图,业务数据一行不碰。
筛选条件本身也要经得起推敲。是“新交期晚于原交期”就算延期,还是“晚于今天且未出货”才算,两种口径发出来的名单完全不同。
筛出来的结果还是多行。一个业务员手上有五张延期单,就是五行记录。
微信消息是文本格式,发不了一张表;同一个人连着收到五条,效果约等于没收到。
于是再建一层视图,以第一层视图为数据源,按业务员分组,把五张单拼成一段文字,存进消息内容字段。
拼接要讲顺序。单号、客户、原交期、新交期,按人阅读的习惯排;每单之间留一个空行,手机上才不会糊成一片。
领导层如果也按人名写进公式,每次分工调整都要改模板,改完还要重新测试,成本比想象中高。
做法是在系统管理里增加一个角色,名称就叫“过期订单预警消息接收”。需要收预警的领导,勾上这个角色即可。
再用视图把拥有该角色的用户全部取出来,作为第二类接收人。加人减人只动角色,公式一行不改。
这是权限体系的一个常见用法:把“谁”从公式里拿出来,交给角色去管。角色是业务语言,公式是技术语言,两者分开维护才长久。
在勤哲 Excel 服务器里,角色不只是登录时的一道门,也可以直接当数据源用。这一点让很多“名单类”的需求变得很轻。
到这一步,消息有了,人也有了,还差把两者拼在一起。
用一张视图关联业务员与对应的消息内容,再并上从角色取出的领导名单,得到一份“接收人加消息内容”的完整清单。
清单里一个业务员占一行,内容只有自己负责的单;每位领导也占一行,内容是全部延期单。同一份数据,两种视角。
拼的时候注意去重。同一个人既是业务员又在领导角色里,会收到两条几乎一样的消息,这类细节只有真跑一遍才会发现。
最后建一张最简单的模板,上面只放一个消息公式。公式被执行时,按清单逐行把消息发出去。
因为准备工作都在视图里做完了,模板里几乎看不到逻辑。前期越啰嗦,最后越干净。
再配一个定时任务,每天固定时间自动填报这张模板。填报动作触发公式,消息就出去了,不需要有人守着点按钮。
用户收到的是这样一条提醒:哪张单、哪个客户、原定几号、改到几号。看完就知道要不要马上处理。
任何“定时挑出一批异常记录、按负责人分发”的需求,结构都一样:筛选视图、格式化视图、接收人视图、消息模板。
库存低于安全线、合同到期前三十天、应收账款逾期、设备保养到期,换的只是筛选条件和文案,骨架不用重搭。
定时任务的频率要按业务节奏定。太密会打扰人,太疏就失去预警的意义,多数场景一天一次足够。
还有一点容易被忽略:消息只是提醒,处理仍然要回到系统里做。把“已读”当成“已办”,是这类推送最常见的误用。