判断MDR（本文指市场线索承接或培育责任）工作量是否超过容量，不能只数每天拨了多少电话。要先列出每类完整任务包含的准备、沟通、记录、查重、资料核实、交接和异常处理，再估算这些任务需要的净工作时间，与团队实际可用于承接工作的时间比较。若积压持续增长、客户承诺逾期、主动咨询等待变长、记录开始缩水、重复联系增加或销售交接无人确认，容量或流程已经出现风险。
工作量描述“需要做多少事”，容量描述“在保持质量与客户约定的前提下能持续完成多少事”。两者都不是业务结果。某天形成多少MQL、商机或成交，还受输入构成、客户条件、销售能力、产品适配和周期影响，不能用来反推一个MDR应该完成固定数量。
**容量不足是队列、时效与记录质量共同发出的信号。** 单日动作少、某人一次任务耗时长，都不能独立证明团队超载或个人低效。
先把“一个任务”定义完整
一次联系不只是通话时长。开始前要读来源、历史、授权和已有负责人；沟通中要理解并复述；结束后要记录事实、未知和下一步；遇到专业问题还要内部核实；达到交接条件时要准备背景并等待接收。只有把这些动作都纳入，工作量才接近真实。
不同任务复杂度差异很大。发送已经确认的公开资料，和协调产品、销售一起解释复杂问题，不能都算“一条线索”。建议先按任务类型记录完整耗时分布，而不是拿一次最快处理当统一标准。
容量为什么要用净时间计算
日历上的工作时长不是全部可用于线索承接。团队还需要培训、会议、资料维护、质量抽查、系统问题处理和必要休息。请假、跨时区和临时项目也会改变可用时间。容量估算应使用一段时间内真实可用于该工作的净时间，并注明样本期和团队配置。
例如可以使用“可用净分钟 ÷ 某类任务的中位完整处理分钟”形成教学估算，但不能把不同任务硬塞进同一个平均值，也不能把估算写成岗位指标。对于混合队列，应分别估算资料回应、主动咨询、复杂核实和交接等类型，再合并观察。
怎样用计算口径发现缺口而不是规定产能
可以把某类任务的预计需求写成“进入任务数乘以该类完整处理中位时间”，再加上已经到期的积压、必要协作和异常缓冲；供给侧则使用团队在同一窗口的真实净时间。需求持续高于供给，只说明需要进一步诊断，不自动等于某个人效率低，也不直接得出招聘结论。
更稳妥的做法是把资料回应、主动咨询、复杂核实和销售交接分别估算，使用本团队历史实际分布并保留缓冲。公式的作用是提前看见缺口和输入变化，不是算出一个固定的每日任务数，更不能把估算值直接写进个人绩效。
哪些积压信号比电话数量更可靠
第一，已经向客户承诺的动作连续逾期。第二，主动咨询从进入到首次有效回应的等待变长。第三，已分配记录长期没有接收或退回。第四，未完成记录跨日增加，下一位同事看不懂。第五，重复联系、错误归属或错误资料发送出现。第六，员工为了完成数量跳过准备和核实。
这些信号分别指向客户体验、响应、协作和质量。偶发一天不必立即增员，但若在相似输入下连续发生，就需要定位。日报应同时显示积压年龄和原因，不能只报今日完成量。
区分容量不足和流程浪费
积压增加不一定表示人太少。来源字段缺失会让每条线索都要人工追查；产品资料没有统一版本会反复询问；联系人和账户重复会制造多份任务；市场与销售定义不同会让记录来回退；系统接口失败会造成重复录入。这些是流程与数据问题。
可以抽取等待时间最长的几条任务，画出“等待—处理—再次等待”的过程。若大部分时间耗在找资料、确认归属或补重复字段，先修流程；若规则、资料和工具已经稳定，仍有真实客户任务长期无法按约完成，再讨论人员或排班。
怎样记录工作量而不监控式压人
记录目的应是理解任务结构，不是逐分钟追踪个人。可按任务类型、进入时间、完成时间、等待原因和是否需要协作汇总，观察中位数与分布。复杂任务应允许备注，不与简单发送动作直接排名。
如果员工担心如实记录复杂度会被认为效率低，他们会倾向于拆分或省略任务，数据就失去意义。主管需要明确：准确记录未知、核实和客户拒绝同样是合格产出，不用虚假升级状态换数量。
SLA和容量应该怎样连接
市场与销售SLA规定不同入口何时响应、谁接收、怎样退回和异常如何升级；容量评估检查团队能否持续履行这些约定。若一个时限只在低流量时勉强实现，就不是稳定规则。
设置时限前应观察入口紧急程度、客户时区、任务复杂度和人员配置。预约沟通、普通资料下载、已有客户问题不应使用同一时限。容量变化时，需要有备份、排队和客户说明，而不是让系统自动把所有任务标为按时。
自动化可以减少什么，不能替代什么
自动化适合完成低风险、可验证的重复动作，例如保存表单原始字段、检查必填项、通知负责人、生成到期提醒、发现接口失败和提供统一资料入口。前提是数据合同、幂等、权限和失败处理已经建立。
自动化不能替客户表达需求，也不能根据一次行为自行确认预算、采购权限、MQL、SQL或商机。它节省的是搬运和提醒时间，人的容量应更多用于理解问题、核实事实和协调下一步。系统边界可参考B2B营销自动化系统怎样连接各环节。
一个容量诊断教学例子
**以下为教学例子。** 某周小陈的待办持续增加，表面看是新线索变多。抽样后发现，部分任务来自同一活动名单重复导入；另有多条记录因为资料版本无人确认，来回等待；真正客户主动提出的新问题只占一部分。此时直接增加拨打量，会重复联系并扩大错误。
团队先修复去重和资料责任，再重新观察仍未完成的真实任务。如果主动咨询仍持续超时，且准备、记录和交接质量已经稳定，才有理由调整排班或增加承接力量。这个例子只说明诊断顺序，不代表任何真实企业。
容量超过时怎样安全降载
先保护客户已约定事项、主动请求和已有服务，再暂停没有新事实的例行触达。明确哪些任务可以延后，哪些需要备份人员，哪些要向客户重新说明时间。不能通过删除记录、降低MQL标准、缩短必要核实或把未接听写成无需求来“消除”积压。
还可以合并不会损害上下文的准备工作，例如统一维护公开资料、建立常见问题核实路径、减少重复录入。批量处理只优化相同结构，不应用同一句话覆盖不同客户事实。
主管应该看团队容量还是个人速度
首先看队列与流程是否稳定，再看人员之间是否存在培训或分工差异。直接用最快个人作为基准，会鼓励其他人跳过记录和核实。比较时至少控制任务类型、复杂度、等待外部回复和工作时间，并结合质量抽查。
容量是团队系统属性：输入波动、资料、职责、工具、销售接收和管理决策都会影响它。员工可以改善工作方法，但不能单独承担上游错误与下游等待造成的全部积压。
怎样建立一个最小容量看板
最小看板可以包含：各类型新进入任务、完成任务、期末积压、积压年龄、到期承诺完成率、主动咨询等待、记录完整度、重复或错误归属、待内部核实、待销售接收和异常原因。每个数字说明对象、窗口、去重与数据源。
不要把完成沟通、MQL、销售接收、SQL和成交相加。它们可能来自同一联系人在不同阶段的事件，也可能跨越不同时间。看板先帮助发现等待与质量，再与业务结果按群组连接。
学完这一页要完成什么
选取一个具有代表性的工作周期，把任务按类型拆开，记录完整处理时间与等待时间。计算团队净可用时间，观察进入量、完成量、期末积压和逾期，而不是先设定固定产能。抽查几条耗时最长与最快记录，确认差异来自复杂度还是流程。
形成一份容量诊断：哪些时间用于客户价值，哪些用于必要合规与记录，哪些是重复和等待；哪一项可以通过资料、流程、工具或分工改善；改善后观察什么。只有在流程问题处理后仍持续超载，增员判断才有可靠依据。
诊断以后，回到普通工作日的任务队列调整队列顺序和备份，并在可执行MDR日报中持续观察进入量、积压、等待与质量是否真正改善。
结论：可持续完成才叫容量
MDR容量不是一天能拨多少次，而是在不牺牲授权、准备、记录、核实和客户承诺的条件下，团队能持续完成多少完整任务。用净时间和任务结构估算，用积压、逾期与质量验证，再区分流程浪费和人员不足。容量评估的目的不是逼出更高动作数，而是让真正需要回应的人不被遗漏。