技术支持工作管理流程

1、技术支持工作管理流程制度修订记录版本号主要作者修改记录（请详细填写）完成日期第一条第二条第三条第四条第五条总则 为了提高技术支持工作效率、 梳理售后支持 流程，并促进售前交流、测试等售前过程， 并杜绝现在支持过程中屡次发次的沟通障 碍，特制定技术支持工作管理制度。 本制度的适用对象是公司所有业务员工， 主 体为售前（含售后）人员，同时包括流程所 涉及的销售、测试、研发人员。 本制度经公司行政办公会讨论通过， 立即执 行。工作职责界定 一个项目的所有技术支持工作， 都由第一和 第二售前完成； 如果需要其他人员， 必须经 过技术支持部经理、技术总监和总经理批 准。 原则上，责任售前应该尽量完成项目

2、的所有 支持工作。如果第一责任售前正在处理某些 项目无法立即支持， 要向销售说明， 并向销 售询问是否可以推迟到某空余时间再支持。 如果销售认为可以推迟到第一责任售前推 迟的时间处理， 则此项目尽量还由第一售前 处理。如果销售反馈项目紧急， 不能推迟支 持，第一责任售前有责任协调第二售前进行 处理，并将协调结果告知销售。 如果第一售 前确实不方便协调第二售前可以告知销售 自己协调第二售前支持。 第二售前的处理过 程类似， 也是尽量支持， 要询问是否可以推 迟到某个时间点支持。 如果第二售前也无法 支持需要向售前经理说明情况。 另外也考虑 先向用户打电话，一方面迅速响应表明态 度，另一方面也评估

3、支持内容， 然后决定是 否有充足时间处理， 避免一个简单问题转来 转去。第六条 某项目突发事件如果第一售前没时间处理， 转第二售前处理了。 原则上第二售前只负责 此突发事件的处理， 第二售前处理完毕后通 过电话或邮件方式告知第一售前处理结果， 邮件时抄送售前经理， 之后此项目的协调还 由第一责任售前协调处理。 请第一售前转第 二售前支持时尽量交代好第二售前需要支 持的内容、 时间和范围。 避免出现第一售前 认为转给第二售前处理了， 第二售前认为处 理完又转回给第一售前了这种情况， 如果出 现这种情况， 统一认为是第一售前没有协调第七条第八条第九条第十条第十妥当，责任由第一售前承担。 责任售前处

4、理项目过程中，注意及时反馈， 及时处理，不要邮件申请资源后就不管了， 紧急时及时追电话协调。所有售前在支持过程及日常的产品使用过 程中发现的产品问题和易用性等修改建议 均需写内部 bug 反馈表，然后邮件给测试 组成员，抄送给全体售前支持人员。项目立项 所有技术支持过程的启动， 必须通过 技术 支持立项单 事先进行项目立项、 确立责任 售前。立项时须由申请人详细填写技术支持 内容要求，以利项目进行。 完成立项后，销售保留技术支持立项单 存档，以备查询。 售前填写项目跟踪表 。 根据立项要求，由责任售前负责相应准备。 责任销售与责任售前须紧密配合，明确需 求、明确支持内容。技术支持人员一旦介入某

5、个项目的支持 工作，如果该项目没有立项， 则介入项目的 技术支持人员应该督促项目销售尽快走技 术支持立项流程。 如果售前工程师履行了督 促任务（例如邮件等方式提醒），销售依然 没有走技术支持立项流程的， 技术支持人员 可以停止对此项目的支持， 项目出现延误等 情况由销售自己承担责任。沟通与反馈第十二条 技术支持人员所做的任何技术支持工 作，如销售未在场，在沟通完成后，无论沟 通结果如何，建议立即发送汇报邮件给该项 目的责任销售。邮件标题为：客户沟通 -XX 项目-技服人员名字。如果技术支持人员认 为电话可以交代清楚， 并且认为电话交代不 会引起问题的， 也可以采用电话向销售汇报 的形式。第十三

6、条 某项目的责任销售，一旦发现技术支持 人员与客户沟通后， 没有发送汇报邮件也没 有电话说明的， 则可以发投诉邮件给技术支 持部经理，抄送技术总监；邮件标题为：投 诉 -XX 项目沟通问题。 销售接到责任售前的 电话汇报，如果认为售前反馈的问题需要邮 件说明的，可以要求责任售前补发汇报邮 件。第十四条 某技术支持每收到 2 次投诉邮件，当月 绩效工资扣发 1 级；每收到 4 次投诉邮件， 绩效工资永久降 1 级。第十五条 汇报邮件正文应按如下内容填写：沟通 结果“成功 /问题遗留”、项目名称、沟通 人、沟通方式、沟通的具体问题（不得写“解 决了技术问题” 这样的笼统语句， 而必须写 成“解决

7、vista 下远程控制网络参数设置” 这样的明确语句）、遗留的问题描述等。第十六条 技术支持在发送汇报邮件后，应同时填 写该项目第一售前署名的项目跟踪表。 注意每个售前有自己的项目跟踪表， 表内只 记录第一售前是自己的项目。 第二售前支持 项目后要将支持日期和支持内容邮件给第 一售前，第一售前收到后填写到自己的项目 跟踪表中。项目跟踪表是项目奖金申领的依 据，请认真填写。问题遗留处理第十七条 如果沟通的结果是“问题遗留”，则技 服人员应该立即启动内部处理流程。第十八条 如技术支持部内部可处理，则处理完成 后立即发送邮件向销售汇报， 如发生客户沟 通，则需要再次发汇报邮件和填写 项目跟 踪表。必

8、要时可向部门经理申请资源。第十九条 如需研发配合，则启动产品改进申请 单或故障处理工作单，否则研发部门 不与支持。参见“项目立项”章节。研发支持第二十条 如项目中所使用的版本非标准发布版 本，须提前准备。 采用非发布版的主线版本 须提前测试、确认，定制版本须通过产品 改进申请单 （由责任售前执行）流程进行 版本制作。第二十一条 一个项目允许多次提交产品改进申请 单，前两次可由售前与销售沟通后直接发 出。如果第三次以后再有研发需求， 须由销 售、责任售前与售前经理沟通， 由售前经理 发出产品改进申请单，售前发出无效。 以防止过多研发内容对研发团队正常开发 的影响。第二十二条 一个项目内，如果研发

9、执行产品改进 申请单 的净研发时间超过一周， 则此项目 的销售奖金将把研发成本扣除后再计算。 售前交流与客户培训第二十三条 如果支持内容为售前交流，须由销售与售前共同核对准备内容，包括 PPT 以及其 他文档准备，沟通重点、方式方法等。第二十四条 如支持内容为客户培训，须由销售提前 准备培训环境， 向售前布置培训内容， 以便 完成培训。技术文档编写支持流程第二十五条 如果支持内容为技术文档编写，须由销 售与售前共同明确文档目标， 核对内容、 重 点，方式方法等。第二十六条 销售可以提出文档目录等建议和要求， 由售前根据情况采用。第二十七条 如文档中需要了解用户信息、网络拓扑 等用户情况， 可由

10、售前与客户沟通获取。 如 售前不能获取， 应反馈给销售， 由销售去获 取。如因未获取足够信息而产生的问题， 按 以上步骤查找原因和责任。第二十八条 销售有权对售前完成的文档进行审核， 不合格文档可以驳回重新编写。产品测试支持流程第二十九条 如支持内容为产品测试，须由售前向销 售确认测试要求， 明确用户关注重点， 商讨 竞争分析、测试重点内容和方式方法等。第三十条 为提高测试成功率，应事先获取网络拓 扑或测试环境等信息， 以供准备。 索取信息 可由责任售前与用户沟通， 如不能获取， 须 反馈给销售，由销售去获取。第三十一条 完成准备后，由售前完成测试预案， 并按此方案进行测试支持工作。 测试预案

11、 格式同测试方案，重点为环境准备和功 能项目。此文档为内部文档，不对外发布。 销售可以提前审核， 如预案不符合要求， 可要求售前重新准备。第三十二条 如果测试使用的版本为项目版本，应由 售前提前进行版本准备。第三十三条 销售如有时间进度要求，须明确告知售 前，由售前落实在预案中。第三十四条 支持完成后，如销售未参与，则售前应 及时电话或邮件将支持过程与结果告知销 售。产品实施 注：产品实施部分的流程暂时不作为硬性要求， 以后根据实际情况调整后再发布。 简单的说现在 的要求是做好实施前的准备和沟通， 做好实施后 的汇报。第三十五条 如支持内容为产品实施，须由销售填写 项目实施工作单 销售部分，

12、发送责任售 前，抄送销售负责人、售前负责人。第三十六条 责任售前收到项目实施工作单后， 填写技术部分。第三十七条 为提高测试成功率，应事先获取网络拓 扑或实施环境等信息， 以供准备。 索取信息 可由责任售前与用户沟通， 如不能获取， 须 反馈给销售，由销售去获取。第三十八条 售前起草项目实施进场准备单，经 销售确认后发送给客户， 由客户签收后进行 准备。项目实施进场准备单见附件。第三十九条 完成准备后，由售前完成实施预案， 并按此方案进行测试支持工作。 实施预案 格式同测试方案，重点为环境准备和功 能项目，以及实施步骤。此文档为内部文档， 不对外发布。 销售可以提前审核， 如预案 不符合要求，

13、可要求售前重新准备。第四十条 如果测试使用的版本为项目版本，应由 售前提前进行版本准备。第四十一条 售前须根据项目情况制定项目实施与 进度计划表，经销售确认后可发给用户表格格式见附件。第四十二条 销售如有特殊时间进度要求，须明确告 知售前，由售前落实在预案中。 故障处理第四十三条 项目进行过程中，遇到问题时，由责任 售前工程师负责解决。 遇到疑难问题时可以 请其他售前同事帮忙分析解决， 也可以向售 前经理申请资源。 注意其他同事一般只帮忙 分析或者只帮忙解决某个具体问题， 不管项 目整体的情况。 请责任售前掌握项目整体情 况，协调和促进项目中问题的解决。 责任售 前认为协调后仍然没办法解决或者

14、没有资 源解决时，要及时反馈给售前经理和销售， 避免项目被延误。第四十四条 当售前遇到三次均无法解决的问题或者 明显严重 bug 时，经售前经理同意，可提 交故障处理工作单，交由研发经理进行 处理。提交同时，应尽量提供包括环境、操 作过程、现象、日志等信息，以利研发排查。 注意，一般的 bug 走内部 bug 反馈流程处 理即可，必要时才走故障处理流程。第四十五条 研发经理接到故障处理工作单后，检查售前处理是否得当。 如处理有误， 可驳 回并给出建议意见。 如研发经理确认须由研 发解决， 则分配研发负责人处理， 研发负责 人协调相关研发人员直接进行项目支持。 第四十六条 研发负责人接手故障处理

15、后，原则上整 个故障的处理由研发负责人在研发内部协 调解决。故障只有完整解决后才能转交给技 术支持部门。研发负责人认为故障问题已经 解决时可以填写 故障处理工作单 的相关 部分然后邮件给故障提出人申请关闭， 经故 障提出人确认解决后关闭此故障。第四十七条 如果研发负责人认为问题无法解决或解 决时间过长时， 由研发负责人征求故障提出 人的意见，通过定制研发流程或其他流程将 问题转化。以不影响项目进程为首要考量。 售后服务第四十八条 项目实施验收完成后的售后技术服务， 由原责任售前负责处理。第四十九条 需要售后升级服务时，产品升级、补丁 升级等技术工作由售前负责， 序列号、 购买 服务等商务升级由

16、销售负责。其他第五十条 本制度由公司行政办公会解释执行。 第五十一条 本制度附录为本制度的一部分。第五十二条 以上流程可根据项目情况适当简化。但 是如果项目支持过程中产生问题， 首先查找 被简化的步骤和责任。第五十三条 附图是以上规定的流程图示，如有不一 致，以上述文字规定为准。第13页共22页附件一 名词解释技术支持工作： 为配合销售开展工作， 而 展开的对客户支持工作。 技术支持也称技 术服务，简称技服或 TS 或售前。技术支 持内容包括产品交流或其他售前技术交 流、产品测试、产品实施、售后服务、技 术文档编写等。根据公司岗位设置， 本制度中针对第四条 内容进行技术支持的人员统一称为售前

17、工程师，简称售前。客户沟通：与客户进行的沟通联系， 包括： 到客户处交流、测试、电话交流、发送邮 件支持、 QQ 等网络支持等。责任销售： 负责某一销售项目 （包括代理 商、直接客户、直接客户的项目）的销售 人员。责任售前：负责某一销售项目的技术支持 人员，包括第一售前和第二售前。标准发布版： 指正式发布的产品版本。 此版本将配套有全套文档。项目版本： 标准发布版以外所有版本。 原 则上不配套相应文档。主线版本：指公司产品研发的主线系列版 本，不受项目版本影响、 持续升级的产品 版本。标准发布版将从主线版本中挑选发 布。定制版本：包括功能定制版本和界面定制 版本。前者在主线版本基础上进行功能增 删，后者在界面（包括产品名称、公司名 称等，以及功能菜单排列等） 上与主线版 本不相同的产品版本。填表日期责任销售用户名称代理商用户地址代理商联系人项目名称第一售前第二售前点数合同额实施开始日期预计完成日期功能要求（明确要部署实施的功能模块、须屏蔽的功能模块。 用户关注的重点功能等）定制流程单（如有新建产品型号单，在此填写文件名，并做为附件 一起发送。）（如有研发申请单，在此填写文件名，并做为附件一起 发送。一个项目有多个研发申请单，则全部填写）（如有研发申请单，在此填写文件名，并填写用户确认