技术支持工作管理流程.docx

技术支持工作管理流程.docx

《技术支持工作管理流程.docx》由会员分享，可在线阅读，更多相关《技术支持工作管理流程.docx（10页珍藏版）》请在冰豆网上搜索。

技术支持工作管理流程

制度修订记录

版本号

主要作者

修改记录（请详细填写）

完成日期

总则

第一条为了提高技术支持工作效率、梳理售后支持流程，并促进售前交流、测试等售前过程，并杜绝现在支持过程中屡次发次的沟通障碍，特制定技术支持工作管理制度。

第二条本制度的适用对象是公司所有业务员工，主体为售前（含售后）人员，同时包括流程所涉及的销售、测试、研发人员。

第三条本制度经公司行政办公会讨论通过，立即执行。

工作职责界定

第四条一个项目的所有技术支持工作，都由第一和第二售前完成；如果需要其他人员，必须经过技术支持部经理、技术总监和总经理批准。

第五条原则上，责任售前应该尽量完成项目的所有支持工作。

如果第一责任售前正在处理某些项目无法立即支持，要向销售说明，并向销售询问是否可以推迟到某空余时间再支持。

如果销售认为可以推迟到第一责任售前推迟的时间处理，则此项目尽量还由第一售前处理。

如果销售反馈项目紧急，不能推迟支持，第一责任售前有责任协调第二售前进行处理，并将协调结果告知销售。

如果第一售前确实不方便协调第二售前可以告知销售自己协调第二售前支持。

第二售前的处理过程类似，也是尽量支持，要询问是否可以推迟到某个时间点支持。

如果第二售前也无法支持需要向售前经理说明情况。

另外也考虑先向用户打电话，一方面迅速响应表明态度，另一方面也评估支持内容，然后决定是否有充足时间处理，避免一个简单问题转来转去。

第六条某项目突发事件如果第一售前没时间处理，转第二售前处理了。

原则上第二售前只负责此突发事件的处理，第二售前处理完毕后通过电话或邮件方式告知第一售前处理结果，邮件时抄送售前经理，之后此项目的协调还由第一责任售前协调处理。

请第一售前转第二售前支持时尽量交代好第二售前需要支持的内容、时间和范围。

避免出现第一售前认为转给第二售前处理了，第二售前认为处理完又转回给第一售前了这种情况，如果出现这种情况，统一认为是第一售前没有协调妥当，责任由第一售前承担。

第七条责任售前处理项目过程中，注意及时反馈，及时处理，不要邮件申请资源后就不管了，紧急时及时追电话协调。

第八条所有售前在支持过程及日常的产品使用过程中发现的产品问题和易用性等修改建议均需写内部bug反馈表，然后邮件给测试组成员，抄送给全体售前支持人员。

项目立项

第九条所有技术支持过程的启动，必须通过《技术支持立项单》事先进行项目立项、确立责任售前。

立项时须由申请人详细填写技术支持内容要求，以利项目进行。

第一十条完成立项后，销售保留《技术支持立项单》存档，以备查询。

售前填写《项目跟踪表》。

根据立项要求，由责任售前负责相应准备。

责任销售与责任售前须紧密配合，明确需求、明确支持内容。

第一十一条技术支持人员一旦介入某个项目的支持工作，如果该项目没有立项，则介入项目的技术支持人员应该督促项目销售尽快走技术支持立项流程。

如果售前工程师履行了督促任务（例如邮件等方式提醒），销售依然没有走技术支持立项流程的，技术支持人员可以停止对此项目的支持，项目出现延误等情况由销售自己承担责任。

沟通与反馈

第一十二条技术支持人员所做的任何技术支持工作，如销售未在场，在沟通完成后，无论沟通结果如何，建议立即发送汇报邮件给该项目的责任销售。

邮件标题为：

客户沟通-XX项目-技服人员名字。

如果技术支持人员认为电话可以交代清楚，并且认为电话交代不会引起问题的，也可以采用电话向销售汇报的形式。

第一十三条某项目的责任销售，一旦发现技术支持人员与客户沟通后，没有发送汇报邮件也没有电话说明的，则可以发投诉邮件给技术支持部经理，抄送技术总监；邮件标题为：

投诉-XX项目沟通问题。

销售接到责任售前的电话汇报，如果认为售前反馈的问题需要邮件说明的，可以要求责任售前补发汇报邮件。

第一十四条某技术支持每收到2次投诉邮件，当月绩效工资扣发1级；每收到4次投诉邮件，绩效工资永久降1级。

第一十五条汇报邮件正文应按如下内容填写：

沟通结果“成功/问题遗留”、项目名称、沟通人、沟通方式、沟通的具体问题（不得写“解决了技术问题”这样的笼统语句，而必须写成“解决vista下远程控制网络参数设置”这样的明确语句）、遗留的问题描述等。

第一十六条技术支持在发送汇报邮件后，应同时填写该项目第一售前署名的《项目跟踪表》。

注意每个售前有自己的项目跟踪表，表内只记录第一售前是自己的项目。

第二售前支持项目后要将支持日期和支持内容邮件给第一售前，第一售前收到后填写到自己的项目跟踪表中。

项目跟踪表是项目奖金申领的依据，请认真填写。

问题遗留处理

第一十七条如果沟通的结果是“问题遗留”，则技服人员应该立即启动内部处理流程。

第一十八条如技术支持部内部可处理，则处理完成后立即发送邮件向销售汇报，如发生客户沟通，则需要再次发汇报邮件和填写《项目跟踪表》。

必要时可向部门经理申请资源。

第一十九条如需研发配合，则启动《产品改进申请单》或《故障处理工作单》，否则研发部门不与支持。

参见“项目立项”章节。

研发支持

第二十条如项目中所使用的版本非标准发布版本，须提前准备。

采用非发布版的主线版本须提前测试、确认，定制版本须通过《产品改进申请单》（由责任售前执行）流程进行版本制作。

第二十一条一个项目允许多次提交《产品改进申请单》，前两次可由售前与销售沟通后直接发出。

如果第三次以后再有研发需求，须由销售、责任售前与售前经理沟通，由售前经理发出《产品改进申请单》，售前发出无效。

以防止过多研发内容对研发团队正常开发的影响。

第二十二条一个项目内，如果研发执行《产品改进申请单》的净研发时间超过一周，则此项目的销售奖金将把研发成本扣除后再计算。

售前交流与客户培训

第二十三条如果支持内容为售前交流，须由销售与售前共同核对准备内容，包括PPT以及其他文档准备，沟通重点、方式方法等。

第二十四条如支持内容为客户培训，须由销售提前准备培训环境，向售前布置培训内容，以便完成培训。

技术文档编写支持流程

第二十五条如果支持内容为技术文档编写，须由销售与售前共同明确文档目标，核对内容、重点，方式方法等。

第二十六条销售可以提出文档目录等建议和要求，由售前根据情况采用。

第二十七条如文档中需要了解用户信息、网络拓扑等用户情况，可由售前与客户沟通获取。

如售前不能获取，应反馈给销售，由销售去获取。

如因未获取足够信息而产生的问题，按以上步骤查找原因和责任。

第二十八条销售有权对售前完成的文档进行审核，不合格文档可以驳回重新编写。

产品测试支持流程

第二十九条如支持内容为产品测试，须由售前向销售确认测试要求，明确用户关注重点，商讨竞争分析、测试重点内容和方式方法等。

第三十条为提高测试成功率，应事先获取网络拓扑或测试环境等信息，以供准备。

索取信息可由责任售前与用户沟通，如不能获取，须反馈给销售，由销售去获取。

第三十一条完成准备后，由售前完成《测试预案》，并按此方案进行测试支持工作。

《测试预案》格式同《测试方案》，重点为环境准备和功能项目。

此文档为内部文档，不对外发布。

销售可以提前审核，如《预案》不符合要求，可要求售前重新准备。

第三十二条如果测试使用的版本为项目版本，应由售前提前进行版本准备。

第三十三条销售如有时间进度要求，须明确告知售前，由售前落实在《预案》中。

第三十四条支持完成后，如销售未参与，则售前应及时电话或邮件将支持过程与结果告知销售。

产品实施

注：

产品实施部分的流程暂时不作为硬性要求，以后根据实际情况调整后再发布。

简单的说现在的要求是做好实施前的准备和沟通，做好实施后的汇报。

第三十五条如支持内容为产品实施，须由销售填写《项目实施工作单》销售部分，发送责任售前，抄送销售负责人、售前负责人。

第三十六条责任售前收到《项目实施工作单》后，填写技术部分。

第三十七条为提高测试成功率，应事先获取网络拓扑或实施环境等信息，以供准备。

索取信息可由责任售前与用户沟通，如不能获取，须反馈给销售，由销售去获取。

第三十八条售前起草《项目实施进场准备单》，经销售确认后发送给客户，由客户签收后进行准备。

《项目实施进场准备单》见附件。

第三十九条完成准备后，由售前完成《实施预案》，并按此方案进行测试支持工作。

《实施预案》格式同《测试方案》，重点为环境准备和功能项目，以及实施步骤。

此文档为内部文档，不对外发布。

销售可以提前审核，如《预案》不符合要求，可要求售前重新准备。

第四十条如果测试使用的版本为项目版本，应由售前提前进行版本准备。

第四十一条售前须根据项目情况制定《项目实施与进度计划表》，经销售确认后可发给用户。

表格格式见附件。

第四十二条销售如有特殊时间进度要求，须明确告知售前，由售前落实在《预案》中。

故障处理

第四十三条项目进行过程中，遇到问题时，由责任售前工程师负责解决。

遇到疑难问题时可以请其他售前同事帮忙分析解决，也可以向售前经理申请资源。

注意其他同事一般只帮忙分析或者只帮忙解决某个具体问题，不管项目整体的情况。

请责任售前掌握项目整体情况，协调和促进项目中问题的解决。

责任售前认为协调后仍然没办法解决或者没有资源解决时，要及时反馈给售前经理和销售，避免项目被延误。

第四十四条当售前遇到三次均无法解决的问题或者明显严重bug时，经售前经理同意，可提交《故障处理工作单》，交由研发经理进行处理。

提交同时，应尽量提供包括环境、操作过程、现象、日志等信息，以利研发排查。

注意，一般的bug走内部bug反馈流程处理即可，必要时才走故障处理流程。

第四十五条研发经理接到《故障处理工作单》后，检查售前处理是否得当。

如处理有误，可驳回并给出建议意见。

如研发经理确认须由研发解决，则分配研发负责人处理，研发负责人协调相关研发人员直接进行项目支持。

第四十六条研发负责人接手故障处理后，原则上整个故障的处理由研发负责人在研发内部协调解决。

故障只有完整解决后才能转交给技术支持部门。

研发负责人认为故障问题已经解决时可以填写《故障处理工作单》的相关部分然后邮件给故障提出人申请关闭，经故障提出人确认解决后关闭此故障。

第四十七条如果研发负责人认为问题无法解决或解决时间过长时，由研发负责人征求故障提出人的意见，通过定制研发流程或其他流程将问题转化。

以不影响项目进程为首要考量。

售后服务

第四十八条项目实施验收完成后的售后技术服务，由原责任售前负责处理。

第四十九条需要售后升级服务时，产品升级、补丁升级等技术工作由售前负责，序列号、购买服务等商务升级由销售负责。

其他

第五十条本制度由公司行政办公会解释执行。

第五十一条本制度附录为本制度的一部分。

第五十二条以上流程可根据项目情况适当简化。

但是如果项目支持过程中产生问题，首先查找被简化的步骤和责任。

第五十三条附图是以上规定的流程图示，如有不一致，以上述文字规定为准。

附件一名词解释

●技术支持工作：

为配合销售开展工作，而展开的对客户支持工作。

技术支持也称技术服务，简称技服或TS或售前。

技术支持内容包括产品交流或其他售前技术交流、产品测试、产品实施、售后服务、技术文档编写等。

●根据公司岗位设置，本制度中针对第四条内容进行技术支持的人员统一称为售前工程师，简称售前。

●客户沟通：

与客户进行的沟通联系，包括：

到客户处交流、测试、电话交流、发送邮件支持、QQ等网络支持等。

●责任销售：

负责某一销售项目（包括代理商、直接客户、直接客户的项目）的销售人员。

●责任售前：

负责某一销售项目的技术支持人员，包括第一售前和第二售前。

==================================================

●标准发布版：

指正式发布的产品版本。

此版本将配套有全套文档。

●项目版本：

标准发布版以外所有版本。

原则上不配套相应文档。

●主线版本：

指公司产品研发的主线系列版本，不受项目版本影响、持续升级的产品版本。

标准发布版将从主线版本中挑选发布。

●定制版本：

包括功能定制版本和界面定制版本。

前者在主线版本基础上进行功能增删，后者在界面（包括产品名称、公司名称等，以及功能菜单排列等）上与主线版本不相同的产品版本。

附件二：

项目实施工作单

填表日期

责任销售

用户名称

代理商

用户地址

代理商联系人

项目名称

第一售前

第二售前

点数

合同额

实施开始日期

预计完成日期

功能要求

（明确要部署实施的功能模块、须屏蔽的功能模块。

用户关注的重点功能等）

定制流程单

（如有《新建产品型号单》，在此填写文件名，并做为附件一起发送。

）

（如有《研发申请单》，在此填写文件名，并做为附件一起发送。

一个项目有多个研发申请单，则全部填写）

（如有《研发申请单》，在此填写文件名，并填写用户确认意见）

版本型号

功能模块

用户环境

服务器部署位置

服务器IP

客户端部署方案

策略部署方案

验收方案

其他及实施预案

（将《实施预案》做为附件，在此填写文件名）

开始日期

（售前人名、日期）

结束日期

（售前人名、日期）

加粗字体为必填项

附件三：

进场准备单

以下为《进场准备单》示例。

尊敬的XX用户，您好：

根据XX单位与XX公司XX项目合作……，为项目顺利进行，请按下表进行准备工作。

序号

项目

准备要求

准备结果

备注

一

服务器准备

1

服务器配置

2

操作系统要求

3

服务器IP

二

网络准备

1

2

三

客户端准备

1

客户机硬件配置要求

2

操作系统要求

3

应用环境要求

四

其他准备项

1

2

其他

XX公司

年/月/日