杭州为例的困人救援系统人物角色与产品原则-Week04

困人救援图

        就在上周,杭州又发生了两起严重的电梯事故,一起直接导致1人死亡,另一起导致1人重伤瘫痪1人轻伤。沉痛的现实使得电梯安全再度成为大家关心的焦点,也让我们这些业内人员意识到我们应该加快我们的脚步,为电梯安全贡献更多的力量。这周的作业就整理下困人救援过程中的用户角色与产品原则。

        首先上图,让大家了解下救援实施过程中的业务流程:

产品业务流程

        根据上面的流程图,简单来说就是:被困人员发出求救信息给政府或物业或维保,物业与政府收到后会通知到维保客服,而后维保客服派单给具体救援人员,救援人员收到或抢到任务单后前往事发位置解救被困人。在某些紧急情况下,政府也会启动二级预案直接通知就近的救援站点的救援站长,由他们直接派人前往救援。

        在这个业务系统中,我们要搭建96333客服与维保客服的业务平台,打通信息闭环。同时要推出救援人员使用的APP,提高他们的工作效率。所以系统的关键词就是:快速、高效、闭环。值得一提的是,被困人暂时不在产品范围内,所以他们不算是业务的发起点。

人物角色

        根据上面的业务模型,我们可以看到整个闭环中涉及到的大概是两类用户:直接业务关系类与间接利益相关类。

一、直接业务关系类用户

        直接业务相关类用户是整套闭环得以运行的基础,他们缺一不可,因此他们是产品的直接需求来源者。我们要确保我们的功能对他们来说稳定、易用、高效。

96333客服

        政府的96333客服是当前产品范围内的主要发起点与信息监管方(政府的电梯应急处置中心俗称为96333,因为他们的热线为96333,隶属于质监局),他们在收到被困人的求助信息时会在第一时间通知维保客服,然后在剩下的时间内跟踪整个救援过程的情况,所以他们有4个主要的需求痛点如下:

1、准确的事件位置

        由于电梯的使用场合复杂,很多人在一个陌生场所使用电梯而被困,很大概率无法说清楚目前自己的准确位置,这就给客服的通知与调度产生了非常大的问题,也会在通知这个环节浪费大量时间。

2、告警单的快速下发

        在得知被困人员位置后,在传统的救援系统下,客服需要去查找当前位置的电梯所对应的维保单位,而后电话通知该维保单位,并不存在工单的流转。因此这是个很大的问题,在这个过程中不仅浪费时间,而且也导致了后续的一些问题,如第三点。

3、跟踪后续救援过程

        由于传统的救援系统下所有的政府客服人员工作均使用电话联系,没有工单的流转关系,那么所有的跟踪过程全部是由电话沟通人员记录的,这就带来了很大的工作量,因为这样做信息的传递只能是异步的,无法做到实时同步。

4、异常情况的人工介入

        还有就是在救援过程发生异常情况,比如维保客服长时间不响应,或者派遣的救援人员距离事件发生地距离太过遥远,这时就需要政府的客服人员调度附近的救援站点前往救援,而在传统救援系统中,这种情况他们需要通过登记在案的站点地址与事发地做比对,在这个过程中也会浪费大量时间,反而没达到快速救援的目的。

维保客服/救援站长

        维保客服是救援的中枢,由他们进行救援人员的派遣并向政府汇报实时进度。而救援站长只是另一个曾免的维保客服,对于他们来说,需求痛点其实是一样的,主要是以下3方面:

1、高效化的人员派遣

        在收到报警信息后,维保客服要做的就是联系救援人员,由于这个工作技术性不高,因此只要找出本单位距离事发地最近的人去救援即可。但在传统的救援系统中,无法做到获取人员位置,只能一个个通过电话询问位置,觉得距离差不多就派遣这个人过去,不仅浪费大量的时间,而且极其低效。

2、过程的实时反馈同步

        在救援以及维修的过程中,所有的节点在传统系统中都是由工人反馈至客服,再由客服反馈至96333,传话筒的工作同样占用了客服人员大量的时间。

3、报告汇总与管理

        在每次救援或维修完成后,工人都需要打电话将报告内容告诉客服,由客服进行录入然后才能做到管理。而在这个过程中,由于客服人员的专业程度受限经常出现录入的报告存在问题,而需要返工的情况,来回的沟通也使得工人的时间被占用。

救援人员

        救援人员是前往事件发生地救援的一线人员,如何最高效的将所有必须信息通知到他们,是整个救援信息的核心与关键。所以,他们对于产品的需求痛点主要是:

1、明显的通知

        由于工人们经常需要在电梯内、机房以及井道等区域施工,因此他们的手机经常不在手上,因此如果通知不明显,他们收到的信息延迟,很有可能耽误救援时间。因此他们需要尽可能明显的通知。

2、如何前往事发位置

        有些工人们对于区域不是那么熟悉,在收到通知要前往救援时往往只能通过手机记录下地址,然后在地图中寻找或者询问路人,在这个过程中也浪费了很多宝贵的救援时间。

二、间接利益相关类用户

        在这套系统中,有一部分间接利益的相关用户,他们虽然不参与业务流程,但是却对系统的需求有一定影响。

被困人

        被困人是这套系统存在的原因,整个系统其实是为了解救他们而存在的。他们是在报警时的描述以及等待过程中的进度询问都会对系统的业务需求产生影响。

物业值班人员

        在事件发生后,所有的业主施压的对象必定是物业人员以及物业公司,而且维保单位对于物业来说是乙方,他们也会对维保提出很多严苛的条件,从而对系统产生影响。比如:万达物业要求维保在发生困人的15分钟内到达现场等。

产品原则

对于这套救援系统,其实原则或者初心倒是很简单,那就是:

为了更快的救出被困人,减少更多的伤亡!

当然,以后的最终愿景可能是被困人与最近的救援人员的直接对话。这样可能是最高效的,哈哈~

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,491评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,856评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,745评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,196评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,073评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,112评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,531评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,215评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,485评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,578评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,356评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,215评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,583评论 3 299
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,898评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,174评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,497评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,697评论 2 335

推荐阅读更多精彩内容