人从五六个涨到十几个，老板反而更忙了：每天在几个业务员之间来回协调，客户撞车、报价口径不一、交付掉球，最后所有事还是压回自己身上。很多老板第一反应是"人不够"或"人不合适"，于是继续招人、继续换人，问题照旧。这篇只讲一件事：团队的组织架构怎么设——分几层、部门怎么切、一个主管带几个人、什么时候该调整。要招几个人、招什么样的人、入职后怎么带，各归专篇，本篇不展开。

一、先分清：是组织问题，还是人的问题

三种最常见的误判。

缺人式加人：活干不完就加人，加完发现沟通成本更高，活还是干不完。真正卡住的往往是没人对一件事负责，而不是没人干活。

能人式补位：哪个环节出问题就找个能人塞进去，能人在时一切正常，人一走立刻塌。这说明补的是人，不是位置。

制度式空转：流程、表格、会议都齐了，但没人按它执行。多数时候不是制度写错，而是制度没挂在具体位置上，没人被要求对它负责。

一条判断标准：把同一个人换个位置、把同一件事换个流程，问题就消失，那是组织问题；换了人换了流程问题还在，才可能是人的问题。先分清，再动手。

二、动手之前，先把三条业务线摆出来

任何规模的团队，实际都在跑三条线。

开发线：找新客户、前期沟通、报价、推进到首单。产出是新的合作机会。

交付线：接单之后的生产跟进、单证、物流、尾款、售后。产出是订单按时按质做完、钱安全收回。

支持线：资料与内容、数据整理、工具维护、报价与方案支撑。产出是让前两条线少走弯路。

把三条线各自写清三件事：产出什么、最容易卡在哪、谁对这个结果负责。写完通常就会发现，问题集中在某一两条线的交界处——比如开发承诺了交付做不到的事，或者交付占用了开发太多时间。组织架构要解决的，正是这些交界处。

三、按阶段设层级：三种形态

层级不是越多越专业，而是刚好够用。

阶段 典型信号 层级设置 汇报关系
一人统筹 老板能叫出每个在谈客户的名字，在谈客户一双手数得过来 老板直接带每个业务员，不设中间层 所有人向老板汇报
设组长 老板开始靠开会才知道进度，业务员之间开始撞客户 分设几个小组，每组一名组长 组员向组长，组长向老板
设部门 开发与交付互相拖，支持工作没人固定负责 开发、交付、支持分开成部门 部门负责人向总经理汇报

设组长的意义不是多一个官，而是把"每天问进度"这件事从老板身上挪走。设部门的意义不是多几块牌子，而是让每条线有明确的负责人和评价口径。判断标准很简单：老板每天花在协调上的时间，比花在客户和策略上的时间多，就该设一层。

四、管理幅度：一个主管带几个人合适

管理幅度看三件事，不是看人头数字。

工作相似度：同一套动作重复，一个人能带得多；每人干法都不一样，带得就少。

客户复杂度：客户决策链长、条款复杂、交付要求高，需要主管介入的场合就多，幅度要收窄。

事务性工作量：如果主管一半时间在填表、催单、对账，他能带的人自然更少。先把事务性工作收走，幅度才提得上来。

超过幅度的处理顺序：先按客户或市场拆组，再补交接规则，最后才考虑加管理层。反过来做，通常先多出一个管人的人，问题一个没解决。

还有一条常被忽略：加管理层是加成本，不是加能力。管理岗的价值在于让一线的产出可复制，如果他只是在传话，这个位置就是负担。

五、部门怎么切：按市场、按产品线、按职能

切分方式 什么时候适合 主要风险
按市场切 不同市场的语言、时区、认证与采购习惯差别大 各市场重复投入支持工作，资源分散
按产品线切 产品技术差异大，需要不同的专业话术与方案 同一客户被不同产品线重复打扰
按职能切 客户需求相对统一，需要开发与交付各自专业化 交接环节多，责任容易掉在中间

三条硬规矩：一条线只有一个负责人；交界处写明谁主导、谁配合；跨线冲突由上一级当场定，不留给下面反复协商。

中小团队常见的做法是混合切：客户按市场分组，支持职能集中到一处。这样既不重复投入，也不会出现一个客户被几个人轮番联系。

六、什么时候需要中台

前中后台分离不是大公司专属。前台打仗，中台赋能，后台保障。中台存在的理由只有一个：让一线不用重复造轮子。

出现这三个信号，就该把部分职能收上来：同类工作被几个人各做一遍；客户资料、报价口径、案例素材散在各人手里；跨部门抢资源、抢支持，靠人情协调。

中小团队的中台可以先由一人兼任，但必须做到两件事：资料集中存放、口径统一发布。只挂牌子不收资料，等于没设中台。

七、架构调整的三个时机

看到这些信号，才谈调整：老板每天在救火；某个主管的下属已经顾不过来；跨部门协作经常掉球、客户投诉变多；新人上手越来越慢、老人越来越忙；业绩在涨但利润没跟上。

真正适合动手的时机有三个：业务跨过一个明显台阶；客户结构发生大变化，比如从零散订单转向少数大客户；关键岗位出现空缺或人员变动。

反过来，业务平稳、团队刚磨合顺手的时候，不要为了"看起来正规"去改架构。架构要跟着业务走，不是业务跟着架构走。

八、过渡期最容易出事的三件事

先立规则再动人。调整方案里必须写明谁向谁汇报、什么事谁审批、每个人的评价口径怎么变。规则不清就动人，第一周就会开始内耗。

老人怎么安置要有明话。原来的组长变成组员，或者被并到别的部门，必须给明确的新角色和新的评价标准，不做暗降。含糊处理，走的往往是最能干的那个。

流程要同步改。架构变了流程没变，等于把旧流程塞进新盒子，最后还是回到老样子。

调整后留一段观察期，只看三件事：客户有没有掉球、决策是不是变快、一线花在客户上的时间有没有变多。三件事都没有改善，说明改的是结构，没改到责任。

九、与邻近主题的切分

本篇只讲层级怎么设、部门怎么切、管理幅度怎么定、什么时候调整。团队要几个人、什么信号才加人、谁负责开发谁负责跟单，属于角色分工与编制；招什么样的人、怎么面、试用期怎么验，属于招聘与试用期；入职后的系统培训与带教节奏，属于新人培训；指标怎么定、怎么考，属于考核。这些只点名，不展开。

十、发布前自查（10项）

[ ] 是否先分清组织问题与人的问题，再决定动不动架构

[ ] 三条业务线是否写明产出、卡点与负责人

[ ] 当前层级是否刚好够用，有没有多余的管理层

[ ] 管理幅度是否按工作相似度、客户复杂度、事务量判断

[ ] 超幅度时是否按先拆组、再补规则、最后加人的顺序处理

[ ] 部门切分方式是否与市场、产品、职能的实际差异匹配

[ ] 每条线是否只有一个负责人，交界处是否写明主次

[ ] 中台是否做到资料集中、口径统一

[ ] 调整方案里是否写明汇报、审批与评价口径

[ ] 调整后是否有观察期与三条验收标准

——林芳老师 | 外贸圈集团创始人、10倍业绩增长模型创始人