🤕️如何让企业客户“宾至如归”

tags
life
dev
type
Post
summary
status
Published
slug
concepts-to-empower-your-customer
date
Aug 3, 2023
从六月份离开微软到现在的两个月时间,我都在花时间去面试不同的岗位,不得不说,今年的环境是真的很差——很多的岗位面试流程长得离谱,也有中道崩殂没有音讯的。所幸的是,我还是积累了不少面试的经验,也有对内资、外企、互联网和软件业的部门岗位有了更深的认识。

技术支持面试的侧重点是技术本身吗

在今天一场面试(国内一线互联网的To B IM产品,技术支持)后, 我越发体会到,互联网企业做To B,面对竞品深厚的积累,真的很难很难。面试是视频会议的形式,两位面试官从声音上分辨,嗓音很年轻,后生可畏。
大概是如下的面试流程:
  1. 自我介绍——谈谈我既往的工作经验和内容
  1. 技术面试——两道算法题(如何用Map做超时缓存,一道排序题我没时间看了),前端技术选型(框架,静态页面,微前端)
  1. 业务能力——发生严重中断时该如何处理(客户原因,平台原因)
没有问对企软件应用最关键的infra问题、网络问题、系统兼容问题。也没有深入谈谈他们的业务范围,支持范围。
因为国内大厂支持业务起步晚,似乎也没有很完备的SOP,谈起业务和流程问题,面试官和我的频率有点对不上。

技术不应是成功对企服务的头号标准

国内公司做生意,尤其做大生意,诚意都拉的很足,我是真的很佩服。
从和两位面试官聊天,他们说对中等规模的企业,只要订阅了产品,他们一般都会派工程师前去驻场——我不清楚他们的定价细节,但我可以肯定的是,这绝对是亏本买卖。 IM产品一年的订阅费,对标他们的工资,是倒贴钱。
国内企业用户对工具软件的付费意愿真的很低,哪怕你集成了再多的管理工具,一个微信也能解决九成的问题。对信息安全重视的大企业,又都是内部定制的IM工具,毕竟数据捏在自己手里才安全。
这种大厂的服务风格,让我想起传说中的煤老板做生意:
  1. 你只要来问价,到了山西,先吃喝玩乐洗浴足疗打头阵
  1. 除非你主动要求,很少进行无谓的参观考察
  1. 在你启程回家之前,发一张名片:你去别处问价吧,问到最低的再来找我,我肯定比他更低
其他行业的贸易大多类似,买卖不成仁义在,积攒口碑是第一位。只要你一直做这个行当,总有一天你会来做我的生意。
可对企软件服务没有这样的市场环境啊。

付钱的和用产品的不是同一个人

工业企业的员工哪里会操心煤是哪儿来的?管你山西还是内蒙,哪怕日本拉来的煤,送进机器里,出得产品不都一个样?
可做对企软件服务,提需求用产品的业务部门往往没有经验,接需求买产品的IT更注重价格,最后还是老板批预算付钱。这个产品真正用起来好不好用,还不是业务部门一个人说了算——尽管真的只有他们在用。
乙方可难做了,要了解业务部门的技术小白想干什么,要和IT的老大觥筹交错讨生意。但这就是企业服务,你提供的技术和产品不是为了让某一方吃撑,而是为了让大家都有饭吃。
理解了这个关系,做起技术支持的工作会更得心应手:
  • 需求A,业务部门施压给IT,IT实在不想做,或者已经有现成的方案给业务部门,向你提出了产品咨询:这个需求到底能不能实现?
  • 需求B,为提升团队影响力,IT想重构既有的系统infra,但是改动infra又不会改变使用体验,向你提出了架构咨询:帮我识别一下重构方案的价值在哪里?
  • 需求C,IT老大想体验某个最新的技术,交给小弟甲做个原型。甲压根都没听说过这个新名词,想都没想开个工单给你复述了一遍需求:你做到什么程度甲会满意?
这样超出技术本身的问题和讨论,往往会占据很大一部分工作时间。
学管理信息系统的时候,谈到“信息系统在企业内实施的阻力”这一问题,教科书上就一句:来自不同部门的意见会影响实施的进度。
往大了说,信息系统的革新也可归类于组织变革这个议题下,要是真展开谈这个问题,一本书都不够呀。

和你的“客户”感同身受

作为一线员工如何能做到这一点?又如何避免在多个并行的工单中迷失呢?
  1. 设身处地为客户着想:你得知道你的“客户”是谁,站在他的立场上分析问题,揣测他想要什么样的结论。也可以旁敲侧击的问一问,毕竟有些话他想让你说出来:更有信服力,也能体现他的价值。
  1. 永远尊重流程:和大多数人认识不同,技术支持是有自己的理论支撑的——ITIL,包括服务生命周期、运维和服务管理、服务台建设在内的一整套理论知识。参照这个能标准建设出卓越的支持流程,毕竟10086/10010还有Dell都在用,微软也在用。
优秀的流程+客户关怀优先的理论,如果得到恰当的实践,不但可以为产品带来良好的口碑,也能极大减轻员工的心理压力——被客户push到哭哭啼啼的工程师,往往是支持团队的独有的风景。
或许一线员工极少有机会参与到支持流程与体系的设计中,但是相关的理论知识仍然可以应用到个人工作里:个人与团队的知识库建设、标准问题的解决流程、在严重中断时与CXO对话的call high能力等等。
优秀的技术支持工程师不应是客户的保姆,也不是产品的负责人,而应该是企业级产品的专家:通晓产品,更通晓不同组织的技术环境。授人以鱼,不如授之以渔。主动引导客户并培养他们自我解决的能力,并在适当的阶段介入干预——简单的问题自己做,稍复杂的问题文档查,个性化的需求交给我。为客户营造自我实现的良好反馈,也能为自己赢得积极的评价,陪伴产品和客户一同成长。
当优秀的流程带来卓越的支持体验,客户甚至会给出支持服务超脱于产品本身的评价。我有很多次看到客户能给出这样的评价:尽管这次预期外的中断影响很大,还好有你们,不然我真是想不出我一个人怎么扛。
 

lucky_bricks © 2018 - 2024