十一点四十五分，苏州一家制造企业的客服主管许晨收到行政同事的消息：“中午的企业微信礼品通知能发了吗？”工单后台显示，试发留下几件待回。七个人已经排班，下午仓配对接人只能和下一班重叠半小时。
许晨和这家公司是虚构的。她先打开测算表，把通知后一小时和仓配交班半小时分开。发之前，她要算清楚七个人能接多少，哪些工单必须由仓配查，以及要把哪一批通知留到下一轮。
先把通知、领取和查单分成能安排人手的队列
许晨把企业微信和小程序打开，问客服同事能不能从两个入口查到同一笔工单。只有能找到原记录，后续排班才知道新增的是一件工作，还是同一件事被两个窗口各处理了一次。
礼品活动可能有多个入口：企业微信里看通知，小程序里提交领取信息，工单系统里联系人工。收到三条消息不一定代表三件事。同一个订单问题若最终归到同一工单，新进工单可以计一件，客服读消息、检查身份和合并记录的时间算到处理工时。若入口没有联通，三个人分别查同一订单，工作量确实发生了。团队可以先保留这一观察，再评估怎样让不同入口汇到同一条记录。
每行代表一个可处理同类问题的队列和一个连续时段。行政能解释领取期限，客服能重发已确认的通知，仓配人员能核对交运，几种处理可能不是一批人。需要仓配核验的地址调整不一定能由在线客服立即处理。可先安排一般咨询、订单核验和仓配联络三个工作范围，具体按实际权限合并或拆开。若一人同时服务多个队列，只在相应工作时段计一次。
AWS 的简体中文容量规划资料介绍如何用预测和人员安排规划客服资源。本文测算表是单独设计的活动工作量工具，例子是虚构的，不采用或假定某个平台的排班结果。文件版本为 2026 年 11 月 7 日的第 1 版。黄色单元格可编辑，样例可用于核对公式，再把实际工单和可用排班写入副本。 AWS 客服容量规划资料
试发留下的是要做的工时，还是在等答复？
待回工单里有一件已联系仓配，只需到约定时间查看结果。许晨从下一步开始估算，避免把前一班已经做完的查询再写进本班工作量。
开始时给每条记录明确时段和队列。对于企业微信通知后集中到达的咨询，先试十五分钟或半小时；对于回执、跟单和内部审批较均匀的队列，可能使用一小时。国内多个办公室在同一时区也可能有不同的班次和工作时间。总部在午休时发通知，仓库当时未必能派出对接人。把排班时点、通知时点、预计咨询到达和仓配可回复时点放在同一张时间表上。
新增工单是当前时段首次交给这个队列处理的工作。调入另一组的记录要与原队列区分，避免两个队列都把一次转交当成完全独立的新增。比如收件人先问能不能换地址，客服确认订单已分配给仓库，然后把请求转给仓配联络人。前者的查单和答复在客服队列，后者的供应商联系计入对应的工作段。两段都有工时，但对外报告时仍可以把它们关联到一笔业务问题。
单单处理分钟包括阅读、查记录、回复、必要的记录补全或交班。供应商答复要等一个小时，并不等于客服持续投入一小时。如果期间客服可以做其他事，工作量只计入联系、核对和下一次跟进的时间；未结案件仍由指定人员追踪。用同一时间范围的样本估算平均处理分钟，同时注明待外部处理的时间是否从工时中剔除。
上一段结束时没完成的部分，按仍需做的事估成剩余工时分钟。如果七件在等待承运商结果，其中只有两件需要本班发出下一次查询，就把两件的实际操作时间放入本班。不能将七件的全部生命周期重新算一遍。有些工单起初登记为一项，但处理过程中发现涉及发货和费用，负责人员可以新增对应工作量，说明在哪一段发生以及怎样交接。留出查单编号和下一次查看时点，减少换班后重复翻找。
把七个人能真正受理的分钟算出来
| 项目 | 定义或公式 | 输入前要核对 |
|---|---|---|
| 时段分钟 | 这一行覆盖的实际分钟 | 通知发出、交班与截止是否一致 |
| 剩余工时分钟 | 前一段留到本段实际要做的工作 | 已经完成的部分不再计 |
| 新增工单 | 新进入本队列的工作数 | 先明确合并与转交规则 |
| 单单处理分钟 | 新工单平均工作量 | 阅读、回复、查证、结案记录 |
| 非受理比例 | 时段中由休息、会议和其他工作占用的比例 | 同一时间不要重复扣除 |
| 受理占比上限 | 剩余时段用于处理工单的比例 | 为波动和临时任务留空间 |
| 需求分钟 | 剩余工时＋新增工单×单单分钟 | 单位统一为分钟 |
| 人均有效分钟 | 时段分钟×（1－非受理比例）×受理占比上限 | 必须大于零 |
| 需求人数 | 需求分钟除以人均有效分钟，再向上取整 | 人员必须在该队列可用 |
| 缺口分钟 | 需求分钟减排班人数对应的有效分钟，最低为零 | 指出按现有班表可能做不完多少 |
最高需求人数和最大工时缺口可能出现在两行，审批排班时应回看各自行的时段及人员类型。
非受理比例指事先知道不用于工单的时间，例如交班、会议、培训或固定的行政任务。受理占比上限表示扣除这些之后，有多少时间能安排给正常工单。两项要避免重复。若夜班同事先参加会议，他的可受理时段已缩短，不能既减少分钟又把同一场会议加到非受理比例。若处理分钟已经包括填好结果和内部流转，也不需要为相同工作额外扣除一次。
人员数以能在这一段负责相同工单的人为准。调来的同事如果只在最后十分钟值守，可以另开一行或缩短窗口，不能当成整段的完整人力。若同一人的排班原本包含仓配、出入库和核验工单，要确认他是否有明确的受理时间。如果只能在固定时点批量查看，按那个时段计划，然后向客户告知由谁负责下一次更新。
输入为零和没有数据要分开。没有新进工单可以填零，有任务但当前没人排班也可以填零。缺少处理时长时留空，此行不会输出结果。受理占比为零也不会计算，因为每人的有效分钟为零。把表中结果搬到日报时，要同时注明待确认的行。缺了数据的时段不应因为汇总只有有效行而看起来已经安排妥当。
中午通知全发，现有排班会差四十八分钟
许晨先算通知后一小时。试发还留三十分钟工作，预计新增四十五单，单单六分钟，合计三百分钟。六十分钟扣掉百分之二十非受理时间，再乘百分之七十五受理占比上限，每人有效三十六分钟。七人合计二百五十二分钟，缺口四十八分钟；能办相同工单且全程在岗的人需要九名。
公司不必立刻把两个名字加到排班上。先看最常见的问题来自哪里。若大部分工单询问小程序领取页面的位置，可以优化经过审批的通知，测试员工从企业微信中是否能找到入口，再更新预计进线。若问题集中在订单范围或地址验证，临时支援的人必须能处理对应系统里的工单。把两人同时安排在所有队列，会掩盖他们真正可用的时间。确认每个人在什么时点开始、能看到哪些订单、遇到授权范围以外的问题找谁。
在预计无法补齐人员时，也可以把通知分成有明确范围的两波。第一波结束后，客服主管检查实际接收工单、新增工时与前段剩余工作。若开始十五分钟的工单就达到一小时预测的大半，第二波负责人需要得到这一观察，按已批准的方式推迟或缩小范围。已发的通知仍有有效的受理方式。未发的部分应由负责通知的人调整，避免客服口头请同事稍等，但通知系统照常执行。把原计划、实际发出、采取的决定和谁批准写到一条记录。
分波还会影响领取时间。如果第一波收件人有三天可选择，第二波晚发但共用一个截止时点，就可能只剩下两天。活动团队应核对这一差异是否在已经批准的条件内，必要时对不同批次说明确切截止日。客服也要按实际发送时间解答，不能只使用一份笼统的回复。若为减少咨询调整了说明，把调整前后的实测数据分开，避免把暂时的低进线当成固定规律。
仓配交班的半小时不能借用中午的容量
第二行写的是仓配交班。前一班留二十四分钟，预计新增十八单、单单八分钟，需求是一百六十八分钟。三十分钟扣除百分之二十五的非受理时间，再乘百分之八十受理占比，人均十八分钟。排班七人只能覆盖一百二十六分钟，缺四十二分钟，按同样工作能力估算要十人。若只有五人能查订单，许晨还要把受限的工作另列。
物流问题可能需要先查承运商是否已经揽收、在仓库里是否仍可取消。上一班若已提交核验，交班时要留原请求号、目前确认的状态、下一步和下次检查时间。下一班沿原记录跟进，确认供应商是否已经受理。对不需要核验的普通咨询可以由另一组接手。需要修改订单时，先找到能作出该决定的人，由其按现有授权处理。不能因为排班缺口就发两份相同的核查或改址请求。
一项应对选择是给仓配联络人保留较长的交叠班次。若他只负责前半段，就把后半段的处理权限落实到下一位同事。另一项选择是把仍未发出的通知移到物流队列较空的时间。第三项是提前发出经批准的配送进度说明，减少收件人重复询问已经确认的同一问题。每一项措施改变的量不同：延长交叠增加有效时间，调整波次改变需求到达时间，优化状态说明可能降低新增工单。修改输入后，再用实际进线和处理情况验证。
如果仓配处理的客户来自不同分公司，订单编号不一定共享一个查询范围。安排人员前，应确认他只需查自己的订单还是已获批准处理跨公司请求。手上有通用的客服任务不等于可以从个人微信转发收件信息。等待对应负责人时，客服可以告诉收件人已经确认的进度与下次更新时间，不作还无法核实的交付承诺。系统恢复或有权人员到岗后，先回到原工单更新结果，并复核是否还有等待中的请求。
用首波的真实进线更新剩余批次
可以从一批试发记录开始。记下发出多少邀请、不同入口什么时候开始出现工单、各类型用时和同一批人可用的时段。与上一次活动比较前，问两个问题：收件人走的是不是相同入口，活动内容会不会引发新的操作。前一场是线下领取，本次是寄送时，地址和配送工单可能变化；前一场只有办公室员工，本次覆盖门店和夜班，接收与咨询的时点也会不同。
计算处理时间时，不要把不同案型的均值随手平均。比如二十四件普通查询每单四分钟，六件仓配核验每单十四分钟，合计一百八十分钟。如果用四和十四的算术平均九分钟乘三十件，会得到二百七十分钟。能够由同一批人处理时，可用一百八十除以三十得到加权后的六分钟；权限和岗位不同，就把两类分别排班。在提供汇总之前，保留这个工作量是怎样计算的。
若没有数据，使用低、中、高三组假设，并说清楚每组是哪个量变了。低值可以是假设活动规模较小或入口说明明确；高值可以是假设通知在同一时间发出，配送问题集中出现。没有进行过小规模测试，就不要称这些数字为行业均值。用一小部分经过批准的人群试发，记录多久开始有咨询，再重新审查对大批量通知的估算。第一波若有新类型问题，先更新当前队列安排，再决定是否沿用原计划。
一天总工单数也不能反映高峰。若半小时内的咨询都集中在刚发通知的三分钟，半小时的预计人力可能够做完工作，但用户仍会排队。要对外说明答复时间，需要另外看实际接入时间、第一次答复、解决时间和等待转交的时长。报告时把“本段工时够不够”与“客户等待多久”当作两个可观察的问题，不把本表结果转换成响应时限保证。
上线前拿一笔虚拟工单试权限和暂停条件
让活动负责人、客服主管和仓配对接人同时确认一份具体的排班。确认谁能决定推迟下一波、谁能核验订单状态、谁有权限向供应商提出变更。拿虚构的工单测试三种情况：同一个人从企业微信和小程序分别咨询，原订单仍只有一笔；客服请求查单时，接手人可以看到已经做过的确认；在没有查单权限的时间段，负责人仍可说明下次何时更新，不私自改发货信息。测试应使用允许的环境与数据。
在试算表里至少检查几行边界。新增工单为零而有剩余工作时，应仍有需求分钟。排班为零且有工时时，缺口等于全部需求。受理占比为零或必要输入缺失时，计算结果留空。变更某一行的排班或工单数量后，看明细和摘要是否联动。把结果复制给业务方时，一并提供试算版本、实际数据的观察时点及仍需确认的队列。
发生意外时先看影响的工作范围。某个值守同事临时不能工作，可以更新当前排班，再查看哪些事项只有他有权处理。渠道发生问题时，让能修复的人负责，同时核对是否要先停发还没发的通知。已经收到的咨询仍有原来的等待时间与负责人员。外部仓配暂时没有回应时，保留工单与下次回访；一般问题仍由适用队列处理。下一时段的剩余工时按实际尚需完成的工作估算，不直接抄前一段的总需求。
活动结束后，业务方可以比较原预测、实际进单、处置时长、排班与未结工时。复盘文档只需保留汇总数值、波次、案型和经过批准的观察。不要把收货地址和私人消息作为排班证据抄进试算表。把响应延误、缺少权限与渠道错误分开讨论，让下一次的决定针对具体问题。若一项改动让通知少发或渠道更清楚，找出它对实际工单的影响，再用于下一次预算与排班。
找到能暂停群发的人，把决定放进时间表
运营负责人可以在群发前记录何时读一次现场数据、由谁提议暂停、实际由谁改变发送队列。举例来说，第一波在十一点四十五分，第二波原定十二点十五分，客服主管在十二点核对已进工单、上班人数、是否发现共同故障。如果需要延迟第二波，应让能够操作通知计划的人确认修改是否生效。若恰好到了实际发送的时间，先看第二波是否已开始，再决定下一步。不要在状态未知时把同一批人放入另一条发送记录。
出现问题时，先判断影响的渠道、批次和工作。小程序入口出现错误，可能有些客户仍可通过原来的其他入口查询订单；仓配系统暂未回传更新，选择期限的咨询仍可受理。现场负责人让能够独立处理的队列继续工作，将故障的证据传给对应负责人。给客户的说明可以包括已经确认的事实、下一次更新以及可使用的联系渠道，不替没有回复的供应商承诺处理结果。恢复发送前，核对现有邀请是否还能用，调整后是否仍是经过批准的对象，新的时段有没有适合的排班。
分波后，留意领取期限和仓配作业的承接。多个办公室或工厂的员工可能在不同班次看到通知。晚一批发出的员工如果仍面对同一个截止时间，会少一些选择时间。若需要修改领取期限，确认由谁审批及影响哪批；联系已经收到通知的员工之前，核对是否真的需要补发，避免同一订单引发更多询问。仓配团队若只有上午能集中核单，不要在修改波次后默认为下午也可处理。将下次可查时间和需要负责的岗位写入对应时段。
换班时按原工单接着查，别让同一问题多占一轮工时
客服向仓配交班时，一条工作记录可以只说明原工单、当前已经确认的订单状态、已联系过的对象、下一次查看时点和需要决定的事项。例如上午已请求仓库确认是否可以改址，下午负责人的任务是读取原请求结果并更新客户；还没有结果时，照约定时间复查。将所有未关闭的工单从头算一遍，会高估工时，还可能让下一班重复发出同一请求。只给下一班有效的工作与证据索引，让每个人按权限查到所需信息。
如果交班发生在业务高峰，中间可能需要腾出十分钟做相互确认。将这些分钟放入实际班表，或作为这个时段的非受理时间。不要认为交班上的两个人都能用完整的十分钟处理同一队列。若有一位同事参加了交班，却在剩余时间负责不同类型工单，在各自队列里按实际分钟安排。工作表用来帮助找人和找时间，具体岗位范围仍要由班组主管落实。
安排一个小测试能发现记录的遗漏。给值守人一笔虚构订单，包含联系过的物流方、仍要核对的状态和预计回复时间。换班同事能否找到原请求，能否看懂原来已做过什么，能否正确说明下次更新。如果不能，先改善交班内容，而不是假设熟悉系统的同事可以弥补。然后换一个缺少订单查询权限的测试身份，看看受理人能否正常把工作交给适用岗位。将需要另行授权的步骤留给已确认的责任人。
活动结束后保留可复用的工作量依据
把预计的工单量与真实进线在同一时间窗口比较。举例来说，首小时实际新增三十五单，不一定意味着原四十五单估计过高。可能有一部分员工直到下午才打开通知，或者活动说明变更后，部分问题转为次日来询。可以顺着实际时间观察后续时段，看是否有迁移。再核对平均处理时长是否更高、在班的人员是否有改变，最终指出缺口减少是工作量降低、工时转移还是投入了更多人员。
复盘时要能找回哪些数字来自试算、哪些来自实际工单。如果第一轮以公司工单为准，而第二轮用企业微信消息条数，先恢复相同的统计口径再比较。若确实无法合并，标明分别代表工单和接触次数。公司可以用这些观察改进下次通知和支持流程，不必长时间把个人对话、地址和证件资料放进排班文件。保留业务时间窗、工作类型、实际分数、调整措施和负责人，足以解释大多数排班决定。
如果为了复盘重新估一个类似的活动，不要覆盖当初使用的数字。保留批准时版本以及事后校正的版本，并记录变更依据。例如首波实际只发三百人而非预估的四百人，直接替换输入会让前后结果看起来很接近，却掩盖原排班是为更大波次做的。将发生的发出范围和剩余工作分别写入，下一次评估便能知道原预测在哪些条件下适用。
群发前，排班负责人还会问什么
能把多个队列的最大人数加在一起报给负责人吗？
先看高峰是不是同一时间，以及负责人员是否重叠。若两条队列在不同时点达到最高值，有人员可以正常切换，就不一定需要把两项最高值同时排上。若同一时间需要两种权限，应查看每个岗位实际可用的人。用各队列的时段表对齐后再确定补位。
为什么有工单没关闭，却没有算在本时段剩余工时里？
仍需等待外部答复的工单要有负责人和下次检查时间。若本时段不需要实际操作，可以在到期后将查询或答复工时计入相应时段。不能因为没计工作量就不跟进，也不需要把等待的全部分钟算作客服一直在处理。
一次小范围试发能确定以后的进线率吗？
试发可以提供一个具体起点。后续活动的受众、入口、截止日期和供应商安排可能不同。保存本次观察的范围和口径，拿它校准类似波次；不同条件下，按新的资料调整，先安排能应对波动的发出节奏和责任人。
七个人的第一班，先处理哪一批
许晨和行政确认，首小时可以先留下一批预计会产生九单的通知。在其它输入不变时，首波新增由四十五单改为三十六单，需求变成三十加三十六乘以六，共二百四十六分钟。七人仍能安排二百五十二分钟，只剩六分钟余量。她在十五分钟后复核真实进线与工单类型，避免把这个试算结果直接当成下一波也能发的保证。
下午，仓配负责人与下一班按原请求号完成交接。需要查订单的工作留给具备权限的人，普通操作咨询则安排在相应窗口。许晨在结束时把两次决策、已发范围和未结工时写在同一份版本记录里。下一次节前活动不必重新猜这两段发生过什么，也不必靠复制客户地址和聊天记录来证明工作量。
用 Giftpack 执行经过审批的礼品活动
企业明确目标人群、预算、发送窗口和客服责任后，可以评估 Giftpack 是否适合执行礼品活动。其帮助中心介绍了选择范围、个人限额、地区规则和备用选项。请核对所在市场的可用范围，确认企业、礼品服务和配送方怎样分工。用已确认的队列、人员权限与实际工单量更新测算表，就能决定哪一个时段需要由企业增加值守或调整通知。 Giftpack 企业礼品与个性化说明