FYI - WangChangye/tr GitHub Wiki

文档范围：

服务流程的生命周期
服务操作手册与技术文档
案件质量：客户反馈vs案件真实预期
绩效承诺与绩效考评
落地与实现

修订历史：

2019.06.14，初稿

第一部分服务流程的生命周期
服务的很大的努力方向是客户的愉悦消费体验和黏度，这和服务提供者的
实际工作输出质量大部分情况下是正相关的，但并不是完全一致的。
处理一个维修请求，完成一次设备或系统的优化改良，完成一次全面检测，
甚至一次客户拜访与客户关系建设，提供一次顾问咨询服务，都可以抽象化为
一个服务案件。一个服务案件可以由客户发起，也可以由服务提供者发起。服
务案件的生命周期如下：
案件进入“已确认”状态，代表我们收到了该案件，将会去查看案件详细内
容，这是一个用来提升响应速度的的机制，收到案件后不做任何操作，首先告
诉客户，您的案件我们收到了。我们主动发起的案件，可以因为区域经理综合
判断而被废弃，也可以因为客户不认可而废弃。
案件一经进入活动状态，不管通过技术工程师的努力还是通过区域经理的
努力，则必须达到预期目标。
为了追溯，统计，技术积累等目的，使用案件记录库是必要的。每一个案
件对应库里的一条记录，每一次的沟通，操作，相关参与人员及角色的变化，
当前责任人的变更和案件状态变化，都使用该记录进行追踪。

L1: 案件第一位经手人，操作手册的主要使用者
L2: 技能广而一般的技术工程师
L3: 专精某一种类问题解决的技术工程师
AM: 区域经理

L2和L3工程师可以从现有工程师中培养，兼任，并逐渐专业化。

融合了案件记录库的案件处理流程如下：

区域经理和L3介入案件后，案件当前责任人修改为L3,L3可以远程指导处理<br/>

或者现场处理，同时区域经理视情况做好客户沟通与资源协调。

案件记录创建时应至少包含一下部分：

简要描述
受影响的设备/系统/方案所属分类
达成标准
严重程度级别与紧急程度级别
期望达成日期

案件记录操作中至少应记录以下信息：

操作手册链接，如果有
如果有责任人变更，注明原因

第二部分. 服务操作手册与技术文档

当我们需要为客户提供系统优化，系统维修，方案建议，使用方法指导和
疑难问题定位处理时，可以根据关键词在手册中找到具体可行的步骤，使对服
务场景有最基本了解的人也可以根据步骤提供专业的服务。
一个操作手册条目应至少包含一下部分：

现状描述
预期描述
操作步骤
相关L2 L3 接口人

条目创建由工程师评审后存档。

根据我们所提供的服务的分类，服务操作手册也对应不同的分类，例如：
方案推荐建议类：范例，监控系统按照最经济，最可靠，最易用，最灵活等分类
分别提供四类推荐软硬件配置，涵盖强弱电，存储，摄像头
系统软件等可落地清单及操作步骤，组件升级更迭指南，机房
机柜布局建议等
使用配置指南类：范例，视频会议系统，按品牌及型号分类提供简单可操作的
组织会议/参与会议/远程白板使用等各项的具体步骤，常见不当
使用方式及其输出信息，常见不当配置及其症状，常见不当使用
方式/配置的纠正步骤以及既成影响的恢复方法；
范例，修改配置进行定制化的安全简单可操作的步骤
系统设备例行检测类：范例，所有待检系统设备待检项目清单，检测步骤，和
系统/设备预期输出结果
设备/系统故障恢复类：范例，设备出现症状A，请使用步骤1，2，3，4进行排查
如果符合步骤一的全部特征，则问题根源为cause_01，请直接跳到
步骤5进行操作解决该问题，然后跳到步骤10排除其环境诱因。
如果执行完所有操作该问题仍未解决，请将该案例交接给用户
[email protected]_union.com 作深入定位与解决

技术文档，由工程师提交用以分享心得经验，会议中评审。包括但不限于
以下内容：

客户关系维护与开发技巧
不同品牌型号设备互通性优劣与稳定性
常见系统问题分析案例
新设备新系统新场景
技术文档可以用于新员工培训，老员工学习，检索，以及为客户提供咨询建议
是作为数据参考。对文档的贡献，可以作为绩效考评的一个维度。

第三部分案件质量：客户反馈vs案件真实预期
通常情况下，客户对一个案例完成满意度的反馈和一个案例应有的完成满意度
是一致的，如果出现由于某些特殊原因例如战略目标要求而出现的不一致，区域
经理应该创建新的例外ticket说明该原因,并关联到该案例记录。例外ticket仅内
部可见。

第四部分绩效承诺与绩效考评
员工在公司/部门年度目标的方向与框架内作个人季度绩效承诺，绩效承诺至
少包含如下部分：
- 个人工作输出：案件处理数量/质量，市场业绩
- 个人技能提升：技能/理论/客户关系技巧
- 创新贡献：服务操作手册&技术文档提交数量/质量，参与评审场次,
实用新型工作模式/方法/话术贡献，等

绩效承诺每季度初提交直接领导审批，审批通过后存档执行。<br/>
最终考评结果为绩效承诺达成度，季度末由直接领导参考案例记录库，服务操<br/>
作手册与技术文档库的汇总统计数据以及对个人能力提升的综合考量做出<br/>

第五部分落地与实现
短期：
技术文档依托 github wiki, 或者github pages
服务操作手册，依托github pages实现，例如： https://wangchangye.github.io/tr/
案例记录追踪，依托github issues系统实现，案例评分使用label实现

  优势：快速上线，比较稳定，功能丰富，统计搜寻跟踪追溯功能齐全。<br/>
  局限性：英文界面，可定制化不高，容灾性能无法完全掌控。<br/>

长期：开发/外购定制化系统，以主备系统&周期性备份的形式部署到服务器。

  统一接口，使用用户角色区分不同的权限（操作/查询/界面选项），使用公众号
  转接到页面。

FYI - WangChangye/tr GitHub Wiki

⚠️ **GitHub.com Fallback** ⚠️

⚠️ GitHub.com Fallback ⚠️