您在此处：
切换计划
在提交上线窗口之前，请为每个切换元素决定并记录处理。无论您使用哪种推出方法，它们都会适用。
| 切换元素 | 计划注意事项 |
|---|---|
| 上线窗口 | 确定维护时段的持续时间、谁在线上、上线的签单授权、问题的升级路径，以及在上线时段之前、期间和之后立即与受影响用户的沟通。 |
| 回滚条件 | 定义启动回滚的条件、谁有权调用它、预期的回滚持续时间，以及在维护中是否可行。 |
| 实时报价 | 决定销售团队在您接管时仍在工作的报价会发生什么。有效报价包含有效期、定价快照和配置的行。在周期中迁移它们通常会产生难以调和的差异。 一种切实可行的方法是仅迁移长期运行的战略交易，通常是那些具有自定义商业条款或延长有效期的交易。对于所有其他内容，请销售代表在上线后在收入管理中重新创建报价。这种方法实施更简单，验证更容易，并且避免了配置不匹配的风险。 |
| 数据验证门 | 在上线前，创建一组小的报价，以涵盖一系列有代表性的场景，然后在迁移后根据这些报价进行验证，以确认新更改已正确应用。
列出在宣布上线成功之前必须通过的对帐检查。典型检查包括记录计数、针对策划报价包的定价验证、集成烟雾测试和您的程序需要的任何其他大门。 |
| 订单处理冻结 | 决定是否在上线前暂停或限制新的或正在进行的订单，以确保工作不会停滞。如果您实施冻结，请将其时间告知销售团队，并通知客户任何延迟，而不必披露迁移本身。 对于实时订单，定义数据冻结的标准，例如某个日期，在这些标准上与利益相关者保持一致，并确定上线后处理实时订单的计划。 |
| 过度护理期 | 定义上线后立即加强支持的持续时间，哪些角色保持可用，以及不能等待正常支持的问题的升级路径。 |
| 通信计划 | 分配谁发送每条消息以及向哪些受众发送。销售代表、财务、运营和 IT 部门通常需要在切换前、切换中和切换后的不同时间点提供不同级别的详细信息。 |
另请参阅：
本文章是否解决您的问题？
请与我们共享您的想法，以便我们进行改进！
