如何创建客户导入流程
如何围绕销售到交付的那次交接设计客户导入流程：实施团队接手一个客户之前必须成立的条件，以及客户自己把守的那两道关卡。
运作方式
写清楚交付团队接手的是什么
把实施团队接手一个客户之前需要的条件列出来：双方签署的范围说明、一位有权批准的具名联系人、环境与集成的前置要求，以及销售过程中做出的每一项承诺。清单上凡是无法核对的，就不是条件，而是一厢情愿——要么让它变得可核对，要么把它删掉。
把你们的步骤和客户的步骤分开
把流程走两遍。第一遍标出哪些步骤由客户执行，第二遍标出哪些判断只有客户才能回答——第二份清单很短，通常只有两项，而它正是会让一切停下来的那一份。针对每一项写清楚：没有答案送来的时候会怎么办，因为那才是你真正会用到的那条路径。
把步骤写成行，再用行号连起来
“方框文字”列里的每一行都会变成一个方框。把一个步骤通向的行号填进“连线至”列，用逗号分隔。因为连接靠的是数字而不是手画的线条，重命名某个步骤或者调整表格顺序，都不会破坏流程——这正是一张可以编辑的图和一张只能重画的图之间的差别。
把客户也填进垂直泳道列
负责人填在“垂直泳道”列，阶段填在“水平泳道”列，而这一列并不在乎这位负责人是不是在你们的工资表上。把一个判断行放进客户的泳道，图就当着所有人的面说明：这个答案不归你们来给。在启动会上，这句话比写在计划里的同一句话更难被绕过去。
把每一次拒绝都画成带标注的分支
每个问题的“形状”都填“决策”，两个去向都填进“连线至”，分支用词按同样的顺序填进“连线文字”——这样就没有哪一支箭头是从菱形里没标注地跑出来的。一个更小的行号就是回路的写法：迁移核对失败退回修正步骤，不放行退回配置。
先送审批，再把链接发出去
把画好的图送去走审批，然后把链接发给客户团队和客户那位具名联系人。一份会流出公司的计划带着审批记录，回答的正是对方最先会问的那个问题——这是已经定下来的，还是谁的草稿——同时也标明了启动会依据的是哪一版。
常见问题
销售到交付的交接应当包含什么？
六件事，而且每一件都可以核对：双方签署的范围说明、影响交付的商务条款、一位有权批准的具名客户联系人、销售过程中做出的每一项承诺（包括口头的那些）、方案默认成立的技术前置条件，以及已经约定属于范围之外的事项。最后两项最常缺席，也正是它们制造了第三周的范围争议。请把这份资料包做成交接的条件，而不是交接之后才补出来的文档。
客户导入应该做多久？
不要用周来回答，而一个不带条件的数字，就是一个你注定会错过的数字。这里有两个判断属于客户——“客户是否已提供数据与访问权限？”和“上线准备是否获批？”——所以任何日期都是以这两个答案为条件的预测。请照这个样子公布：日期、它依赖的那两个答案，以及答案没来时会发生什么，因为一条“无回应”分支挪动的是日期，而不是把延误吸收掉。被明确告知哪个答案卡着日期的客户，往往会更早把它给出来。
应该让客户看到导入计划吗？
应该，而且要给他们你们自己在用的那一份，而不是它的摘要。只有当客户能读到这份计划，关于他们自己的步骤也在关键路径上的说法才会被相信；上线放行的对话也才会变成一件事先谈好的事，而不是临到头才抛出来的意外。把他们的联系人对应到他们负责的那些行上，并公布这些行所带的日期，那两个只有他们能给的答案就不会再默认迟到。
什么是价值实现时间，又该怎么衡量？
价值实现时间，指的是从合同签署到客户真正拿到他们所购买的成果之间的时长，衡量的基准是启动会上约定的标准，而不是上线。上线是你们流程里的一个里程碑；价值是他们流程里的一个事件。请为每个客户挑一件可观察的事——一个真实的交易量、一份财务真的在用的报表、一条由新系统接起来的队列——并在第 30 天去核对它。没有这次核对，流程就无法告诉你它到底有没有奏效。