先看清这条链路断在哪里
销售是大多数企业里最先跑起来、也最容易散掉的流程。报价在微信里，订单在 Excel 里，发货靠仓库的纸质出库单，回款记在财务的账本上。四段各自都记得下来，拼在一起就没人说得清：这个客户到底欠多少？这张单子发到哪一步了？上个月报出去的价最后成了几单？
常见的症状不是"没有记录"，而是同一件事被记了四遍，四遍还不一样。业务员手抄一份自己的小账，仓库留一份出库单，财务再录一遍收款。每次对不上都要人打电话核，核完谁也不认谁的。等到老板问"我们应收账款一共多少"，答案要等三天，而且没人敢保证准确。
问题出在数据的组织方式上：这四段业务用的是四套互不相干的表，没有一个共同的锚点把"同一个客户的同一笔交易"串起来。要治它，不是再多做一张汇总表，而是让每一段产生的数据自动引用上一段。
Inkwell AI 构建器在这类场景里的做法是：你用业务语言描述这段流程（有哪些单据、每张单据记什么、要走谁的审批），平台把它落成一套带引用关系的数据结构和配套的管理页面，PC 端和手机端同步可用。下面按"数据怎么建 → 页面怎么用 → 移动端怎么配合 → 上线前查什么"的顺序讲清楚。
数据怎么建：四张主表加一条引用链
销售链路不要一上来就做很大，先把四个核心对象立住：报价单、销售订单、发货单、回款记录。它们之间是一条单向引用的链条，每一环只往上引用一次，不重复录入。
报价单：把价格从聊天记录里捞出来
报价单是整条链的入口，也是最容易被忽略的一环。它的字段不需要复杂：客户（引用客户档案）、报价日期、有效期、明细行（产品、数量、单价、金额）、合计金额、状态（草稿 / 已发出 / 已接受 / 已作废）。
两个细节值得在建的时候就定下来：
- 有效期必须是必填字段。 后面所有"报了价没成交"的分析都靠它和状态来判定。
- 明细行的单价允许手工改。 报价本来就是有议价空间的动作，锁死取价规则反而没人愿意用。但改动要留下痕迹，这是审计的事，不是阻止改价的理由。
销售订单：从报价一键生成，而不是重新录
销售订单承接报价单，字段结构类似，多出来的是交期、收货地址、结算方式、审批状态。关键设计是：订单可以从报价单转过来，转入时把客户和产品明细带进来，业务员只补交期和地址。
这一步是整个方案能不能落地的分水岭。如果转订单还要重录一遍明细，业务员就会跳过报价直接开单，报价环节又空了。带数据这件事听起来简单，实际决定了系统有没有人用。
订单需要一条审批流：超过一定折扣或账期的单子要主管确认。审批走平台内置的工作流引擎，配置成可视化流程即可，不用为它单独开发。
发货单：引用订单，不允许凭空创建
发货单挂一个必填的"来源订单"引用，创建时只能从已生效的订单里选，选好之后明细自动带出，仓管只填实发数量和物流信息。
这里有个必须守住的口径：发货单不能脱离订单单独存在。 一旦允许自由创建，"未发货订单"和"已发货量"这两个数字就永远对不上，超发漏发的提醒也就失去了依据。
回款记录：只做登记，不做核销计算的重活
回款是最容易做复杂的一环。第一版建议只做最朴素的记录：客户、收款日期、金额、收款方式、关联订单（可选）、备注、经办人。
先不要做"一笔回款按比例分摊到五张订单"这种自动核销——那是财务总账的职责，业务台账阶段做到"能记下每笔钱进了哪个客户名下、对应哪张单"就已经解决了大部分争吵。等业务跑顺、大家习惯在里面登记了，再考虑核销规则。
引用关系靠平台的引用引擎落地
上面这些"引用客户""引用订单"的关系，不是手写外键拼出来的。平台有一个引用引擎，模块之间通过软引用建立关联：下拉选项直接从被引用模块的列表里取，客户改名之后历史单据上的显示跟着走，同时保留下单时的关键字段快照（比如成交价），避免事后改档案把历史账改花了。
金额一律用"分"为单位存储，页面上显示成元，两位小数。这是为了避免浮点误差在累计的时候越攒越多——销售台账最怕的就是合计差一分钱。## 页面怎么用：三类人看三张视图
数据建好之后，页面的价值在于让不同的人打开就看到自己该管的事，而不是所有人共用一张大表格。
业务员：我的客户、我的单、我的回款
业务员的主视图是列表加筛选。默认只看"负责人是我"的单据，可按客户名、订单号、状态、日期区间过滤。三个高频动作要放在最显眼的位置：新建报价、报价转订单、登记回款。
订单列表上直接显示回款进度（已回金额 / 订单总额），不用点进详情就知道哪张单还欠着。这个字段是由回款记录汇总出来的，属于只读的派生值，不允许手工编辑——否则又变成两套数字。
销售主管：漏斗和异常
主管关心的是过程而不是单笔。两个视图够用：
- 报价转化视图：一段时间内发出的报价，按状态分布看有多少已接受、多少过期未回复。它回答的是"我们的报价到底能不能落地"，而不是"大家忙不忙"。
- 异常清单：超期未发货的订单、超过账期未回款的客户、折扣超出权限的单子。异常清单比统计图更能推动动作，因为它直接指向"今天该找谁"。
需要图形化的部分（阶段漏斗、月度成交趋势）平台支持图表组件，可以搭在看板上；但第一版建议先把异常清单做扎实，图表是锦上添花。
老板：一张应收台账
老板的问题通常只有三个：这个月做了多少、还有多少没收回来、哪家客户欠得最多。这三问对应一张聚合页——按客户分组的应收余额表，点开某个客户能看到他名下所有未结清的订单和对应的回款流水。
这张页面全部由前面的数据算出来，不需要任何人额外录入。这是判断方案对不对的试金石：如果老板要的数还需要人另外填，说明数据结构没建对。
字典与口径统一
产品类别、结算方式、客户等级、回款方式这类枚举，交给平台的数据字典集中维护。好处是所有模块的下拉选项来自同一处，改一次全局生效，不会出现"A 模块叫电汇、B 模块叫银行转账"这种对不上的情况。
移动端怎么配合：销售的现场在手机里
销售业务有一半发生在公司外面：见客户时当场报价、仓库提货时确认数量、出差路上批单子。PC 端建好的模块会自动同步到移动端，不需要为手机单独再做一套，这一点在选型时很关键——很多系统失败就是因为"手机上打不开，出去就见不了客户"。
移动端在这条链路上的典型用法：
- 报价现场出单。 在客户面前把明细录进去，价格当场生成 PDF 或截图发出去，比"回去整理好明天发您"专业得多，也少了一次变数。
- 审批随手完成。 折扣申请、超账期放行的审批推到手机端，主管在车里就能批。审批卡两天，是客户流失最常见的内部原因。
- 回款拍照留证。 收到现金或银行水单，当场拍照上传附件并登记金额。附件走平台的文件存储能力，和回款记录绑在一起，事后核对不用再翻聊天记录。
- 查客户的家底。 拜访前打开客户档案，历史订单、未结欠款、最近一次跟进一目了然，不至于当着客户的面问"我们上次做到哪了"。
外勤网络不稳时优先保证"能看能记"，复杂的批量操作留给回办公室后的 PC 端，这是双端分工的实际边界。## 上线前查什么：五组动作走一遍
发布之前，用真实业务语言把链路跑通一遍。下面这五组检查，任何一组过不去都不要急着给业务员用——系统的信任只有一次机会，第一周算错一次数，之后大家就回去用 Excel 了。
- 引用完整性。 新建报价 → 转订单 → 生成发货单 → 登记回款，全程不手工重录任何一项客户或产品信息。中途删掉一个被引用的客户，系统应该拦住并告诉你哪几张单在用他，而不是静默留下空引用。
- 金额一致性。 明细行合计与单据总额始终相等；改一行数量，总额和已回款比例同步刷新；所有金额显示两位小数、无浮点尾差。用一笔带折扣、数量为小数的极端单子去试。
- 权限边界。 普通业务员看不到别人的客户和价格；主管能看本部门但不能改历史单据；财务可以登记回款但不能创建订单。权限按平台的角色体系配置，逐条对照"谁能看、谁能改、谁能删"实测，不要凭配置界面推断。
- 状态流转不可逆的地方真的不可逆。 已生效的订单不允许退回草稿随意改动，作废要走作废流程并保留原记录。销售数据是对外承诺的凭证，可随意篡改的台账没有意义。
- 移动端闭环。 用手机完成一次完整报价加一次审批，检查字段是否齐全、附件能否上传、下拉引用在手机上是否正常加载。别只测 PC 端就发布。
另外提醒一件事：历史数据先只导入三个月。把更早的单据一次性全灌进去，看起来数字漂亮，实际会让新系统在试运行期背下旧账的对不齐问题，很难分清是迁移错了还是新功能有 bug。等链路稳定跑顺，再补历史。
之后怎么延伸：这条链还能长出什么
销售链路立住之后，它能成为很多模块的数据源头，扩展的成本比从零建低得多：
- 库存联动：发货单扣减库存，缺货时下单环节就提示，而不是发不出货才知道。
- 采购触发：接单后按缺口生成请购，把"以销定采"变成自动动作。
- 应收应付台账：回款记录向上汇总成客户应收，与采购侧的供应商应付合成老板的资金视图。
- 售后工单：从某张订单发起报修，设备序列号、售出日期、保修状态直接带过来。
- 提成与业绩核算：以回款而非订单为口径计算业绩，这是大多数公司真正想要的算法。
这些都不需要推翻现有结构，只是在同一条引用链上继续挂对象——这正是先把四张主表的关系建对的原因。
小结
销售数字化最容易犯的错，是想一步到位做一个"完整的 CRM"。真正能落地的是反过来：先把报价、订单、发货、回款这四张表和它们之间的引用关系立稳，让每一段产生的数据都能自动流向下一段，然后在这个基础上长出看板、权限和移动端。
判断标准也很朴素——老板问"这个客户还欠多少"的时候，答案是从系统里读出来的，还是从某个人的记忆里想出来的。