I功能升级
公告与消息通知入口在哪，谁有权限发
入口在订货宝管理后台的「营销中心」或「消息中心」菜单下，具体位置随版本略有差异，但逻辑一致：先建内容，再选范围，最后确认发送。对接人第一次配置时，建议先用测试账号走一遍全流程，确认下游四端展示效果再正式推。
权限上，通常由运营负责人或商务主管来发，不建议开放给所有业务员。原因很直接：调价、放假这类信息一旦口径不一致，下游会拿着两个版本找你确认，反而增加沟通成本。如果公司有多个业务线共用一个订货宝账号，更要提前约定谁有权发全量公告。
发布前需要准备三样东西：通知正文、生效时间、适用范围。正文要写清楚「什么变了、从哪天开始、对下游有什么影响」，不要只写「价格调整通知」五个字。适用范围可以按客户分组、区域或等级来选，选错范围是后面最常见的返工点。
II功能升级
它解决的是哪一段业务：从「人找信息」到「信息找人」
调价、放假、上新这三类信息，在传统做法里依赖业务员逐个通知下游。业务员在忙、在休假、在跟单，信息就卡住了。下游没收到，下单时按旧价走，财务对账时才发现差异，回头再补沟通，一来一回消耗的是内勤和财务的时间。
订货宝的消息通知把这段业务从「人找信息」变成「信息找人」。下游打开订货小程序或商城时，公告在首页可见；重要调价可以配合弹窗或消息提醒，让下游在订货动作发生前就看到变化。这样做的价值不在「发得快」，而在「下单前触达」，减少事后扯皮。
需要注意的是，它替代不了业务员的客情沟通。大客户调价，系统公告是留痕和兜底，电话或当面沟通仍然要做。把系统通知当成唯一手段，遇到情绪敏感的下游，反而容易激化。
III功能升级
配之前要准备什么：先把规则定清楚，再动系统
第一件事是确认通知的分类。建议至少分三类：价格类、运营类（放假、配送调整）、商品类（上新、下架）。分类清楚，后面下游在消息列表里能快速识别，也方便你们统计哪类通知打开率高。
第二件事是确认生效时间与订货时间的先后关系。比如调价通知写「10月1日生效」，但下游9月30日下的单按什么价？这个规则要在配置前和财务、商务确认好，写进公告正文，避免下游理解偏差。
第三件事是准备下游分组。订货宝支持按客户等级、区域、业务员归属等维度分组，如果你们的下游分组本身是乱的，通知范围就会跟着乱。配之前花半天把客户分组理顺，比发出去再撤回要省事。
IV功能升级
常见配错的地方：范围、时间、文案各有一个坑
范围配错最常见。想发给A区域，结果选了全量客户，下游看到不属于自己的调价信息，会来问「为什么我没收到这个价」。撤回公告在部分版本里操作路径较深，而且已经看到的下游无法「收回记忆」，所以发送前的确认页要多看一眼。
时间配错是第二类。生效时间写成当天，但下游习惯提前备货，公告发出时订单已经下了。建议调价类通知至少提前一个订货周期发出，给下游留出调整采购计划的时间。放假通知则要写清楚「最后发货日」和「恢复发货日」两个节点。
文案配错是第三类。只写「价格有调整，详情咨询业务员」，等于把系统通知又推回给人工。正确做法是把调整幅度或新价格表放在公告里，或者附上可查看的价目表入口，让下游能自己确认，减少业务员重复回答。
V功能升级
和手工做法的差别：不是快慢，是留痕和一致性
手工通知（微信群、私聊、电话）的问题是信息碎片化。同一个调价，十个业务员可能有十种说法，下游截图互相核对，反而制造混乱。订货宝的公告是单一信源，下游看到的是同一份内容，口径一致。
另一个差别是留痕。谁在什么时候发的、发给了哪些客户、下游是否已读（部分版本支持已读状态），这些在系统里有记录。遇到下游说「没收到通知」，可以回溯确认，而不是靠记忆扯皮。
手工做法也不是没有优势：灵活、有人情味。所以实际落地时，建议系统公告做兜底和留痕，业务员对重点下游做补充沟通。两者配合，比只用一种更稳。
VII常见问题
被问得最多的几个问题
订货宝的订货小程序、PC商城、微信商城、APP四端都支持消息通知展示，具体展示位置随版本略有差异。发布前建议用测试账号在四端各看一遍，确认公告入口是否明显、内容是否完整。如果下游以小程序下单为主，重点检查小程序端的展示效果。
可以。订货宝支持按客户分组、区域、等级等维度选择通知范围。配置时注意两点：一是确认分组本身是否准确，分组乱了范围就会错；二是调价生效时间和订货时间的先后规则要提前和财务确认，写进公告正文，避免下游按旧价下单后产生争议。
建议系统公告做统一触达和留痕，业务员对重点下游做补充沟通。调价、放假这类信息，系统公告能确保口径一致、有记录可查；但大客户或情绪敏感的下游，仍然需要业务员电话或当面说明。把系统通知当唯一手段，遇到特殊情况反而容易激化。
IV继续看
企业微信 · 专属顾问