飞书项目 作为飞书旗下的项目管理平台，提供了高度灵活的配置，为多种类型的事件全流程管理提供可能性。在飞书项目中可将质量管理体系、企业运维业务资源、SLA 标准、数据监控、知识沉淀等能力落地为标准流程，为企业事件管理的过程、标准、监控提供平台保障，全面提升事件处理能力与处理质量，加强企业的管控能力。沉淀事件过程、处理结果等信息，也有助于企业进一步实现价值挖掘，明确客户画像和产品定位，完善产品及服务标准。
一、背景
1.1 场景介绍
基于工单的事件管理是日常运维业务最核心、最常见、最高频的场景，包含从工单的提出、变更、分类、聚合、监控、预警、升级、关闭到沉淀的全流程。不同管理模式、不同产品类型、不同的 SLA 要求对每个企业的运维管理提出不同的挑战，运维作为后方，其敏捷高效直接影响客户体验，从而影响到客户粘性，一套好的运维管理工具可以高效灵活落地事件管理 SOP ，在标准化的基础上定制不同的管理流程，需要具备敏捷灵活、有效沉淀、实时预警监控、可视的数据大盘，在此基础上协助企业完成质量体系的搭建，构建业务“轻中台”，打造坚实有力的大后方。
1.2 一般流程&关键节点
-
事件提出：主要包含事件发现与提出两个环节，事件的发现来源主要为人工提出和系统预警——其中人工提出，包含内外部使用用户在使用过程中提出问题的场景，内部用户可能为使用用户、测试人员等角色，外部可能为客户、关联方或协作方等角色；系统预警来源于自动监控的预警机制，如内存使用监控、并发请求监控等。
-
事件分析：主要包含事件响应、客服（零线）处理、事件定位等环节，分析阶段的前提是及时响应，基于此，对于简单的事件可以及时闭环，对于复杂的问题明确定位与类型，如遇事故，在处理的基础上及时上升，开放复盘流程节点，以便分析问题，做好沉淀，规避事故再次发生。在分析阶段，根据企业管理需要，可增加一线、二线运营或运营专家节点，以做好问题过滤和及时闭环、升级。
-
事件处理：主要包含各类型事件的具体处理过程，如缺陷类，新建对应的缺陷工单或聚合此类缺陷，缺陷调整后由受理人测试后通知反馈人测试来关闭缺陷，在调整过程中发现该缺陷归属于需求，可灵活调整工单类型转为优化建议类的需求工单继续跟进；如优化建议类（需求），新建对应的需求工单或聚合此类需求，转为 PM 评估，并入具体开发的迭代中，因需求开发周期相对较长，过程中关键的节点需要同步至事件反馈人及受理人，以便其获得更好的体验，增加信心；如投诉类，节点直接流转至对应的投诉处理人，及时处理，超时平台应主动识别并做预警，防止舆论扩散产生不利影响。
-
事件关闭：主要包含反馈人关闭事件、事故复盘及满意度评价三个环节，事件的关闭并不能以受理人的处理完成为终，所有类型的事件关闭需要反馈人的最终确认，留给反馈人评价的主动权，满意度评价也可作为评估受理人工作绩效的评估标准之一，最大程度保证受理人与反馈人目标一致，双方对齐语言，共同确认结果，对双方工作均有保障。
-
知识沉淀：事件暴露与解决，对于企业完善产品、服务条款、知识库及建立内部协作机制均会有很大的帮助，所有的事件应清晰可视，企业应有明确的分类及标准，使得知识沉淀可以顺畅、准确。
-
事件监控：事件的处理监控主要体现在过程中需要把控的关键节点，如首次响应、SLA 标准下的服务要求、系统预警的解决时效等等，在过程中应做到主动预警，自动升级。
-
**数据分析&**绩效评估：在事件处理过程中每日的数据大盘极为重要，每日问题处理时效、流入流出情况、使用稳定性等均需要实时的数据提供可视化看板，这些指标同时作为评估受理人员工作的绩效标准，如工时、满意度等指标，便于企业管理者从整体评估部门 ROI 。
二、场景痛点&解决方案
2.1 当前痛点
-
SLA 指标（服务级别协议）难以监控与落地，发现问题时往往处于被动局面
-
知识沉淀慢，知识库更新难，专人专项花费大量时间精力
-
各产品、各环节、各部门事件提报入口不统一，交付及商业化团队压力大，管理分散
-
事件后期管理闭环难，雷声大雨点小
2.2 解决方案
-
自动化与度量，保证 SLA 执行过程的监控全面及时
-
标准化流程驱动，符合要求自动更新知识库
-
统一的事件提报入口，释放服务阶段交付、CSM 、运维等人员压力，统一管理
-
完整的闭环管理，全过程进度可视，可预警，各类事件定制不同的流程，获得更高主动性
三、飞书项目全流程实践
飞书项目提供标准化、定制化、智能化、自动化的流程管理平台，结合企业事件管理的需要，可以覆盖使用问题、投诉、预警等多场景，每种场景可继续细分，如使用问题在闭环管理中需要继续细分到使用咨询、优化建议、bug 缺陷等类型，在飞书项目中通过灵活配置类型字段承载每种细分类型的事件，通过开关控制节点可见性及事件流转走向。
如何界定零线、一线、二线、运营专家的角色？ 很多企业产品线多，事件处理按模块精细划分，在真正接触到运营之前，需要客服人员分类、过滤问题，一般会有零线客服的存在，零线客服一般专业技能不强，主要目标为快速响应、问题分类过滤、回答简单/标准的问题。 一线、二线、运营专家等角色需要根据企业实际情况进行判断，逐层上升问题，以达到快速及时且不浪费资源解决用户问题的目标。
3.1 SLA 标准执行，高效高质快速响应
- 事件处理过程中，SLA 的适配尤为重要，根据影响程度和紧急度，自动计算优先级，减少因优先级不明确增加的沟通成本。
- SLA 时效及分级可以根据企业管理诉求灵活配置自动化规则，根据 SLA 标准也可配置相关度量图表，一目了然看到 SLA 超时的情况，并可下钻到具体事件，及时跟进。
- SLA 关键节点，均有消息提醒，临期、到期主动预警，过期自动升级。如高优预警可设置停留 1 天提醒、投诉处理可设置停留 7 天提醒、过期自动上升至高层，消息规则可自定义。
3.1.1 临期/到期预警
3.1.2 过期自动升级
3.2 知识沉淀有价值，促进产品与服务完善
知识沉淀可设置专人在问题处理后做统一判断，并执行沉淀动作，根据沉淀类型不同，可设置相关任务以保证更新动作闭环。该节点建议使用 open API 直接集成，或由专人专岗负责，以保证知识沉淀有价值、不重复。
3.3 统一入口，事件完整闭环管理
事件的闭环包含过程的完整和结果的确认，在事件处理过程中，可能出现事件的变更/聚合/升级，在飞书项目中可通过字段、节点及空间关联驱动的配置实现。
- 对于事件的类型变更，可以通过变更事件类型控制，并控制权限，防止误操作
- 对于归属于同一需求或缺陷的反馈，可以聚合到相同的需求/缺陷处，需求/缺陷节点流转后自动驱动事件节点的流转。
- 对于事件的升级，虽然在处理过程中都不愿出现但不可避免，一旦发现事件需要升级为事故，在飞书项目中可打开【升级事故】开关，在原事件处理流程基础上，并行出现事故升级及复盘节点，事故的复盘也会作为前置依赖条件影响整个事件的关闭。
- 对于事件的关闭，需要反馈人确认并做满意度评价，反馈人可基于解决方案、响应时效、服务态度等综合考虑，给出关闭的意见，并做满意度评价，在流程中满意度评价中可以单独节点体现，或在处理结果中直接体现，满意度的结果可以手工给出或通过 open API 从服务台、工单系统中获取，获取后节点自动流转。
- 在闭环过程中包含过程监控的数据看板和关键消息的预警，关键节点预警在上文 SLA 适配处已有介绍，对于过程数据的监控，飞书项目可以制定不同的表格视图搭建日度、周度、月度，个人、部门、区域、产品的度量图表，如下效果为日度和月度看板，可根据使用角色定义管理看板与日常看板。
3.4 事件类型可定制，灵活调整，便于协同沟通
使用咨询、优化建议、bug 缺陷、人员投诉、系统预警等不同流程均可通过事件类型控制，在事件定位后运营人员可以选择合适的类型，由此控制后续不同的流程走向，如发现选择失误，还可变更切换至对应的流程类型。
3.5 事件处理评价自动及时，工时消耗一目了然
- 事件处理过程的高效及时，除了过程中的管理要求与实时监控外，也需要与受理人的绩效紧密相关。在提供标准的 openAPI 接口对接外部考勤、OKR 系统外，可在飞书项目配置自动的人员评分，根据 SLA 标准自动创建扣分记录，辅助管理者对受理人绩效考核。
- 作为过程管理的主要工具，飞书项目提供工时记录的能力，在估分与排期的基础上，自动累计实际工时并计算剩余工时，方便统计人效。
四、飞书项目实践过程的思考
4.1 单一空间 or 多空间管理？
在使用飞书项目过程中，大家首先会遇到单一空间配置还是多空间配置的困扰，在事件管理场景中，判断多空间还是单一空间的主要条件为以下四个：
1.公司内有无运营人员角色（偏产品/偏客服均可）
2.产品种类是否单一
3. SLA 要求是否明确且严格
4.客户服务与产研合作密切程度
如飞书项目团队在遇到反馈事件时，开放飞书项目小精灵收集内外部的事件，设立用户运营团队响应及处理事件，经运营团队评估确认为bug缺陷或优化建议类明确定位流转至后续评估环节，在优化建议类场景中，用户运营团队专人专岗做需求的评估，确认后同步至产研空间中，符合上述条件中的【有运营角色】+【产品种类单一】+【 SLA 明确】+【用户运营与产研独立】，建议事件和产研使用两个空间管理
如A客户无专岗运营人员，由产品经理进行所有优化建议类反馈事件的筛选，产品种类相对较多，属于【无运营角色】+【产品种类多样】+【 SLA 明确】+【运营与产研在一个团队】，建议事件和产研使用一个空间管理，在产研空间直接沉淀需求及缺陷。
4.2 单一工作项 or 多工作项管理？
在使用飞书项目过程中，大家经常会遇到单一工作项还是多工作项配置流程的困扰，最典型的场景——在事件配置时不同的事件类型，如投诉、使用咨询、系统预警、优化建议、bug 缺陷配置在一个工作项还是多个工作项，判断多工作项还是单一工作项的主要条件为以下三个：
1.流程是否具有统一性和连贯性
2.表单结构差异不大，数据有统一分析诉求
3.原流程相对集中在一个或少数几个部门管理，大家对单一工作项接受程度更高
如B客户投诉的流程与事件处理流程类似，表单的字段相似，且都为运营处理或派发，符合【流程统一】+【表单结果差异不大】+【处理部门统一】，建议在一个工作项管理
