技术支持工作管理流程.docx
《技术支持工作管理流程.docx》由会员分享,可在线阅读,更多相关《技术支持工作管理流程.docx(10页珍藏版)》请在冰豆网上搜索。
技术支持工作管理流程
制度修订记录
版本号
主要作者
修改记录〔请详细填写〕
完成日期
总则
第一条为了提高技术支持工作效率、梳理售后支持流程,并促进售前交流、测试等售前过程,并杜绝现在支持过程中屡次发次的沟通障碍,特制定技术支持工作管理制度。
第二条本制度的适用对象是公司所有业务员工,主体为售前〔含售后〕人员,同时包括流程所涉及的销售、测试、研发人员。
第三条本制度经公司行政办公会讨论通过,立即执行。
工作职责界定
第四条一个工程的所有技术支持工作,都由第一和第二售前完成;如果需要其他人员,必须经过技术支持部经理、技术总监和总经理批准。
第五条原则上,责任售前应该尽量完成工程的所有支持工作。
如果第一责任售前正在处理*些工程无法立即支持,要向销售说明,并向销售询问是否可以推迟到*空余时间再支持。
如果销售认为可以推迟到第一责任售前推迟的时间处理,则此工程尽量还由第一售前处理。
如果销售反应工程紧急,不能推迟支持,第一责任售前有责任协调第二售前进展处理,并将协调结果告知销售。
如果第一售前确实不方便协调第二售前可以告知销售自己协调第二售前支持。
第二售前的处理过程类似,也是尽量支持,要询问是否可以推迟到*个时间点支持。
如果第二售前也无法支持需要向售前经理说明情况。
另外也考虑先向用户打,一方面迅速响应说明态度,另一方面也评估支持容,然后决定是否有充足时间处理,防止一个简单问题转来转去。
第六条*工程突发事件如果第一售前没时间处理,转第二售前处理了。
原则上第二售前只负责此突发事件的处理,第二售前处理完毕后通过或方式告知第一售前处理结果,时抄送售前经理,之后此工程的协调还由第一责任售前协调处理。
请第一售前转第二售前支持时尽量交代好第二售前需要支持的容、时间和围。
防止出现第一售前认为转给第二售前处理了,第二售前认为处理完又转回给第一售前了这种情况,如果出现这种情况,统一认为是第一售前没有协调妥当,责任由第一售前承当。
第七条责任售前处理工程过程中,注意及时反应,及时处理,不要申请资源后就不管了,紧急时及时追协调。
第八条所有售前在支持过程及日常的产品使用过程中发现的产品问题和易用性等修改建议均需写部bug反应表,然后给测试组成员,抄送给全体售前支持人员。
工程立项
第九条所有技术支持过程的启动,必须通过?
技术支持立项单?
事先进展工程立项、确立责任售前。
立项时须由申请人详细填写技术支持容要求,以利工程进展。
第十条完成立项后,销售保存?
技术支持立项单?
存档,以备查询。
售前填写?
工程跟踪表?
。
根据立项要求,由责任售前负责相应准备。
责任销售与责任售前须严密配合,明确需求、明确支持容。
第十一条技术支持人员一旦介入*个工程的支持工作,如果该工程没有立项,则介入工程的技术支持人员应该催促工程销售尽快走技术支持立项流程。
如果售前工程师履行了催促任务〔例如等方式提醒〕,销售依然没有走技术支持立项流程的,技术支持人员可以停顿对此工程的支持,工程出现延误等情况由销售自己承当责任。
沟通与反应
第十二条技术支持人员所做的任何技术支持工作,如销售未在场,在沟通完成后,无论沟通结果如何,建议立即发送汇报给该工程的责任销售。
标题为:
客户沟通-**工程-技服人员名字。
如果技术支持人员认为可以交代清楚,并且认为交代不会引起问题的,也可以采用向销售汇报的形式。
第十三条*工程的责任销售,一旦发现技术支持人员与客户沟通后,没有发送汇报也没有说明的,则可以发投诉给技术支持部经理,抄送技术总监;标题为:
投诉-**工程沟通问题。
销售接到责任售前的汇报,如果认为售前反应的问题需要说明的,可以要求责任售前补发汇报。
第十四条*技术支持每收到2次投诉,当月绩效工资扣发1级;每收到4次投诉,绩效工资永久降1级。
第十五条汇报正文应按如下容填写:
沟通结果“成功/问题遗留〞、工程名称、沟通人、沟通方式、沟通的具体问题〔不得写“解决了技术问题〞这样的笼统语句,而必须写成“解决vista下远程控制网络参数设置〞这样的明确语句〕、遗留的问题描述等。
第十六条技术支持在发送汇报后,应同时填写该工程第一售前署名的?
工程跟踪表?
。
注意每个售前有自己的工程跟踪表,表只记录第一售前是自己的工程。
第二售前支持工程后要将支持日期和支持容给第一售前,第一售前收到后填写到自己的工程跟踪表中。
工程跟踪表是工程奖金申领的依据,请认真填写。
问题遗留处理
第十七条如果沟通的结果是“问题遗留〞,则技服人员应该立即启动部处理流程。
第十八条如技术支持部部可处理,则处理完成后立即发送向销售汇报,如发生客户沟通,则需要再次发汇报和填写?
工程跟踪表?
。
必要时可向部门经理申请资源。
第十九条如需研发配合,则启动?
产品改良申请单?
或?
故障处理工作单?
,否则研发部门不与支持。
参见“工程立项〞章节。
研发支持
第二十条如工程中所使用的版本非标准发布版本,须提前准备。
采用非发布版的主线版本须提前测试、确认,定制版本须通过?
产品改良申请单?
〔由责任售前执行〕流程进展版本制作。
第二十一条一个工程允许屡次提交?
产品改良申请单?
,前两次可由售前与销售沟通后直接发出。
如果第三次以后再有研发需求,须由销售、责任售前与售前经理沟通,由售前经理发出?
产品改良申请单?
,售前发出无效。
以防止过多研发容对研发团队正常开发的影响。
第二十二条一个工程,如果研发执行?
产品改良申请单?
的净研发时间超过一周,则此工程的销售奖金将把研发本钱扣除后再计算。
售前交流与客户培训
第二十三条如果支持容为售前交流,须由销售与售前共同核对准备容,包括PPT以及其他文档准备,沟通重点、方式方法等。
第二十四条如支持容为客户培训,须由销售提前准备培训环境,向售前布置培训容,以便完成培训。
技术文档编写支持流程
第二十五条如果支持容为技术文档编写,须由销售与售前共同明确文档目标,核对容、重点,方式方法等。
第二十六条销售可以提出文档目录等建议和要求,由售前根据情况采用。
第二十七条如文档中需要了解用户信息、网络拓扑等用户情况,可由售前与客户沟通获取。
如售前不能获取,应反应给销售,由销售去获取。
如因未获取足够信息而产生的问题,按以上步骤查找原因和责任。
第二十八条销售有权对售前完成的文档进展审核,不合格文档可以驳回重新编写。
产品测试支持流程
第二十九条如支持容为产品测试,须由售前向销售确认测试要求,明确用户关注重点,商讨竞争分析、测试重点容和方式方法等。
第三十条为提高测试成功率,应事先获取网络拓扑或测试环境等信息,以供准备。
索取信息可由责任售前与用户沟通,如不能获取,须反应给销售,由销售去获取。
第三十一条完成准备后,由售前完成?
测试预案?
,并按此方案进展测试支持工作。
?
测试预案?
格式同?
测试方案?
,重点为环境准备和功能工程。
此文档为部文档,不对外发布。
销售可以提前审核,如?
预案?
不符合要求,可要求售前重新准备。
第三十二条如果测试使用的版本为工程版本,应由售前提前进展版本准备。
第三十三条销售如有时间进度要求,须明确告知售前,由售前落实在?
预案?
中。
第三十四条支持完成后,如销售未参与,则售前应及时或将支持过程与结果告知销售。
产品实施
注:
产品实施局部的流程暂时不作为硬性要求,以后根据实际情况调整后再发布。
简单的说现在的要做好实施前的准备和沟通,做好实施后的汇报。
第三十五条如支持容为产品实施,须由销售填写?
工程实施工作单?
销售局部,发送责任售前,抄送销售负责人、售前负责人。
第三十六条责任售前收到?
工程实施工作单?
后,填写技术局部。
第三十七条为提高测试成功率,应事先获取网络拓扑或实施环境等信息,以供准备。
索取信息可由责任售前与用户沟通,如不能获取,须反应给销售,由销售去获取。
第三十八条售前起草?
工程实施进场准备单?
,经销售确认后发送给客户,由客户签收后进展准备。
?
工程实施进场准备单?
见。
第三十九条完成准备后,由售前完成?
实施预案?
,并按此方案进展测试支持工作。
?
实施预案?
格式同?
测试方案?
,重点为环境准备和功能工程,以及实施步骤。
此文档为部文档,不对外发布。
销售可以提前审核,如?
预案?
不符合要求,可要求售前重新准备。
第四十条如果测试使用的版本为工程版本,应由售前提前进展版本准备。
第四十一条售前须根据工程情况制定?
工程实施与进度方案表?
,经销售确认后可发给用户。
表格格式见。
第四十二条销售如有特殊时间进度要求,须明确告知售前,由售前落实在?
预案?
中。
故障处理
第四十三条工程进展过程中,遇到问题时,由责任售前工程师负责解决。
遇到疑难问题时可以请其他售前同事帮助分析解决,也可以向售前经理申请资源。
注意其他同事一般只帮助分析或者只帮助解决*个具体问题,不管工程整体的情况。
请责任售前掌握工程整体情况,协调和促进工程中问题的解决。
责任售前认为协调后仍然没方法解决或者没有资源解决时,要及时反应给售前经理和销售,防止工程被延误。
第四十四条当售前遇到三次均无法解决的问题或者明显严重bug时,经售前经理同意,可提交?
故障处理工作单?
,交由研发经理进展处理。
提交同时,应尽量提供包括环境、操作过程、现象、日志等信息,以利研发排查。
注意,一般的bug走部bug反应流程处理即可,必要时才走故障处理流程。
第四十五条研发经理接到?
故障处理工作单?
后,检查售前处理是否得当。
如处理有误,可驳回并给出建议意见。
如研发经理确认须由研发解决,则分配研发负责人处理,研发负责人协调相关研发人员直接进展工程支持。
第四十六条研发负责人接手故障处理后,原则上整个故障的处理由研发负责人在研发部协调解决。
故障只有完整解决后才能转交给技术支持部门。
研发负责人认为故障问题已经解决时可以填写?
故障处理工作单?
的相关局部然后给故障提出人申请关闭,经故障提出人确认解决后关闭此故障。
第四十七条如果研发负责人认为问题无法解决或解决时间过长时,由研发负责人征求故障提出人的意见,通过定制研发流程或其他流程将问题转化。
以不影响工程进程为首要考量。
售后效劳
第四十八条工程实施验收完成后的售后技术效劳,由原责任售前负责处理。
第四十九条需要售后升级效劳时,产品升级、补丁升级等技术工作由售前负责,序列号、购置效劳等商务升级由销售负责。
其他
第五十条本制度由公司行政办公会解释执行。
第五十一条本制度附录为本制度的一局部。
第五十二条以上流程可根据工程情况适当简化。
但是如果工程支持过程中产生问题,首先查找被简化的步骤和责任。
第五十三条附图是以上规定的流程图示,如有不一致,以上述文字规定为准。
一名词解释
●技术支持工作:
为配合销售开展工作,而展开的对客户支持工作。
技术支持也称技术效劳,简称技服或TS或售前。
技术支持容包括产品交流或其他售前技术交流、产品测试、产品实施、售后效劳、技术文档编写等。
●根据公司岗位设置,本制度中针对第四条容进展技术支持的人员统一称为售前工程师,简称售前。
●客户沟通:
与客户进展的沟通联系,包括:
到客户处交流、测试、交流、发送支持、QQ等网络支持等。
●责任销售:
负责*一销售工程〔包括代理商、直接客户、直接客户的工程〕的销售人员。
●责任售前:
负责*一销售工程的技术支持人员,包括第一售前和第二售前。
==================================================
●标准发布版:
指正式发布的产品版本。
此版本将配套有全套文档。
●工程版本:
标准发布版以外所有版本。
原则上不配套相应文档。
●主线版本:
指公司产品研发的主线系列版本,不受工程版本影响、持续升级的产品版本。
标准发布版将从主线版本中挑选发布。
●定制版本:
包括功能定制版本和界面定制版本。
前者在主线版本根底上进展功能增删,后者在界面〔包括产品名称、公司名称等,以及功能菜单排列等〕上与主线版本不一样的产品版本。
二:
工程实施工作单
填表日期
责任销售
用户名称
代理商
用户地址
代理商联系人
工程名称
第一售前
第二售前
点数
合同额
实施开场日期
预计完成日期
功能要求
〔明确要部署实施的功能模块、须屏蔽的功能模块。
用户关注的重点功能等〕
定制流程单
〔如有?
新建产品型号单?
,在此填写文件名,并做为一起发送。
〕
〔如有?
研发申请单?
,在此填写文件名,并做为一起发送。
一个工程有多个研发申请单,则全部填写〕
〔如有?
研发申请单?
,在此填写文件名,并填写用户确认意见〕
版本型号
功能模块
用户环境
效劳器部署位置
效劳器IP
客户端部署方案
策略部署方案
验收方案
其他及实施预案
〔将?
实施预案?
做为,在此填写文件名〕
开场日期
〔售前人名、日期〕
完毕日期
〔售前人名、日期〕
加粗字体为必填项
三:
进场准备单
以下为?
进场准备单?
例如。
尊敬的**用户,您好:
根据**单位与**公司**工程合作……,为工程顺利进展,请按下表进展准备工作。
序号
工程
准备要求
准备结果
备注
一
效劳器准备
1
效劳器配置
2
操作系统要求
3
效劳器IP
二
网络准备
1
2
三
客户端准备
1
客户机硬件配置要求
2
操作系统要求
3
应用环境要求
四
其他准备项
1
2
其他
**公司
年/月/日