企业官网建设流程全解析

门店这门生意，最近两年被讨论最多的不是选址、不是选品，而是"人进来之后有没有留下痕迹"。"口袋牛店进店码、好店主、火红信使、彩站云、云彩店"这一串词放在一起看，指向的其实是一套很典型的线下门店数字化组合：进店码把路过的顾客变成可识别的ID，店主端把日常经营动作搬到手机上，消息通道负责在合适的时间把人叫回来，云端门店则把一家店的账、货、人收拢到一张网里。我做门店系统落地这些年，见过太多老板在这四件事上各买一套工具，最后数据互相不认、店员懒得用、消息发出去石沉大海。这篇就按这四块拆开讲，从选型逻辑到编码规则、从权限模型到对账机制，把我实际踩过的坑和可以直接抄的做法写清楚，不管你是自己开三四家小店，还是在给连锁做实施，应该都能拎出几条能用的东西。

1. 先把这套组合的问题边界划清楚

1.1 到店流量到底在哪三个环节漏掉的

很多店主一提"数字化"就想到做个会员系统，但真正漏客的地方往往在前面。第一个漏点是"进门没识别"：顾客进店、逛一圈、走了，你对这个人一无所知，连他是第一次来还是第无数次来都分不清。第二个漏点是"成交没留痕"：收了钱、打了小票，但这个人跟店里没有任何绑定关系，下次他换条街照样逛。第三个漏点是"离店没触达"：人走了就彻底消失，你既不知道他多久没来，也没有低成本的方式叫他回来。

进店码要解决的是第一个漏点，店主端解决第二个，消息通道解决第三个。这三个环节是串行的，任何一环断了，后面的投入都是白花钱。我见过一家三十多平的小店，花了不菲的预算做会员储值，结果门口连个码都没有，进店转化全靠店员口头问"办张卡吗"，一个月办出去十几张。后来只做了件很朴素的事——把进店码贴在门口和收银台，扫码就能领一张小额券，一个月新增识别用户翻了好几倍。工具本身不神奇，神奇的是它把"无法识别"变成了"可识别"。

这里要提醒一句：三个环节的顺序不能反。不少项目一上来就做消息群发，用户池里全是店员手动录的手机号，触达成本高、退订率高、投诉也多。先把识别做起来，触达才有意义。

1.2 四个角色的真实需求根本不一样

做门店系统最容易犯的错，是把"门店"当成一个用户。实际上至少站着四类人，需求差得很远。

顾客侧最关键的指标是"扫码到完成不超过三步"，多一步流失一大截。店主侧最关键是"打开就知道今天怎么样"，不要让他去点五层菜单找一个数字。店员侧最关键是"不出错"，因为出错了他要被老板说，所以任何需要判断的地方都要给默认值和二次确认。运营侧最关键是口径统一，同一个"进店人数"在四个报表里出现四个数，这套系统基本就废了。

我的经验是，需求评审的时候四类人至少要各找一个真实代表坐下来聊半小时，别只看需求文档。店员说"这个按钮太小了手上有油点不到"，这种话在文档里永远看不到。

1.3 为什么是"码+端+信+云"而不是一个巨型系统

有人会问，为什么不直接买一套大而全的门店ERP，非要把这四块拆开。原因很现实：这四块的技术特性、迭代节奏、故障影响面完全不同。

进店码是"一次做好、长期不动"的东西，物料印出去贴墙上，改一次成本极高，所以它的编码规则必须一次设计到位。店主端是"高频迭代"的东西，老板每天都要用，一周一个小版本很正常。消息通道是"外部依赖最重"的东西，受平台规则、运营商通道质量影响，需要独立监控和降级方案。云端门店是"数据底座"，最怕的是口径变来变去，所以它的模型要稳，改起来最慎重。

把这四种节奏完全不同的东西塞进一个系统，结果一定是：因为码不能改，所以端也跟着不敢改；因为端上线频繁，云端的表结构被反复折腾。分开做、用统一ID打通，才是可持续的做法。当然，拆开不意味着四套账号体系，账号必须是统一的，这点后面权限模型那节会细讲。

2. 选型：每个模块都有一组"看起来都行"的选项

2.1 进店码的三种形态，选错了后期很痛苦

进店码看着就是"印个二维码"，实际选择不少，而且各有各的代价。

第一种是静态链接码，二维码里直接是一段固定网址。优点是生成简单、不依赖任何平台，打印出来就能用，十年不失效。缺点是无法区分渠道，门口贴的、传单上印的、外卖袋里塞的，扫进来是同一个入口，你没法知道人从哪来。

第二种是带参数码，网址后面挂不同的渠道参数。这是我最推荐的起步方案，成本几乎不增加，但能立刻分清"门口码、传单码、收银台码、员工分享码"四类来源。落地的时候我会给每个物料一个独立短码，比如门口 A01、收银台 A02、外带包装 A03，后台按短码统计，物料上不印长参数，看起来干净。

第三种是动态码，码的内容会变，通常带时效或者带一次性的场景值。适合防止截图转发、防止物料被替换，但需要后端配合刷新，物料要么是电子屏，要么需要定期换贴。小店用这个属于过度设计，连锁且对防刷有要求时才考虑。

选择逻辑其实很简单：先问自己"我要不要知道人从哪个物料来的"。要，就上带参数码；不要，静态码足够。我建议所有的店都上带参数码，因为这是唯一一个几乎零成本、却能回答"哪张传单有用"的方案。

注意：码一旦印到物料上就是沉没成本。上线前务必用至少五台不同型号的手机、三种不同的扫码入口实测一遍，包括系统相机、社交软件扫一扫、浏览器扫一扫。有些定制机型对二维码容错级别敏感，容错级别建议不低于 M，面积小的物料用 H。

2.2 店主端选原生还是网页，关键看店员的手

店主端的技术路线常见三条：原生应用、网页（H5）、以及跑在社交平台里的小程序形态。

原生的好处是性能和硬件调用，扫码、打印小票、调摄像头都快，弱网下体验也稳。代价是发版要过审核，紧急修个bug可能要等一天，而且店员要下载安装，这一步流失不小。H5的好处是改了就生效，发个链接就能用，缺点是在低端安卓机上卡顿明显，摄像头调用经常被拦。小程序形态介于两者之间，安装门槛最低、调用能力够用，问题是对平台依赖重，平台规则一变你就得跟着改。

我的取舍是：店主本人用小程序形态，店员收银台用原生。店主看数据、审批、看报表，随时随地，不需要装东西；店员在固定工位上，装个原生应用，接扫码枪、接小票打印机都方便，也不容易误触。这套组合我落地过几次，店员接受度明显高于"全都要装App"。

还有一个容易忽略的点：屏幕尺寸。店员用的往往是便宜的安卓平板或者旧手机，字号如果按设计稿的12px做，在那种屏上基本看不清。我一般要求关键数字字号不低于18px，按钮点击区不小于44×44，这些细节决定了"店员愿不愿意用"。

2.3 消息通道不是选一个，而是排一个优先级

"火红信使"这类消息触达能力，最忌讳只押一条通道。实际运营中，触达效果是一个漏斗：发出去、送达、看到、点开、到店。任何一环的损耗都需要别的通道来补。

我把通道按"成本—到达率—打扰度"三个维度排过很多次，结论比较稳定：

实际策略是分层：日常状态类走站内，活动类走社群，钱相关的（券快过期、储值余额变动）走短信，客单价特别高的走人工电话。关键是同一个用户一周内不要被三条以上通道同时轰炸，这个频控必须做在服务端，不能靠各个业务线自觉。

2.4 云端门店：多租户SaaS还是自己搭，看你有几家店

云端门店这块，"彩站云""云彩店"这类形态本质上都是把门店的经营数据放到云上，让多店可以看到彼此、让老板可以远程看店。选型上就两条路：用现成的多租户服务，或者自己搭一套。

判断标准很直接：门店数量在10家以内、没有特殊流程，用现成的。现成方案的边际成本极低，一家店一年几百块，功能覆盖八成需求。超过10家、或者有很特殊的业务规则（比如称重商品、组合套餐、跨店调拨），就要认真考虑自建，因为定制需求会把你逼到"在别人的系统里打补丁"的境地，那是最难维护的状态。

我更倾向一个中间方案：核心交易和库存用现成SaaS，门店侧的进店码、会员标签、触达策略自己控。因为交易系统的复杂度高、合规要求多，自己造轮子性价比低；而会员标识和触达策略恰恰是最需要灵活调整、最体现运营差异的地方，必须握在自己手里。这两者用一个统一的用户ID打通就行。

3. 进店码从设计到上墙的完整过程

3.1 编码规则要一次设计到位

这是我认为整个项目里最不能省的一步。码的编码规则一旦定下来，后面所有的统计口径都挂在它身上，改起来牵一发动全身。

我常用的结构是：短码前缀 + 门店编号 + 物料类型 + 校验位。举例说明设计思路（这里是示意，不是真实编码）：门店编号用4位（能撑到9999家店），物料类型用2位（门口、收银台、传单、包装、员工分享……），校验位1位用来防手输错误。整串控制在8位以内，短、能读出来、能口播。

为什么不直接把门店ID塞进去？因为要区分物料。为什么不直接用随机串？因为门店新增的时候需要批量生成，随机串没法批量推演，运营每次加店都要找技术。用可推演的结构，运营自己就能按规则生成。

注意：校验位不是可选项。店员有时候会手输码，没有校验位的话输错一位就归到别的门店去了，这种数据污染非常难查。校验算法用最简单的模11或者模10都行，够用。

另外要定死一件事：一个码只对应一个门店 + 一个物料类型，绝不复用。门店搬迁、物料换版，都要发新码，老码保留有效（或者做过期跳转），不能删。删了之后历史数据就对不上了。

3.2 扫码到识别，中间那段路最容易出事

用户扫码之后到系统识别出"这是谁、从哪来"，中间大概有这么几步：扫码 → 解析出短码 → 请求后端 → 判断是否新用户 → 下发落地页 → 埋点上报。这条链路上每一步都可能掉链子。

最常见的掉链子是落地页加载慢。门店里信号往往不好，尤其是地下商铺、老商场，4G信号一格。落地页如果依赖三四个外部资源，首屏就要三四秒，用户直接退出了。我的做法是落地页极度轻量化：只放一个店名、一句权益、一个按钮，全部内联，不加载任何外部字体和图片，控制在50KB以内。

第二个掉链子是新老用户的判断逻辑。有些实现是"设备首次访问即为新用户"，这个在同一个家庭共用手机、或者用户清了缓存的情况下会误判。更稳的做法是后端以账号为准，前端设备标识只作为辅助。如果确实拿不到账号，那就在落地页上做一次轻量确认，别偷偷判。

第三个掉链子是埋点上报丢失。用户在弱网下扫完就走了，埋点请求还没发出去。这块要用本地队列加失败重试，把扫码事件先落到本地，联网后再补传，否则你会发现后台数据比实际到店人数少一大截。

3.3 物料制作与张贴，全是细节活

这块听起来最不像技术活，但实际影响最大。我整理过一份张贴检查清单，每次开店都照着走：

• 材质：室内用哑光不干胶，室外用防水防晒的PVC或者亚克力，普通纸质贴在门口撑不过两周。
• 尺寸：顾客站立位置到码的距离如果是1米以内，8×8厘米够用；2米左右要12×12厘米；玻璃门外面贴的，建议15厘米以上，因为隔着一层玻璃反光。
• 高度：一般在离地1.2到1.5米，也就是正常视平线略低的位置，太高了要抬头、太低了要弯腰。
• 数量：门口一个、收银台一个、包袋或者外带包装上一个，三个起步。只贴一个的店，实际扫码率会明显低。
• 防替换：这个必须提。贴在门外的码，要放在视线可及的位置，每天开店前看一眼有没有被覆盖。我之前见过码被人贴了另一张上去，一天损失几十个用户。
• 说明文字：码旁边一定要有一句话，写清楚"扫了能得到什么"。只写"扫码"两个字的，转化率会差很多。

心得：物料上别印太复杂的图案，二维码四周的留白区（静区）一定要保留，至少四个模块宽。我见过为了好看把码裁到边缘的设计，结果一半机型扫不出来。

3.4 数据看板：进店率到底怎么算

进店码产生的数据，如果只看"扫码次数"是没有意义的，因为同一个人可以扫十次。我通常看四个指标：

这几项必须固定口径，写进看板说明里。我见过最典型的扯皮是：运营说复访率30%，店长说只有15%，一查发现运营用的是"扫码后30天内任意一次扫码"，店长用的是"实际消费"。都没错，但必须提前说清楚是哪一个。

4. 店主端与云端门店真正的难点

4.1 权限模型：别用"角色"两个字糊弄过去

门店系统的权限比大多数系统都麻烦，因为它有"层级"和"范围"两个维度。层级是老板、店长、店员；范围是这家店、这几家店、全部店。这两者组合起来，简单的角色表根本不够。

我一般用"角色 + 数据范围"两段式：角色决定能做什么操作（看报表、改价、退款、发券），数据范围决定能看到哪些店的数据。这样新增一家店的时候，只需要调整范围，不用新建角色。实际配置长这样：

• 老板：全部操作，全部门店
• 区域负责人：查看 + 调拨，指定若干门店
• 店长：本店全部操作，仅本店
• 店员：收银 + 查库存，仅本店，且看不到成本价

这里有个细节必须注意：退款权限一定要单独拆出来。店员能收银不代表能退款，退款是资金出口，出了事很难追溯。我的做法是退款必须店长确认，超过一定金额要老板确认，所有退款操作留操作人、时间、原因三要素。

4.2 多店数据同步：冲突是必然会发生的

云端门店最容易出问题的地方是"同一件商品在两家店被同时卖掉了"。库存如果是简单的加减，超卖几乎不可避免。

处理思路有几个层次。最粗的是定时同步，比如每5分钟拉一次，简单但延迟大，适合库存不敏感的商品。好一点的是扣减时先占位，下单即锁定，支付成功才真正扣减，超时自动释放。再进一步是按门店分库存，每家的库存独立记账、独立扣减，跨店调拨走单独的调拨单，这样冲突面就小很多。

我的建议是：库存按门店独立记，可售数量 = 本店库存，绝不共用一个大池子。共用池子看着省事，实际上是所有麻烦的根源。跨店调拨做成一张单据，出库扣减、入库增加，全程有单可查，出了问题能追溯。

4.3 弱网和离线：门店的网络比你想的差

做门店系统的人如果只在办公室测，上线一定会出事。真实门店的网络环境：老商场里信号死角多、地下店铺经常断网、饭点高峰期带宽被抢、有些店压根没装宽带靠手机热点。

所以店主端必须做离线可用。最低要求是：断网时能完成收银，本地记账，联网后自动补传。要做到这点，几个设计必须提前想好：本地要有一份商品和价格的缓存；离线订单要带本地唯一号，防止补传时重复；补传要有顺序，避免先传了支付后传了订单。

还有一点很多人踩过：离线时不要允许发券和退款。这两个动作涉及权益和资金，必须在服务端校验，离线状态下宁可禁用，也不能让本地自己判断。

4.4 对账：每天必须跑一次的活儿

云端和门店之间，钱和货必须每天对一次。对账不是财务的事，是系统设计的事。我一般会做三层校验：

第一层是订单数对账，门店端记录的订单总数 vs 云端收到的订单总数，不等就查补传队列。第二层是金额对账，门店端实收合计 vs 云端记账合计，差一分也要查。第三层是支付渠道对账，把第三方支付的流水拉下来，逐笔和系统订单匹配，重点看"支付成功但系统未记单"和"系统记单但支付未成功"这两种异常。

这套流程听起来重，但每天跑一次、异常自动告警，实际维护成本很低。最怕的是攒一个月再对，那时候数据已经烂了，根本查不清。

5. 消息触达做不好，前面全白干

5.1 频次控制是底线，不是可选项

我见过太多项目，识别用户做起来了，然后开始疯狂推送，一个月之后用户集体静默、退订、投诉。触达这件事，做减法比做加法重要。

我一般设三道闸：第一道是单用户周频次上限，比如一周最多三条营销消息，状态类通知不计入但也要控量。第二道是同类内容去重，同一个活动对一个用户只推一次，别今天推明天推。第三道是静默期，用户刚完成消费的24小时内不推营销，刚投诉过的一周内不推。

这三道闸必须做在服务端，做成统一的触达网关，所有业务线都从这个网关走。如果让各业务自己控，一定会有人为了KPI突破上限。

5.2 到达率怎么算，很多人算错了

"发出去了"不等于"送达了"，"送达了"不等于"看到了"。指标要分层：

• 发送成功率 = 提交成功数 / 计划发送数（反映接口调用质量）
• 送达率 = 送达回执数 / 提交成功数（反映通道质量）
• 点击率 = 点击数 / 送达数（反映内容质量）
• 到店转化率 = 核销或下单数 / 点击数（反映真实效果）

如果只看到"发送成功率99%"，很容易误以为触达没问题。实际上某些通道的送达率长期偏低，回执还经常延迟好几个小时。所以通道要定期做摸底测试：自己拿一批号码发出去，人工确认收到的时间，一个月做一次，比看报表靠谱。

5.3 文案和时机，比通道更影响效果

同样的通道，不同的文案和时机，效果能差好几倍。我总结下来几条实践：

时机上，到店后2到3小时发一条感谢加小福利，打开率通常明显高于隔天群发；券到期前1天提醒，核销率远高于到期当天。文案上，具体比模糊好，"您常买的那款今天到货了"比"新品上市"有效；短比长好，能在通知栏内看完的，就不要点进去才看懂；一条只讲一件事，塞三件事的结果是三件都做不成。

注意：营销类内容必须留退订入口，且退订要真实生效、即时生效。有的系统退订了还继续发，这种一旦被投诉，整个通道的信誉都会受影响，后续所有消息的送达率都会被拖累。

6. 上线后必然遇到的坑，和我的排查顺序

6.1 扫码没反应、识别错门店

这类问题占了所有反馈的一半以上。我固定按这个顺序查：

我一般会准备一张"万能测试码"，把门店、物料类型都设成测试值，遇到问题先用它验证链路是否通畅，能快速区分是"码的问题"还是"系统的问题"。

6.2 数据对不上，先分清是哪一层的偏差

数据对不上是常态，关键是要有分层的排查思路。我的顺序是：先看时间窗口是否一致（很多分歧只是统计区间不同），再看去重规则是否一致，再看补传数据是否已经到齐（弱网补传有延迟，当天的数据当天看经常不全），最后才怀疑代码。

经验值是：当天的数据不要下结论，至少等到次日。因为补传、回执、渠道对账都有延迟。有些团队为了"实时看板"好看，把延迟数据当成实时数据展示，结果店主看到的数字第二天变了，信任度直接崩掉。看板上一定要标注"数据更新时间"，延迟就延迟，诚实比好看重要。

6.3 消息发不出去或者发了没人收到

排查顺序：先查提交接口是否报错（限流、参数、签名问题），再查通道回执（是否被运营商拦截、号码是否空号），再查用户是否退订或静默（很多"发不出去"其实是发给了被过滤的人），最后才查内容本身是否触发审核。

这里有个隐藏问题：不同通道对内容的审核尺度不一样，同一条文案在A通道能发、B通道被拦。所以文案上线前要在所有在用通道上各发一条测试，别只测一个。

6.4 几条我用钱换来的避坑经验

• 码的规则一定要提前定死，我见过项目上线三个月后要加渠道区分，结果所有物料全部重印，成本比预想高得多。
• 权限先做减法：新系统上线时权限给到最小，用起来不够再放。一开始就给全权限，后面收不回来。
• 离线收银必须做，别指望门店网络，我遇到的断网投诉比功能缺失投诉多得多。
• 对账自动化要做在第一天，等数据量大了再补，工作量是十倍的。
• 看板口径写成文档，谁问都能指给他看，能省掉大量解释成本。
• 消息频控网关要单独部署，别和业务混在一起，这个组件将来所有业务都要用。

最后分享一个我在实际操作中的体会：这套东西里最容易做、也最容易被忽略的，不是云、不是端，而是那张贴在门口的码。它看起来最土、最没技术含量，但它决定了后面所有数据有没有源头。我见过太多项目在报表、算法、大屏上花了大力气，回头一看进店识别率不到两成，所有分析都建在沙子上。所以如果让我重新排一次优先级，我会先把码贴好、把识别做准、把口径定清楚，再谈别的。