企业官网建设流程全解析

“经销商订货系统哪个好”这句话，我在过去几年里被问过不下二十次，问的人从快消品区域代理到建材批发老板，再到做外贸的小工厂。每次我都得先反问一句：你说的“好”，是指上线快，还是指三年以后还能改得动？因为经销商订货系统这个品类里，最贵的从来不是软件本身的价格，而是选错之后推倒重来的时间成本。我见过一个做五金批发的团队，图省事买了一套通用型B2B电子订货系统，价格不贵，界面也漂亮，结果上线两个月发现返利和账期根本算不对，最后整套流程退回微信+Excel，钱白花了，经销商还被折腾了一遍。

这篇东西想解决的问题很具体：在你还没签合同之前，把选型的判断依据讲清楚。我会把市面上主流的三条路线拆开——SaaS订阅、源码买断、开源或低代码二次开发——分别说清楚它们各自解决什么问题、钱花在哪里、什么情况下会翻车。同时单独拿出一个章节讲多语言外贸订货和源码交付这两件最容易被销售一句话带过去、实际落地全是细节的事。适合谁来读？正在给公司挑系统的业务负责人、被老板派来找方案的IT，以及自己想做一套给客户用的技术型创业者。不需要你有很深的技术背景，但需要你对自己公司的订单规则有基本认知。

1. 先把“经销商下单”和“消费者网购”这两件事彻底分开

很多人选型时犯的第一个错误，是拿电商平台的使用体验去要求订货系统：界面要好看、下单要三步完成、最好还能有个推荐位。这些当然不坏，但方向偏了。消费者网购是“一手交钱一手交货”的即时交易，规则简单到可以标准化；经销商订货是“先给货、后结账、年底再算返利”的长期博弈，规则复杂到每家公司都不一样。你用B2C的尺度去衡量B2B系统，最后一定会选到一个好看但算不清账的东西。

1.1 账期、授信与多级价格：B2B订单的三根硬骨头

先说授信。消费者买东西，钱不够就不买；经销商下单，钱不够也照样下，因为背后有额度。系统必须知道：这个客户当前可用额度是多少、这一单占用了多少、发货之后额度怎么扣、回款之后怎么释放。这里最容易被做错的是占用与释放的时点。有的系统下单就扣额度，结果订单一取消额度不回来，客户经理天天打电话吵；有的系统发货才扣，结果客户同时下十单全部通过，超发了货才发现。合理的做法通常是下单时“预占”、发货时“实扣”、取消或超时未发货时“释放”，而且这三步都要留日志，否则出了问题根本查不出来。

再说价格。这是B2B系统里最容易失控的部分。同一个SKU，可能有客户专属价、年度合同价、等级价、阶梯量价、区域价、促销价六种价格来源同时存在。系统必须有一套明确的取价优先级，而且这个优先级要能配置、要能查到“这一单为什么取了这个价”。我在实际项目里通常按这个顺序落地：

// 取价优先级：命中即返回，不做叠加 function resolvePrice(sku, customer, qty, orderDate) { const ctx = { sku, customer, qty, orderDate }; const rules = [ () => queryCustomerSkuPrice(ctx), // 1. 客户+单品专属价（最高优先级） () => queryContractPrice(ctx), // 2. 合同价（带生效区间） () => queryGradePrice(ctx), // 3. 客户等级价 () => queryLadderPrice(ctx), // 4. 阶梯量价（按数量区间） () => queryPromotionPrice(ctx), // 5. 活动价 () => queryRegionPrice(ctx), // 6. 区域价 () => queryStandardPrice(ctx) // 7. 标准价 ]; for (const rule of rules) { const price = rule(); if (price != null) return price; } throw new Error('未找到可用价格，禁止下单'); // 关键：不允许兜底 }

最后一行是我强烈建议坚持的原则：取不到价就报错，不要用标准价兜底。听起来很粗暴，但兜底带来的后果是客户按错误价格下了一百单，你事后要一单一单去对、去改、去跟客户解释，成本远高于当场报错让运营去补价格。

第三根硬骨头是账期与对账。经销商不是每单结一次，而是月结、季结，甚至是“卖完再结”。系统必须能按客户生成对账单，把发货单、退货单、返利、费用扣减全部归集到一张单子上，而且这张单子要能导出成经销商看得懂的样子。很多系统的对账单只能导出一个流水列表，客户财务根本不认，最后还是要人工做Excel。

1.2 那些销售不会主动提、上线两个月才炸的隐性需求

功能清单是死的，业务是活的。下面这些需求，你在跟厂商沟通时如果对方没主动问，基本可以判断他做过的B2B项目不多。

一单多仓发货与拆单。经销商下单时不会关心货在哪个仓，他只管下单；但仓库有库存分布，系统得能自动拆成多张发货单，或者让客服手工指定。拆单之后，物流单号、运费、签收状态都要能分别跟踪，最后再合并回一张订单上，这个“拆得开、合得回”的能力，很多系统是没有的。

起订量与最小包装倍数。整箱起订、整托起订、必须是最小包装的整数倍，这些约束必须在加购时就校验，而不是等到提交才报错。我见过一个系统把校验放在提交环节，经销商下了三十行货，提交时提示“第17行不满足起订量”，然后整单被打回，客户当场就想砸键盘。

退货、换货与冲红。B2B的退货比B2C复杂得多，可能是质量问题、可能是临期、可能是政策调整，退货之后还要影响返利计算基数、影响授信额度、影响对账单。如果系统只支持“退货单”而不支持“冲红发票”，财务那边会疯。

经销商层级与代下单。一级商下面挂二级商，一级商帮二级商下单，或者业务员代客户下单，这类场景在建材、农资、家电行业极其普遍。系统要能区分“下单人”和“收货客户”，权限也要能隔离，不然一级商能看到二级商的价格，第二天就得打起来。

审批流与价格特批。超过某个折扣要审批、超授信要审批、大额订单要审批，这些流程如果系统里没有，就只能走线下，走线下就意味着数据缺失。

提示：把上面这几条抄下来，直接问厂商“这五个场景你们的标准版能不能做、要加多少钱、有没有已经上线的客户案例”。对方的回答速度和具体程度，比任何产品演示都有信息量。

1.3 需求清单的正确列法：按“业务动作—系统能力—验收标准”三列走

大多数人列需求清单的方式是抄厂商的功能列表，然后打勾。这种方式的问题在于，它只能验证“有没有”，验证不了“能不能用”。我建议换一种写法：左边写业务动作，中间写系统要提供的能力，右边写一条可以当场验证的验收标准。

这张表的价值在于，它把模糊的“要支持对账”变成了可验证的动作。签合同前拿着它去要演示，厂商做不到的地方就会露出来，而这些露出来的地方，恰恰是后期加钱最多的地方。

2. 三条路线的钱到底花在哪：SaaS订阅、源码买断、开源二次开发

回到标题里那句“高性价比”。性价比不是价格低，是“你付出去的总成本”除以“你实际用上的能力”。市面上能叫得出名字的方案，基本可以归到三条路线上，每一条的账本结构完全不同，横向比价格没有意义，得比三年的总支出和总折腾。

2.1 SaaS订阅型：三个月能上线，但天花板是提前画好的

SaaS订阅是绝大多数中小经销商体系的第一选择，逻辑很朴素：按年付费、开箱即用、不用管服务器、厂商负责升级。对于订单规则相对标准、经销商数量在几十到几百家、公司没有专职IT的团队，这是最省事的路径。上线周期通常在一个月到三个月之间，实施顾问帮你配好商品、客户、价格政策，培训两轮就能跑起来。

它的天花板也很明确。第一是定制空间有限，你能改的是配置项，改不了的是流程逻辑。比如你想让返利在每季度末自动折算成下一季度的抵扣额度，而系统只支持年底一次性返现，那你就只能人工处理。第二是数据在别人手里，导出能力、接口开放程度完全取决于厂商的策略，有些厂商的API要另外买。第三是长期涨价风险，第一年便宜，第三年续费涨百分之三五十的情况并不罕见，而这时候你的数据、流程、经销商习惯都已经沉在里面了，迁移成本高到只能接受。

我一般会建议走这条路线的团队，在合同里明确三件事：数据导出必须是全量的、格式必须是通用格式（CSV或Excel即可，不必非要数据库备份）、接口调用是否有额外费用。这三条写清楚了，至少将来想走的时候走得掉。

2.2 源码交付型：一次买断之后，才是真正开始花钱

源码交付的意思是，厂商把整套系统的源代码给你，你可以部署在自己的服务器上，也可以自己改。对很多老板来说，“源码在自己手里”这件事有巨大的心理安全感，尤其是一些做外贸的、客户数据敏感的、或者业务规则特别独特的公司。价格上，一次买断通常是几万到几十万不等，看似比SaaS年费贵，但如果按五年摊，很多时候反而更划算。

但账不能这么算。源码交付之后，有三笔支出是销售不会强调的。第一笔是运维，服务器、数据库备份、安全补丁、监控告警，这些以前是厂商的事，现在变成你的事，要么招人，要么找外包，一年下来是实打实的成本。第二笔是二次开发，你拿到源码不等于你能改，改一个小功能可能需要读懂几万行代码，找原厂改要按人天报价，找别人改要重新熟悉。第三笔是版本升级，很多源码交付的项目是“一锤子买卖”，厂商后续的版本更新你要么花钱买，要么就停在交付那一版，两年后技术栈过时，安全问题没人管。

所以我的判断标准是：如果你没有至少一个能读懂代码的人（内部员工或长期合作的外部团队），源码交付的价值会大打折扣。源码不是保险箱，是一把需要钥匙的锁，钥匙就是技术能力。

2.3 开源或低代码二次开发：便宜的前提是你自己有人

第三条路线是用开源框架或者低代码平台搭一套。这条路线在技术圈很受欢迎，因为起步几乎不花钱，而且完全可控。实际做起来，难度在于B2B订货系统的核心难点根本不在增删改查，而在授信、返利、多级价格、对账这四块。开源项目通常给你的是商品、订单、用户这些基础模块，真正值钱的那部分要么没有，要么写得很粗糙。

我见过几个团队用低代码平台搭订货系统，前两个月进展飞快，表单、列表、流程一天配好几个，到第三个月卡在价格计算上——低代码平台处理复杂取价逻辑和多表关联计算时非常吃力，最后不得不用脚本扩展，而脚本一多，低代码的优势就没了，还不如一开始就写代码。

这条路适合两类人：一类是本身有技术团队、把订货系统当作公司内部系统来长期演进的公司；另一类是技术型创业者，想做一个垂直行业的产品对外卖。如果你是纯业务方、没有技术资源，这条路线会变成一个无底洞。

2.4 三年总成本对照：把隐性支出摆到桌面上

下面这张表是我在多个项目里估算后取的中位数区间，具体数字因规模和定制程度差异很大，但结构是可以参考的。

看完这张表你会发现问题所在：SaaS的贵在“持续”，源码的贵在“隐性”，自研的贵在“人力”。所谓高性价比，是选一个和你公司资源结构匹配的贵法，而不是找一个不贵的方式。

对应的三种典型推荐组合，我给个粗略对应的建议：

• 经销商在50家以内、订单规则标准、无IT团队：优先SaaS订阅，把预算花在实施顾问身上，让他帮你把价格和返利配明白，比买源码划算得多。
• 经销商几百家、有区域价和复杂返利、有一定技术接口人：源码交付更合适，一次买断之后自己掌握节奏，但要在合同里锁定质保期和升级条款。
• 外贸为主、需要多语言多币种、客户在国外：源码交付加私有化部署几乎是必选项，因为海外访问速度和数据合规会逼着你把系统放在自己能控制的地方。

3. 外贸订货场景：多语言不是把界面翻译一遍就完事

标题里提到的“多语言外贸订货”，是我见过被低估最严重的一块。很多厂商在演示时会切一下语言，界面从中文变成英文，然后说“我们支持多语言”。这个演示毫无意义。真正的多语言订货系统，至少要做三层分离，少一层都会在上线后出问题。

3.1 界面语言、数据语言、单据语言的三层分离

界面语言是最表面的，菜单、按钮、提示语。这一层用语言包就能解决，成本最低，也是最容易被拿来充数的。

数据语言才是真正的坎。商品名称、规格描述、客户地址、销售备注，这些数据是业务人员录入的，一个中国工厂的商品名是“高强度六角螺栓M8×40”，英文客户看到的必须是“Hex Bolt M8×40, High Strength”。这就要求数据库里商品表要有一张多语言关联表，而不是简单加一个name_en字段。合理的结构大致是这样：

CREATE TABLE product_i18n ( product_id BIGINT NOT NULL, lang CHAR(5) NOT NULL, -- zh-CN / en-US / es-ES ... name VARCHAR(200) NOT NULL, spec VARCHAR(200), unit_name VARCHAR(50), PRIMARY KEY (product_id, lang) );

为什么要单独建表而不是加字段？因为语言数量是不确定的，今天做英语，明年可能要做西班牙语、阿拉伯语，加字段的方式每加一种语言就要改表结构、改代码、改所有查询，维护成本会指数级上升。用关联表，加语言只是加数据。

单据语言是最容易被忘的。订单确认单、装箱单、形式发票，这些单据发出去是给客户看的，必须按客户的偏好语言生成，而不是按操作员当前的语言。我见过一个系统，操作员用中文界面导出的形式发票全是中文品名，发给中东客户之后对方完全看不懂，业务员只能一个个手工翻译重做，系统等于没用。

3.2 币种、汇率与税制：算错一次就是真金白银

外贸订单必然涉及多币种。核心问题不是“支持不支持多币种”，而是汇率在哪个时点取值。常见的有三个时点：下单时、发货时、收款时。这三个时点选哪个，直接影响你的账面利润。

我的经验是，下单时锁定汇率用于报价和订单金额，发货时按实际汇率重新计算成本，收款时的汇兑差异单独记一笔损益，不要试图塞进订单金额里。如果系统只支持一个汇率，那它顶多能用于内部估算，不能用于真实业务。

税制是第二个坑。国内是增值税，出口多数是零税率或者需要单独处理，海外客户所在国家可能还有当地的流转税。系统必须支持“价格含税/不含税”的切换，而且在切换时要能正确反算。这里有个很常见的错误：系统里商品价格是不含税价，展示给客户时加了税，但客户下单时选的又是含税价，两套逻辑混在一起，最后对账时金额永远对不上。

还有一个容易被忽略的是单位换算。国内按箱、按件，海外客户可能按托盘、按公斤、按英尺。同一个商品要有多套单位，且换算关系要能配置，不能写死。

3.3 海外访问速度：决定客户愿不愿意用第二次

这一条纯粹是体验问题，但对续用率影响极大。系统部署在国内，客户在东南亚或者中东，打开一个商品列表要等五六秒，加购之后提交转圈十秒，你觉得客户会用第二次吗？大概率是第一次用完就回去发邮件了。

解决思路有几个层次。最基础的是静态资源走CDN，图片、样式、脚本这些不常变的东西就近分发，能解决一部分打开速度问题。再往上是把应用层部署在离客户近的区域，或者做多区域部署，这里面涉及数据同步的复杂度，要看业务是否需要全球统一库存。最土但最有效的办法是弱网优化：商品列表分页加载、图片懒加载、下单请求做重试和幂等、断网时把草稿存在本地。外贸客户所在地网络质量参差不齐，一个能在两格信号下完成下单的系统，比一个功能齐全但总要转圈的系统有价值得多。

注意：做多区域部署时，订单号生成、库存扣减这类操作一定要避免跨区域强一致调用，否则延迟会把体验拖垮。通常的做法是按区域分号段，或者用中心化的号段服务加本地缓存。

3.4 单证格式与当地习惯：小细节决定专业度

打印模板必须可配置。这不是锦上添花，是刚需。不同客户对单据的要求差异很大：有的要求显示HS编码，有的要求显示原产地，有的要求把唛头单独放一块。如果模板写死在代码里，每来一个新客户就要找开发改一次，业务根本等不起。

日期格式、数字格式也要能按语言切换。中文习惯是2024年5月1日，英文客户看到的是01/05/2024，美式客户看到的是05/01/2024，这两个如果搞混，交货期直接错一个月。数字千分位分隔符、小数点符号在欧洲部分地区是反过来的，报价单上出现这种错误，客户对你的专业度判断会立刻下降一个档次。

时区问题同样要处理。客户看到的“下单时间”应该是他自己的时区，而你后台统计用的应该是统一时区，两个都要有，不能只留一个。

4. 源码交付验收：合同签完之后最容易吃哑巴亏的四个环节

如果你决定走源码交付路线，那么真正决定这次采购成败的，不是签约那一刻，而是验收那两周。我见过太多合同写得含含糊糊，最后交付一堆跑不起来的代码，或者跑起来但改不动，或者改得动但授权有问题。

4.1 交付物清单必须写到文件级别

“交付源码”这四个字太笼统了。合同附件里应该有一条一条列出来的清单，越细越好。下面这份清单是我在项目里用的，可以直接拿去改。

最后一项特别重要。有些所谓“源码交付”，代码给你了，但里面埋了授权校验，换台服务器就跑不起来，或者限制了并发数。这不是源码交付，这是带源码的SaaS。

4.2 授权范围的坑：能不能商用、能不能二次分发

授权这块要分两层看。第一层是你和厂商之间的授权，要写清楚：这套代码你能否用于自己的业务（当然可以）、能否用于给关联公司使用、能否修改后对外销售或分发给你的经销商使用。有些合同写的是“仅限自用”，那你想给经销商开个子账号都要额外付费。

第二层是代码里引入的第三方组件。这是技术性最强、也最容易被忽略的地方。开源许可证分很多种，有些要求衍生作品也必须开源，如果你的系统里混进了这类组件，而你又打算商业分发，就会很麻烦。验收时让对方提供依赖清单，重点看有没有强传染性的许可证，拿不准的就找懂的人看一眼，这一步花半天时间，能省掉将来很大的麻烦。

4.3 三天摸清代码可维护性：几个粗暴但有效的方法

你不需要通读代码，但可以用几个动作快速判断这套代码值不值得接手。

第一，看目录结构。打开项目根目录，如果所有文件都堆在一层，或者文件名是test1.js、new_final_v2.js这种，基本可以判断开发过程很随意，后期维护会很痛苦。正常的项目应该有清晰的分层：接口层、业务层、数据访问层、公共组件。

第二，搜一下字符串拼接的SQL。在代码里全局搜索"select和+同时出现的地方，如果大量存在，说明有注入风险，而且这类代码通常缺少参数化处理的习惯，安全性和可维护性都要打问号。

第三，看有没有环境配置分离。数据库地址、密钥这些东西是不是硬编码在代码里，如果是，说明这套系统从来没考虑过在不同环境部署，你接手之后第一件事就是大改。

第四，让对方当场改一个小需求。比如“在订单列表加一个按客户名称搜索的输入框”，看他们多久能改完、改完之后提交了什么。这个过程能暴露代码的耦合程度和团队的响应能力，比看一百页文档都有用。

4.4 交付之后的技术支持边界

质保期多长、bug多久响应、升级是否收费、原开发人员离职了怎么办，这四条要写进合同。

质保期一般三到十二个月，我建议至少争取六个月，因为很多问题是在真实数据量下才会暴露的。响应时间要分等级，导致系统不可用的问题必须在几小时内响应，界面文案错误可以放到下一版本。升级条款要写清楚：厂商后续版本是否免费提供、是否收费、收费方式是按年还是按次。最后一条最现实，源码交付的项目，最怕的就是对接人离职，接了你的项目的人走了，你的系统就成了孤儿。合同里可以要求厂商承诺核心人员的稳定性，或者至少承诺交付后一年内的技术支持不因人员变动而中断。

5. 两周POC实测：用你自己的订单把系统逼出原形

演示环境是精心布置过的，数据是干净的，流程是最顺的，销售点哪里都通畅。你要看的不是这个，你要看的是它在你自己的脏数据、怪规则、烂网络下能不能活。所以我一直建议，签合同之前一定要做一轮POC（概念验证），两周时间足够。

5.1 POC环境怎么搭、数据怎么准备

让厂商开一个独立的测试环境，不要用他们的公共演示站。然后你把真实数据导进去，规模不用大，但结构要真。

商品准备两百个左右，覆盖不同品类、不同单位、不同价格类型；客户准备三十个，覆盖不同等级、不同区域、不同账期；价格政策至少配五种，包括客户专属价、合同价、阶梯价、区域价、促销价，而且要有交叉重叠的情况，专门用来测取价优先级；库存分布在两个以上的仓库，用来测拆单。

这一步的关键是不要给厂商“清洗过”的数据。真实的商品名里带空格、带特殊符号、带中英文混排，真实的客户地址有长有短，真实的编码有不规范的。你把干净数据给他们，他们配得漂漂亮亮，上线之后你的真实数据一进来就各种报错。

5.2 必须跑通的六条链路

POC不是功能演示，是业务流程验证。下面这六条链路，一条不通就要追问到底。

第五条尤其重要。历史订单的价格绝对不能被追溯修改，这是财务审计的底线。有些系统为了“数据一致”，价格一改所有订单跟着变，这在B2B场景里是灾难。

5.3 并发与峰值：月底和促销日才是真实压力

订货系统的流量有个明显特征：平时很闲，月底集中爆发。经销商大多在月底盘库存、冲返利、集中补货，那几天的订单量可能是日均的五到十倍。如果系统按日均流量设计，月底必然卡。

压测不用做得很复杂，用k6写个脚本，模拟五十到两百个并发用户同时下单，看几个指标：下单接口的P95响应时间、数据库连接池是否打满、库存扣减有没有出现超卖。

import http from 'k6/http'; import { check, sleep } from 'k6'; export const options = { stages: [ { duration: '1m', target: 50 }, // 爬坡 { duration: '3m', target: 150 }, // 峰值保持 { duration: '1m', target: 0 }, // 回落 ], thresholds: { http_req_duration: ['p(95)<800'], // P95 控制在 800ms 内 }, }; export default function () { const payload = JSON.stringify({ customerId: __ENV.CUSTOMER_ID, items: [{ sku: 'SKU-0001', qty: 2 }], }); const res = http.post(`${__ENV.BASE_URL}/api/order`, payload, { headers: { 'Content-Type': 'application/json' }, }); check(res, { '下单成功': (r) => r.status === 200 }); sleep(1); }

压测时要特别关注库存扣减的并发安全。如果实现方式是“先查库存再更新”，高并发下必然超卖；正确做法是带条件的更新，比如UPDATE stock SET qty = qty - ? WHERE sku = ? AND qty >= ?，根据影响行数判断是否成功。这条你可以直接问技术对接人，答不上来或者含糊其辞的，要留个心眼。

5.4 把POC结论变成谈判筹码

POC跑完，你会拿到一张“哪些行、哪些不行”的清单。这张清单非常值钱，因为它在签约前，厂商还有动力解决问题。行的地方不用多说，不行的部分要具体问：是标准功能不支持需要定制，还是配置没配好，还是压根做不了。

对方如果说“这个要定制，加钱”，你就把前面列的三年成本表拿出来重新算一遍，看加上这笔之后还是不是最优解。对方如果说“我们下个版本会做”，那就要问版本时间表，并且要求写进合同附件——口头承诺的版本计划，八成会延期。

6. 上线推广期：系统好不好用，经销商第一周就给你答案

系统上线那一刻，其实才是一半。真正的挑战在于让经销商愿意用。我见过不少项目，系统本身做得不错，但推了三个月，线上下单率还在百分之二十，剩下的全靠业务员代下单，等于花了钱买了个内部工具。

6.1 期初数据初始化：迁移做得糙，后面全是补丁

上线前必须处理四类数据：商品档案、客户档案、期初库存、期初应收。前三类是基础，第四类最容易被忽略，但它直接影响授信。

期初应收的处理有个原则：金额要准，明细可以粗。也就是说，每个客户的期初欠款总额必须准确无误，但具体是哪几张单子构成的，可以只录汇总。经销商不会因为你没录明细而不认账，但如果你把总额录错了一分钱，他能跟你核对一下午。

商品编码要统一。很多公司存在多套编码：ERP一套、仓库一套、销售自己记一套。上线前必须确定以哪一套为准，做一次映射表，否则同一个商品在系统里会出现两次，库存永远对不上。

6.2 经销商分层推广：先让十家跑通，再谈全面铺开

不要一上来就全员推广。挑十家左右配合度高、订单量中等、老板愿意尝新的经销商做试点，跑两周。这两周你要盯的不是系统有没有bug，而是他们卡在哪一步。是登录不上、是找不到商品、是不知道怎么查历史订单、还是单纯觉得麻烦懒得用。

试点跑通之后，再分批次推广。第二批发三十家，第三批再放开。每一批都配一个“种子用户”，让用得好的经销商去跟其他经销商讲，比你自己讲十遍都管用。

培训材料要短。二十页的操作手册没人看，三分钟的手机录屏会传得很快。把最核心的三个动作录成短视频：怎么登录、怎么搜商品下单、怎么查订单和对账单。其他的等他们问了再说。

在过渡期，业务员代下单这个功能一定要有。经销商还不习惯用的时候，让业务员先在系统里帮他下单，客户慢慢就看到系统能查物流、能看对账，用着用着就自己上手了。

6.3 上线第一个月该看哪些指标

不要只看“有多少人登录过”这种虚荣指标，看四个真正有用的。

线上下单率：线上订单金额占全部订单金额的比例。这个数字每周看一次，增长停滞就说明有卡点。

平均下单时长：从登录到提交成功的平均耗时。超过五分钟就说明流程有问题，可能是商品太多搜不到，可能是价格不显示要打电话问。

错单率：因为下错商品、下错数量、下错价格被退回的订单占比。这个数字下降，说明界面设计是有效的。

客服咨询量：上线后如果客服电话量暴增，说明系统在引导上做得不够。咨询的问题类型分布，就是下一版迭代的需求来源。

我个人的经验是，上线第一个月的线上下单率如果能到百分之五十以上，这个项目基本就成了；如果一个月后还在百分之二十以下，不要硬推，回去查是价格没同步、库存不准、还是某个环节真的太难用。

最后分享一点我在多个项目里反复验证过的体会：订货系统这个东西，功能多少不是关键，关键是它能不能让经销商在三十秒内完成一次他觉得放心的下单。放心的来源很具体——价格是对的、库存是准的、下单之后能看到发货进度、月底能拿到清楚的对账单。把这四件事做到位，哪怕界面朴素一点、功能少一点，大家也愿意用；这四件事有一件没做到，界面做得再花哨，经销商还是会转头打开微信。所以选型的时候，与其纠结对比表上有多少项打了勾，不如拿这四个问题去问每一个候选方案，看谁能给出让你信服的答案。