技术支持工作管理流程.doc_第1页
技术支持工作管理流程.doc_第2页
技术支持工作管理流程.doc_第3页
技术支持工作管理流程.doc_第4页
技术支持工作管理流程.doc_第5页
已阅读5页,还剩8页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

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

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论