技术支持工作管理流程

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

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

3、目突发事件如果第一售前没时间处理，转第二售前处理了。原则上 第二售前只负责此突发事件的处理，第二售前处理完毕后通过电话或邮件方式告知第一售前处理结果，邮件时抄送售前经理，之后此项目的协调还由第一责任售前协调处理。请第一售前转第二售前支持时尽量交代好第二售前需要支持的内容、时间和范围。避免出现第一售前认为转给第二售前处理了，第二售前认为处理完又转回给第一售前了这种情况， 如果出现这种情况，统一认为是第一售前没有协调妥当，责任由第一售 前承担。第七条 责任售前处理项目过程中，注意及时反馈，及时处理，不要邮件申请资 源后就不管了，紧急时及时追电话协调。第八条 所有售前在支持过程及日常的产品使用过程中

4、发现的产品问题和易用性 等修改建议均需写内部 bug 反馈表，然后邮件给测试组成员，抄送给全 体售前支持人员。项目立项第九条 所有技术支持过程的启动，必须通过技术支持立项单事先进行项目 立项、确立责任售前。立项时须由申请人详细填写技术支持内容要求， 以利项目进行。第十条 完成立项后，销售保留技术支持立项单存档，以备查询。售前填写 项目跟踪表。根据立项要求，由责任售前负责相应准备。责任销售 与责任售前须紧密配合，明确需求、明确支持内容。第十一条 技术支持人员一旦介入某个项目的支持工作， 如果该项目没有立项，则介入项目的技术支持人员应该督促项目销售尽快走技术支持立项流程。如果售前工程师履行了督促任

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

6、总监；邮件标题为：投诉 -XX 项目沟通问题。销售接到责任售 前的电话汇报，如果认为售前反馈的问题需要邮件说明的，可以要求责 任售前补发汇报邮件。第十四条 某技术支持每收到 2 次投诉邮件，当月绩效工资扣发 1 级；每收到 4 次投诉邮件，绩效工资永久降 1 级。第十五条 汇报邮件正文应按如下内容填写：沟通结果“成功 / 问题遗留”、项 目名称、沟通人、沟通方式、沟通的具体问题（不得写“解决了技术问 题”这样的笼统语句，而必须写成“解决vista下远程控制网络参数设置” 这样的明确语句）、遗留的问题描述等。第十六条 技术支持在发送 汇报邮件 后，应同时填写该项目第一售前署名的 项 目跟踪表 。

7、注意每个售前有自己的项目跟踪表，表内只记录第一售前 是自己的项目。第二售前支持项目后要将支持日期和支持内容邮件给第 一售前，第一售前收到后填写到自己的项目跟踪表中。项目跟踪表是项 目奖金申领的依据，请认真填写。问题遗留处理第十七条如果沟通的结果是“问题遗留”，则技服人员应该立即启动内部处理流程。第十八条如技术支持部内部可处理，则处理完成后立即发送邮件向销售汇报,如发生客户沟通，则需要再次发汇报邮件和填写项目跟踪表。必要 时可向部门经理申请资源。第十九条如需研发配合，则启动产品改进申请单或故障处理工作单，否则研发部门不与支持。参见“项目立项”章节。研发支持第二十条如项目中所使用的版本非标准发布版

8、本，须提前准备。采用非发布版的主线版本须提前测试、确认，定制版本须通过产品改进申请单 （由责任售前执行）流程进行版本制作。第二十一条 一个项目允许多次提交产品改进申请单，前两次可由售前与销 售沟通后直接发出。如果第三次以后再有研发需求，须由销售、责任售 前与售前经理沟通，由售前经理发出产品改进申请单，售前发出无 效。以防止过多研发内容对研发团队正常开发的影响。第二十二条 一个项目内，如果研发执行产品改进申请单的净研发时间超过 一周，则此项目的销售奖金将把研发成本扣除后再计算。售前交流与客户培训第二十三条 如果支持内容为售前交流，须由销售与售前共同核对准备内容，包 括 PPT 以及其他文档准备，

9、沟通重点、方式方法等。第二十四条 如支持内容为客户培训，须由销售提前准备培训环境，向售前布置 培训内容，以便完成培训。技术文档编写支持流程第二十五条 如果支持内容为技术文档编写， 须由销售与售前共同明确文档目标， 核对内容、重点，方式方法等。第二十六条 销售可以提出文档目录等建议和要求，由售前根据情况采用。第二十七条 如文档中需要了解用户信息、网络拓扑等用户情况，可由售前与客户沟通获取。如售前不能获取，应反馈给销售，由销售去获取。如因未 获取足够信息而产生的问题，按以上步骤查找原因和责任。第二十八条 销售有权对售前完成的文档进行审核，不合格文档可以驳回重新编 写。产品测试支持流程第二十九条 如

10、支持内容为产品测试，须由售前向销售确认测试要求，明确用户 关注重点，商讨竞争分析、测试重点内容和方式方法等。第三十条 为提高测试成功率，应事先获取网络拓扑或测试环境等信息，以供 准备。索取信息可由责任售前与用户沟通，如不能获取，须反馈给销售， 由销售去获取。第三十一条 完成准备后，由售前完成测试预案，并按此方案进行测试支持工作。测试预案格式同测试方案，重点为环境准备和功能项目。此文档为内部文档，不对外发布。销售可以提前审核，如预案不符 合要求，可要求售前重新准备 第三十二条 如果测试使用的版本为项目版本，应由售前提前进行版本准备。第三十三条 销售如有时间进度要求，须明确告知售前，由售前落实在预

11、案 中。第三十四条 支持完成后，如销售未参与，则售前应及时电话或邮件将支持过程 与结果告知销售。产品实施注：产品实施部分的流程暂时不作为硬性要求，以后根据实际情况调整后再发 布。简单的说现在的要求是做好实施前的准备和沟通，做好实施后的汇报。第三十五条 如支持内容为产品实施，须由销售填写项目实施工作单销售部 分，发送责任售前，抄送销售负责人、售前负责人。第三十六条 责任售前收到项目实施工作单后，填写技术部分。第三十七条 为提高测试成功率，应事先获取网络拓扑或实施环境等信息，以供 准备。索取信息可由责任售前与用户沟通，如不能获取，须反馈给销售, 由销售去获取。第三十八条 售前起草项目实施进场准备单

12、，经销售确认后发送给客户，由 客户签收后进行准备。项目实施进场准备单见附件。第三十九条 完成准备后，由售前完成实施预案，并按此方案进行测试支持 工作。实施预案格式同测试方案，重点为环境准备和功能项目, 以及实施步骤。此文档为内部文档，不对外发布。销售可以提前审核， 如预案不符合要求，可要求售前重新准备。第四十条如果测试使用的版本为项目版本，应由售前提前进行版本准备。第四十一条 售前须根据项目情况制定项目实施与进度计划表，经销售确认 后可发给用户。表格格式见附件。第四十二条 销售如有特殊时间进度要求，须明确告知售前，由售前落实在预 案中。故障处理第四十三条 项目进行过程中，遇到问题时，由责任售前

13、工程师负责解决。遇到疑难问题时可以请其他售前同事帮忙分析解决，也可以向售前经理申请资源。注意其他同事一般只帮忙分析或者只帮忙解决某个具体问题，不 管项目整体的情况。请责任售前掌握项目整体情况，协调和促进项目中 问题的解决。 责任售前认为协调后仍然没办法解决或者没有资源解决时， 要及时反馈给售前经理和销售，避免项目被延误。第四十四条 当售前遇到三次均无法解决的问题或者明显严重 bug 时，经售前经理同意，可提交故障处理工作单，交由研发经理进行处理。提交同 时，应尽量提供包括环境、操作过程、现象、日志等信息，以利研发排 查。注意，一般的 bug 走内部 bug 反馈流程处理即可，必要时才走故障 处

14、理流程。第四十五条 研发经理接到故障处理工作单后，检查售前处理是否得当。如 处理有误，可驳回并给出建议意见。如研发经理确认须由研发解决，则 分配研发负责人处理， 研发负责人协调相关研发人员直接进行项目支持。第四十六条 研发负责人接手故障处理后，原则上整个故障的处理由研发负责人在研发内部协调解决。故障只有完整解决后才能转交给技术支持部门。研发负责人认为故障问题已经解决时可以填写故障处理工作单的相 关部分然后邮件给故障提出人申请关闭，经故障提出人确认解决后关闭 此故障。第四十七条 如果研发负责人认为问题无法解决或解决时间过长时，由研发负责 人征求故障提出人的意见，通过定制研发流程或其他流程将问题转

15、化。 以不影响项目进程为首要考量。售后服务第四十八条 项目实施验收完成后的售后技术服务，由原责任售前负责处理。第四十九条 需要售后升级服务时，产品升级、补丁升级等技术工作由售前负责, 序列号、购买服务等商务升级由销售负责。其他第五十条本制度由公司行政办公会解释执行。第五十一条本制度附录为本制度的一部分。第五十二条 以上流程可根据项目情况适当简化。但是如果项目支持过程中产生 问题，首先查找被简化的步骤和责任。第五十三条 附图是以上规定的流程图示，如有不一致，以上述文字规定为准附件一 名词解释技术支持工作： 为配合销售开展工作， 而展开的对客户支持工作。 技 术支持也称技术服务，简称技服或 TS

16、或售前。技术支持内容包括产 品交流或其他售前技术交流、产品测试、产品实施、售后服务、技术 文档编写等。根据公司岗位设置，本制度中针对第四条内容进行技术支持的人员统 一称为售前工程师，简称售前。客户沟通：与客户进行的沟通联系，包括：到客户处交流、测试、电 话交流、发送邮件支持、 QQ 等网络支持等。责任销售：负责某一销售项目（包括代理商、直接客户、直接客户的 项目）的销售人员。责任售前：负责某一销售项目的技术支持人员， 包括第一售前和第二 售前。标准发布版：指正式发布的产品版本。此版本将配套有全套文档。 项目版本：标准发布版以外所有版本。原则上不配套相应文档。 主线版本： 指公司产品研发的主线系

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