此剖析仅代表我个人观点(相对专业流程也不会存在过大偏差)，接受各方建议指导，但请尊重他人经验硕果，拒绝抄袭(今天看到好几位简友在写关于文章被抄袭的事情TT)。
我工作在外包行业，通俗的讲就是，你的工作我帮你做，不仅在基于你需求的前提下，做的比你专业，更重要的是为你节省了时间你可以做对你来说价值更高更核心的工作。没有任何一个团队或者一个人可以解决所有问题的，这么说没人有意见吧，所以我们的工作也是一样，需要团队合作。也许这个合作是来自一家公司，也可能是多家公司，可能合作的对象是和待解决方同公司不同团队的人，也可能就是雇主的自己人，也可能是雇主雇佣的另外一家供应商。
当然啦，不管这些人是谁，在配合上都是要明确自己的边界，并按照问题升级的流程，尊重受理时间的基础上做好配合的。在终端用户的眼里，无论一个问题的解决最终走过了多少团队，受理方都是一个整体团队，他们期待的解决时间是要涵盖全部受理团队的总计解决时间。所以一旦出了问题，是要大家坐下来一起沟通减少差异和理解偏差的。
一线（L1）:
① 对接终端用户，接收需求问题；
② 核实复现陈述的问题，确认问题反馈的准确性，以排除基础操作导致或与我方无关的误判上报；
③ 简述问题产生背景及告知已排查项，并附录必要报错截屏和待解决的问题，做好准确的问题分派；
④ 协助查询问题受理进度，做好问题推进时间的沟通，为受理方争取合理的解决时间，必要时可针对下一级进行催促提醒；
⑤ 配合下一级受理团队联络终端用户补充提交缺失的待确认项；
⑥ 内部分享新问题受理方案，并更新适当的可面向终端用户的答复给到上报人，确认结果准确度；
⑦ 内部学习整理更新升级必要排查操作及模板，以便下次同类问题升级使用；
⑧ 保持提供用户的改善建议和开发需求以便二线分析判断是否进一步和三线沟通落实，或寻找替代方案。
二线（L2—存在现场和非现场支持两种）:
① 受理一线升级上来的需求；
② 核实复现一线陈述的问题，确认问题反馈的准确性，以排除基础及非常见操作导致的误判反馈；
③ 基于不同阶段的排查检测，如有缺失补充提供可自行查阅到的证明，或联络一线补充更新仅有用户才能确认的升级必要条件；
④ 检查后台系统数据，直接解决非开发才可修复的普通型问题；
⑤ 在确认非基础性受理方案可解决的前提下，分派下一级开发团队共同讨论通过系统开发来解决的受理方案；
⑥ 定期更新问题受理进度及必要的针对下一级进行催促提醒；
⑦ 负责受理结果测试，将问题产生原因，受理方案及潜在问题更新给一线团队；
⑧ 必要的话主动提出优化的开发建议。
三线（L3）:
① 受理二线升级上来的需求；
② 基于升级内容检查后台系统配置等；
③ 提供合理解决方案或加入待开发计划；
④ 直接受理或开发升级；
⑤ 提供完整的产生原因受理过程解决方案和潜在问题告知；
⑥ 不可无限期开发，除非提供临时解决方案应急。
其他：
① 不排除因为数据自身异常导致的问题，会邀请不在升级线上的数据团队加入合作；
② 不排除因为系统端的某项特殊功能产生了极其偶发的异常现象，超出正常三线开发可解决的统一性问题，也会邀请提供系统的公司加入研究；
③ 当下无法第一时间解决的故障，需要客户业务方负责人加入讨论变更受理流程来规避可能会产生的无法解决或预增加大量成本的客观问题；
④ 进入法律援助。
我今天把自己对升级的理解做了一次梳理，原因是在项目稳定后开始专注卓越运营，自然要深入推敲当前业务有待规范和完善的点，以便各方更好的配合为用户提供优质的服务。真正整理出来后，我发现现状还是有很多问题的，而这些问题也确实不属于任何一个团队单方面就可以解决，要评估改变带来的波动及不同合作团队的业务工作模式，甚至是调整后对成本的变动，而能推进改善的最重要因素在于当下的影响度，足够大或受众群体的影响力才决定推动的结果和时间，否则还是会延续，既是无奈也是常见的客观现象。
这里学问老大了
网友评论