乙方应该提供什么样子的服务

上篇我们大胆的猜测了一下作为甲方的IT经理和C字头的boss们的想法,今天我们在来假设一下,如果乙方能提供这样的服务,甲方愿意接受么?

  1. 优化服务模式

    优化现有的服务模式,目前大多数服务商的模式还处于被动响应阶段,俗称的”消防队”模式其实也可以说是”急诊”模式,这种模式能给甲方带来的就是救命,有的时候甲方会很感谢,有的时候你救完火,甲方还扔一句”你们这产品太不稳定了”我相信会有很多工程师遇到这样的情况,心里都会有一万只Lama pacos在奔腾。乙方工程师埋怨甲方不懂产品不会使用,甲方埋怨乙方产品稳定性差、工程师能力低,更严重的还会引起投诉,导致服务丢单。

    其实我们理智的看一下,问题出在哪,是乙方工程师的问题么?产品不是我们研发的,也不是开源的,出BUG了,产品级别故障了,我们的确是束手无策。有毛病么?没毛病。是甲方的问题么?我买的产品,我想怎么用就怎么用,不满足需求是你们产品的问题,我们买你们的维保服务了,你就得保障我们的系统稳定。有毛病么?没毛病。都没毛病,那问题到底出在哪?是厂商?是产品?(真搞笑,作为乙方,你敢质疑厂商的东西有问题?你就算质疑了,又能咋样,不还得趴着么。)都不是,是我们的服务模式。
    目前我们提供的传统服务模式,基本都是4次巡检、2次或N次应急,有的更厉害的是12次巡检、N次应急无限次数电话、邮件支持。我们有没有想过这样的服务模式和服务内容对于客户来讲是否真的能起到价值,对于甲方你要这么多的巡检和应急是否有必要。很多IT经理都说过这样的话,我们这刚巡检完怎么就出问题了呢?还有的IT经理学习了一点IT服务知识,上来就搞SLA,就搞问题解决率。有意义么,说真的没有意义。作为乙方,没有哪个乙方是愿意拖着问题不处理,有资源不安排的。
    就拿Exchange来说,甲方要求乙方承诺问题解决率,乙方被逼无奈只能签署,即便工程师多次声明,我们没办法承诺问题能百分之百解决。(厂商也不承诺产品所有问题全部可以解决)但是签署了这样的服务和这样的条款就真的能把这套邮件系统维护好了么?答案肯定是不能的。

    这套邮件系统当初怎么设计的?、实施过程中出现过什么问题?、目前使用人数如何?、是否会存在爆发增长?、目前使用过程中出现过什么问题?、客户端使用习惯如何?、客户端版本情况?这些问题都了解了么?不了解是怎么拍脑门就定的4次巡检2次应急的?
    当然了,在现实中有很多因素会导致这样的情况发生,

    1,甲方预算有限
    2,赠送服务
    3,甲方不懂技术不愿意前期做过多的调研
    4,销售在技术未参加的情况跟甲方制定服务方案
    将错就错的这样走下去之后,就会演变成两个结果,其实这个结果就跟买保险是一样的。

    1,全年稳定,未出现应急情况,4次巡检报告也没有什么特别的点,这个时候甲方会考虑,我这系统看样子挺稳定的,明年的服务买不买可以考虑考虑了。
    2,全年动荡,不仅应急用完了,还把巡检的次数转换成了应急,终于磕磕绊绊全年结束了,这个时候甲方会考虑,这家服务商不行,指着他们来服务,就是”孩子死了来奶了”太晚了。我得考虑换一家。
    这两种结果都是我们不希望看到的,问题就是出在了我们的服务模式上。

  2. 主动服务模式

    优化我们的服务模式并结合上一篇我们的猜测,我们应该改变这种”消防队”的服务模式。最好的防守就是进攻,我们应该提出主动服务的模式来解决我们所遇到的一系列问题。具体如何主动,请听下回分解!

此文章为原创文章,作者:胖哥叨逼叨,如若转载,请与我联系并注明出处:https://www.pangshare.com/680.htm

发表评论

电子邮件地址不会被公开。 必填项已用*标注