三层组织真正的问题
不是没有系统，是事实到不了总部
总部看到的，是合伙人愿意上报的那个版本
客户是谁、跟到哪一步、有没有回款、这个月做得怎么样——这些事实分散在几十上百个人手里，要靠他们自己填表往上报。填得勤不勤、准不准、报不报，取决于人。
等汇总上来的时候，能拿来做决定的那个时间点通常已经过去了。
归属是靠记性和聊天记录定的
两个人跟同一个客户，这在分散作业的组织里不是意外，是常态。但它往往要到签单那天才被发现——那时候谁也退不了，退了就是白干几个月。
一次归属争议伤掉的信任，比它本身涉及的那笔钱贵得多。
业绩和提成是月底才存在的东西
月底汇总、月底对账、月底才知道排在第几、月底才知道这个月挣了多少。中间那三十天里，做得好的人和做得差的人得到的反馈是一样的：没有反馈。
对一支自己找客户的队伍来说，延迟三十天的反馈约等于没有反馈。
三条合起来是同一句话：总部管的其实不是业务，是一叠迟到的上报材料。
入口只有一个
这类系统最大的落地风险不是技术，是没人用
所以我们没有做新的客户端。入口就是他们本来每天都在用的企业微信—— 没有新图标、没有新密码、没有「请大家下载一下」。 合伙人拜访完客户，照常发一条消息，用的还是平时说话的方式； 回到他手上的，是一屏已经整理好、只等他确认的信息。
合伙人不用改变自己的习惯
他做完一次拜访，还是照常说一句话，说的还是人话——不是去某个系统里找表单、选下拉框、填必填项。
他要做的动作只剩确认
回到他手上的是一屏已经整理好的信息，看一眼，对就过、不对就改。这一步是刻意留的人工卡点：确认过的才算数。
所以台账里没有需要事后清洗的脏数据
进业绩统计和提成核算的每一条，都是本人当场确认过的。这比任何事后校验都省事，也更没得争。
那一步确认是刻意设计的质量闸门，不是为了让人多点一下：确认过的数据才会进业绩统计和提成核算， 所以台账里没有需要事后清洗的脏数据，也没有「这个数是谁填的、算不算数」这种争论。 具体怎么识别、怎么归档，会在方案阶段逐项写给你——公开页面上不展开。
归属
撞单在发生的那一刻就解决，不留到签单日
第一次进来就锁住，第二次进来当场拦下
同一个客户被第二个人录入时，系统立刻给出结论，并同时通知双方和他们的上级。争议在发生的当下就被摆到台面上，不留到结算日。留到结算日的争议，争的已经不是归属，是钱。
上线后最直接的变化，不是纠纷少了
是合伙人开始抢着第一时间把客户录进来——因为录了就锁住了。一条规则如果只能靠管理层去催，它迟早会松；能自己长出动力的规则才守得住。 这也是这套系统里我们最满意的一处设计。
系统实际在管的东西
六块，都是原本靠人接力的那几件
组织与权限
总部、区域、合伙人、财务，各自看得到的东西逐层隔开。通讯录跟着组织走，人进人出不用手工维护名单。全表操作留痕——谁在什么时候改了什么，事后查得到。
客户台账
从第一次接触到成交、回款、续约的完整档案，阶段按你自己的业务定义，不套一个通用模板。多维度筛选，随时导得出来。
订单与回款
订单状态流转、回款登记、回款与订单自动对上。签了单但账上一直没有对应的钱进来，这件事系统自己会发现。
业绩实时统计
个人、区域、全局的排名随时能看，不需要任何人做汇总表——「做汇总表」这个岗位动作在这套系统上线之后就不存在了。
提成自动核算
阶梯档位、区域系数、扣减规则都支持。订单状态一变成已签约，预估提成当场推给本人；月末财务在后台核对、批量确认，结算单一次生成。
会话存档与合规
对外沟通记录归档、敏感表述识别，走的是企业主体认证之后的官方存档能力，不是抓取。这一块的开关与范围由你自己定。
这六块里对积极性影响最大的是提成那一块，而且和排行榜不是一个量级：让人当场看见自己挣了多少，比让他月底去对账有效得多。排行榜只对前几名有意义，当场可见的收入对每个人都有意义。
六类预警
不是多报几条，是报给该知道的那个人
跟进超时
客户躺在那里太久没有新动作——这是最常见也最贵的一种流失。
大单待审
金额超过你设定的线，需要有人看一眼再往下走。
回款超期
签了约，但约定的第一笔钱迟迟没到。
回款异常
订单显示已签，对公账上却没有对应的进账。
业绩断崖
某个人或某个区域这个月掉得不正常——掉下去的时候就知道，不是季度复盘才知道。
合规风险
对外沟通里出现了不该出现的表述。
管理层那一端另有一份每日简报：昨天发生了什么、哪几件需要你今天过问，写成一段人能直接读完的话，不是一张还要自己去看的报表。报表要人主动去看，才叫报表；这一份是送到你面前、看完就能决定做什么的。
同一个月
接进系统之后，和靠上报与汇总表的时候
接进系统之后
- ✓客户在拜访结束的那几分钟里就进了台账，本人确认过
- ✓同一个客户被第二个人录入时，当场就有结论，不留到签单日
- ✓签约当天本人就看得到自己这一单大概挣多少
- ✓排名、区域业绩、全局进度随时能看，没有人在做汇总表
- ✓回款和订单对不上，系统先发现，不是月末对账时才发现
- ✓月末财务核对的是已经算好的结果，不是一堆待录入的原始材料
靠上报与汇总表的时候
- ✕拜访完先记在本子上，等有空再填表，等想起来再填
- ✕撞单要等到签单那天才暴露，那时候已经没有体面的解法
- ✕这个月挣了多少，得等到下个月中旬对完账才知道
- ✕总部要看数，先发通知催各区域报，再等各区域催合伙人报
- ✕回款有没有到位，靠财务翻流水一笔一笔比
- ✕月末几天全组的人都在做同一件事：把散落各处的数字凑成一张表
部署在客户自己的服务器上
这是默认形态，不是加钱选项
数据不出你的机房
客户档案、跟进记录、订单与回款，物理存储在你自己的服务器上，不经过任何第三方 SaaS。这不是一个可选项或者加钱项，是这套系统的默认形态。
换个人也接得住
整套用的是通用的开源组件，没有只有我们看得懂的私有部件。源码进你自己的仓库，部署文档、运维手册与培训一并交付——这是交付目标之一，不是附加服务。
交付之后我们进不去
不持有服务器权限、不留后门账号、不做代管。需要协助排查的时候由你临时开权限，事后回收，整个过程的操作记录留在你自己的日志里。
大模型只用在很窄的几处
全部是接口调用，不需要你自建 GPU 服务器；接口账号由你自己充值，我们不代收、不加价。哪个环节会把什么内容发给谁，在方案阶段逐项列明——你可以逐项否决。
还有一件上线时才看得出价值的事：历史客户数据是清洗、去重、定好归属之后一起迁进来的。所以新系统第一天就是满的，不是空的—— 一个空系统会让所有人默认「先按老办法来，等它有数据了再说」，然后它就永远没有数据。
什么时候用不上
这件事有明确的边界
只有一层，而且人都在一个办公室
所有人坐在一起、抬头就能问到进度，这套东西的价值会小很多。它解决的是「人分散在各地、事实只能靠上报」这个具体的病。
合伙人只有几个，而且各自很自觉
五六个人、每周碰一次、每个人都主动同步——表格加人盯着确实还行。这套系统的价值随人数和层级上升，太早上，管理成本比省下来的多。
提成规则还是一单一议
谁优先、比例怎么算、什么情况不计——这些得先有一个人能拍板。规则没定就上系统，只是把要吵的架换个地方吵，而且换到一个改起来更麻烦的地方。
所以你会拿到什么
一条不靠人上报的业务线
其它几套系统分别是什么，看案例索引 →
常见问题
你大概率会问的几个问题
01我们不是这个行业，这套能用吗？+
这套东西的形状跟行业没什么关系，跟结构有关系：你有没有一批不坐在总部、自己找客户自己跟进的人，他们的业绩和收入要不要按规则算清楚。只要这两条成立，形状就是对的。真正需要按你的业务重做的只有两处：识别用的语料（你们平时怎么说话、说的是什么事）和客户阶段怎么定义。其余的组织与权限、归属锁定、提成规则、预警矩阵都是通用结构。诊断时会先判断你的业务离这个形状有多远——如果差得远，我们会直说。
02合伙人会不会抵触？+
会不会抵触，取决于系统是让他多做一件事，还是少做一件事。这套的做法是让合规的那条路比原来更省事：说一句话就完成建档，比自己记在本子上还快；签约当时就看得到自己大概挣多少，比等月底对账清楚；客户录进去就锁住归属，抢着录反而对他有利。所以这件事的关键不在推行力度，在于第一天他打开的是不是他本来就在用的那个界面。
03数据存在哪？你们能看到吗？+
全部物理存储在你自己的服务器上，不经过任何第三方 SaaS。我们不做代管、不留后门账号，交付之后我们也进不去；需要协助排查时由你临时开权限，事后回收，操作记录留在你自己的日志里。大模型部分调用哪一家、哪个环节会发出什么内容，在方案阶段逐项列明，你可以逐项否决。
04它识别错了怎么办？+
识别完不直接入库。回到本人手上的是一屏待确认的信息，看一眼，对就过、不对就改，确认过的才进台账与提成核算——所以错误不会流进业绩统计里。这一步是刻意保留的人工卡点，不是过渡方案。随着你们自己的语料积累，需要改的会越来越少。
05我们能自己维护吗？+
可以，这是交付目标之一。预警条件、提成规则、组织架构、通知给谁，都做成了后台可配置；编排那一层是可视化的，你的技术人员后期能自己调。源码进你自己的仓库，部署文档、运维手册与培训一并交付。
06上线以后新增规则或者新增一类角色，要另外收费吗？+
要。这是我们写进合同的计费规定，在签约时就讲清楚，不会到项目中途才提。规定分两头：日常维护——改阈值、调提成比例、加角色成员、改通知对象、跟进版本、日常巡检与故障响应——你自己的技术人员接得住，也可以购买年度运维订阅；新增一类角色、新增一条业务线、接入新的业务系统，属于一次新的开发，按新项目单独立项计费。这样划分是为了把账算清楚：新增的工作量并进维护费里，要么让维护费虚高，要么让新增的那件事没人认真做。