一、项目背景

我们给一家婚庆统筹公司做系统。他们手上攥着酒店、摄影、司仪、花艺、婚车一票供应商，档期全靠人盯着日历，撞期往往是新人来确认时才发现，定金已经收了退不了，只能硬着头皮调，口碑受损。新人临时改需求全靠拉群喊，合同和结算散在微信聊天记录和 Excel 里，一单做完谁都说不清赚了多少。我们进场时，他们一个月十几场婚礼，统筹师有一半时间花在打电话对档期上，真正做创意和服务的时间被挤没了。老板最怕的是旺季连撞，两场婚礼同一批摄影同一天，派不出人，这种事故一次就够上本地论坛吐槽。更隐蔽的问题是成本黑箱，每场婚礼花了多少、哪类供应商最贵，老板心里没数，只能靠年底翻账本才恍然大悟，机会成本早溜走了。

二、落地场景

我们把供应商档期做成共享日历。每个供应商的可接单时段、已锁时段一目了然，预订即锁，冲突提前一周就能预警，不用等到新人确认才慌。婚礼拆成一份清单，酒店、摄影、司仪、花艺、婚车各是一道任务，系统按婚礼日期倒排，关键节点自动提醒统筹师。新人改需求走增项流程，加司仪、改花艺直接在单子里记一笔，结算时自动汇总，不再靠翻聊天记录。我们还做了多方协同看板，统筹、摄影、司仪都能看到自己这场婚礼的节点和备注，谁该到场、带什么道具清清楚楚。老板把这套接到了财务，每场婚礼的成本和毛利实时算出来，哪场亏了哪场赚了，月底一看就明白。此外，供应商绩效也接进来了，哪家的准时率、返工率低，系统自动打分，下次派单优先，供应商自己也开始卷服务，统筹师不用再靠人情去求人。

三、关键技术挑战与解决思路

档期冲突是核心。我们给每个供应商建了资源日历，预订时做区间锁，重叠就拒绝，但难点在转场。司仪和摄影同一天连场，中间要留转场时间，第一版只锁了时段没留缓冲，结果同城两场间隔两小时，人到了第一场还没散，第二场开场迟到，新人当场发火。后来我们给每个供应商加了转场缓冲参数，锁定时自动往后推，才消停。任务拆解要支持依赖，摄影必须在酒店布场后进场，花艺要等场地确认，我们用有向依赖图串起来，前置没完成后续任务就标红提醒。改单结算最乱，增项、退项、临时加人都要可追溯，我们用单据版本管理，每次改单留痕，结算按最终版本算，扯皮少了。协同看板要实时，我们用消息推送把节点变更推到各方，但推送太频繁会骚扰，后来按角色过滤，只推和自己相关的。供应商绩效打分也踩过坑，初期只看准时率，结果有家供应商为了准时拼命压缩服务时长，新人投诉，后来改成准时率加返工率双指标，才平衡。

案例片段（已脱敏）： 供应商档期锁定与任务分派配置（示意）： vendor.calendar: shared booking.lock: interval vendor.transit_buffer_min: 120 task.deps: directed_graph vendor.score: [punctuality, rework] 某统筹公司上线后档期冲突率从约 8% 降到 1% 以内，任务按时完成率从约 80% 提升到 96%，改单结算从三天压到当天出，供应商准时率提升约一成。

四、效果数据

我们主要看档期冲突率、任务按时完成率、改单结算时效和新人满意度。冲突率压到个位数以内，旺季再没出现过派不出人的事故；任务按时完成率上来之后，统筹师不用再救火，能把精力放回创意。改单结算从对账三天变成当天出单，老板说这才第一次看清每场婚礼的真实毛利。新人满意度跟着涨，主要因为信息透明，改需求不用再拉群喊，单子里写得明明白白。文中数据为项目复盘口径，已做脱敏。老板后来把满意度数据和复购挂钩，老客户转介绍明显多了，婚庆这种靠口碑的生意，省下的投诉成本比系统本身值钱。供应商绩效分接进来之后，返工率降了，统筹师派单更有底气，整体服务水准肉眼可见地上来了。

五、可复用经验总结

供应商档期这类资源，光锁时段不够，转场缓冲才是真坑，我们就是没算缓冲翻过车，同城连场迟到那次够记很久。任务拆解用依赖图比用清单靠谱，前置没完的事别让后人瞎干，标红提醒比口头交代稳。改单一定要留痕，婚庆需求变起来没谱，没版本管理结算就是一笔糊涂账，谁都说不清。供应商考核别只看单一指标，准时率压太狠会牺牲质量，双指标才稳，我们就是被返工投诉教过才改。我现在的判断是，这类统筹系统的价值不在花哨界面，而在把人和资源的约束算准，档期、转场、依赖这三层理清楚，旺季再忙也不乱，剩下的协同都是水到渠成。

我们把合同也接了电子签，供应商在线确认档期和报价，不用再寄纸质，结算周期又短了一截。老板最意外的收获是，哪类婚礼最赚钱系统算得清，他现在敢接大单了，因为知道资源和利润兜得住。