我经历过的失败的产品和项目(五):没有前途的视频呼叫中心

  • 背景

也是在3G大环境下,公司在视频领域尝试的一种业务形态。

大概就在10年的时候,三大运营商也都在做视频呼叫中心的业务评估,不过基本属于规范制定中,其中中联通走的比较快,而且他们的视频呼叫中心最终也上线了(但业务一直起不来),也有一些传统的语音呼叫中心厂家在尝试做这方面的工作。我们在经过一段时间的评估和考察之后,在2010年初的时候,决定和一个Avaya和思科呼叫中心的代理商合作,启动视频呼叫中心的项目,由我来领导这个项目组。

  • 描述

产品比较明确,就是在Avaya和Cisco的语音呼叫中心的基础上,加上视频的能力。

和代理商的分工比较明确,呼叫中心的业务层面有他们负责,包括CRM、界面等等;我们负责视频呼叫中心所需的的音视频和信令能力以及IVVR菜单流程和定制等。

我们提供的产品涵盖手机端(Android/iOS),PC端,业务服务器和媒体服务器

我们这边的主要工作包括:和Avaya和Cisco的对接(信令和媒体);调用接口提供;视频呼叫中心所需的媒体面和信令功能提供,包括点对点视频、三方视频、视频叠加、图片文本叠加、呼转等;IVVR菜单订货制工具等。

项目团队包括:

    • DSP开发1个,负责媒体处理;
    • 媒体控制1个(我兼),负责媒体的控制、整体设计和联调;
    • 业务控制1个,负责业务流程控制;
    • Windows开发2个(其他公司外援),负责提供SDK接口、DEMO程序和PC客户端提供;
    • Android/iOS开发各1个(其他公司外援):负责手机终端
    • 测试2人:负责测试工具、测试用例和测试

由于我领导的职能部门负责不了这个项目的全部工作,所以这个项目的成员除了我,其余都是其他部门和公司临时抽调过来的

  • 过程

整个过程分成两个阶段:演示阶段和后续完善阶段。

演示阶段工作主要在我们这一侧:即通过我们的DEMO程序,和Cisco对接完成,并演示IVVR的所有功能。大概流程如下:手机APP拨入一个号码,进入IVVR流程,用户可观看到一段视频广告和选项菜单,用户选择人工服务,则直接和Cisco的坐席进行视频通话;坐席使用我们提供的DEMO程序,可选择呼转、三方视频、推送视频广告、咨询等操作。这个阶段在两个月内完成,并成功进行了几个外场的演示。

这个阶段进度和压力比较大,加班和熬夜属于常态。后来的几个外场演示,基本是我或者业务控制开发工程师去现场的。

第二阶段主要工作包括,稳定性、性能测试、IVVR菜单工具开发、代理商开发坐席侧软件并和我们的接口对接(替换我们的DEMO程序),和AVAYA呼叫中心对接。这一阶段持续了6个月的时间。

  • 结果

代理商一单未落,第二阶段的客户演示也少了。

我们公司的市场也找来几个典型的客户进行演示(包括平安公司、某地的呼叫中心基地等等),最后也是一单未落。

在经过了6个月的第二阶段工作之后,由于没有市场的推进以及其他项目的冲击,这个项目也就无声无息的终止掉了。

后来代理商的呼叫中心坐席侧也开发完成,界面还是很漂亮的。代理商负责人也找过我好几次,说有几个项目需要演示,希望我们能够继续支持(主要是实际环境下的音视频质量优化,以及AVAYA新接口的对接支持)。由于那时候该项目团队也已经解散,公司也对视频呼叫中心的前景比较不看好,我们也就没在继续支持。

前段时间和代理商负责人聊天,谈到这个项目,最后总结一点:我们走的太前了,IVVR市场还需要培育,而且爆发点可能永远也不会来。

  • 总结

对于公司来讲,这个项目是在3G时代,公司四处出击的又一个失败业务。调研不够谨慎,市场前瞻性不够是主要原因。虽然后来及时的终止了这个项目,损失一时无法看出来,但积累起来,也就导致后来公司的困难阶段。

对于我来讲,第一次带领不同领域技术的项目和团队,第一次带领包括外部公司人员的团队,第一次带领技术和资历都比我高的工程师,对于项目管理和团队管理的来说,又积累的不同的经验。

时间: 2024-10-06 18:32:11

我经历过的失败的产品和项目(五):没有前途的视频呼叫中心的相关文章

我经历过的失败产品和项目(七):定位模糊的面向移动互联网的视频通话应用

背景 2011年下半年的时候,随着移动互联网的普及,移动端的应用越来越多,移动互联网模式初现,强烈的冲击着我们这家做通信公司.作为专业做视频的公司,公司老板决定在移动互联网上面试下水,对于产品只说了这么一句话:大家看下tango,用户只需要在我们的APP上输入手机号,收到短信,就能注册,登录就能免费用我们的视频通话功能,我们先做着,等用户量起来了,我们再做其他想法. 就这样,我们启动了这个项目. 描述 由于我之前刚刚兼任了移动终端组的负责人(从媒体服务器负责人兼任移动终端组负责人,跨度是很大的)

《乌合之众》深度分析日本这个失败的产品

在日本战败70周年之际,适逢日本在东京的武道馆举行每年一度的对战死者的追悼活动,再次将对日本的谴责推向的风口浪尖之上.国内的各大媒体也不失时机地开始大肆宣扬,但媒体更多的是点到即止,更精彩的是人们的各种评论之精彩,不可谓不令人叹服. 就拿腾讯上的<日天皇首提"深刻反省" 疑对安倍不满>这篇文章为例子,文章很简短,主要就是说日本天皇和安培在致辞上的区别,一个是对战后的反省,而另外一个则是毫无反省诚意,引发了网友的评论如下: 究竟应该谴责什么 从评论中我们可以看到网友的评论多有

反省:一个失败的产品

今天的心情本应该是愉悦一点的,因为折腾老子(请允许我爆一句粗口)一个多月的某证券PC客户端内嵌版商城终于通过层层部门测试,要上线了.对客户而言,基本完成了他们所有预期的功能和效果,但就我个人而言,我觉得这是一个混乱.失败的产品. 在这里想做个总结.先分析下客观原因吧. 第一.产品缺乏设计和流程 从项目开始就只有几张截图,没有人提到这个如何产品设计,交互,框架,整个的建设流程,多次问及,除了告之参照截图,就是不断的催促项目时间.迫于时间压力,只能凭自己以往项目经验和对产品短时的理解仓促动手,以致后

人人都是产品经理-项目的坎坷一生

项目的坎坷一生 从产品到项目 一切从kickoff开始即立项 关键的青春期,又见需求 成长,一步一个脚印,配合完成项目的发布 山寨级项目管理,从流程,文档,敏捷三方面讲项目管理 物竞天择适者生存,讲了一些作者亲身经历的例子

论产品和项目

为什么要写这个话题呢,其实也不知道该怎么写,但是今天我却想跟大家探讨一下这个话题,其实话题是这样引起的,今天老板问我最近做了那些东西,然后我给他仔细的叙述了一遍,在我叙述的过程中老板这样问了我一句,在这个医院的项目中已经改了,为什么要在另一个项目中改,还有,为什么这个医院可以直接打印,单位这个却不能直接打印要重新设计.然后他我们做的是产品,不是就一个工程吗?我瞬间无语.话题就是这样. 那么我先说说我对产品和项目的理解吧,首先是产品,我的理解是可以在同类行业中通用的一个应用软件,稍作改动或者说是后

程序猿职业规划随感:做产品还是项目?

作者:易仔阿克(李福东)    时间:2014年8月1日 对于程序猿的职业,由于新技术总是不断出现,软件工具版本也在不断更新,注定程序猿的生活要拥抱变化,另一方面,中国的程序猿也注定具备中国特色:较短的职业生命周期和缺少计划性的没有尽头的加班加点.虽然有人看见程序猿偶尔挣的多些羡慕,但我感觉我国的程序猿大多是靠辛苦靠加班挣来的,性价比一般般. 不过,对于大多数人来说,做不做程序猿也不是自己说了算,尤其是那些做了多年程序的人选择余地就更小了.那么,程序猿怎样选择工作发展方向呢?笔者曾经在私企.外企

Xcode下载失败 使用已购项目页面再试一次

Mac App Store下载失败 使用已购项目页面再试一次解决办法 我们很多使用Mac的用户朋友可能都会遇到过这样的情况,那就是在Mac系统App Store 中下载应用软件时,会提示我们"使用已购页面再试一次"的情况.由于苹果的 App Store 应用商店在国外,所以 DNS 如果不好会直接影响应用的下载以及更新.下面PC6小编给大家简单介绍下如何解决这个问题. 1.在屏幕右上角找到WiFi图标,点击进入"打开网络偏好设置". 2.在网络设置窗口中,选中当前已

用户 &#39;IIS APPPOOL\**&#39; 登录失败的解决方案(项目部署到本地IIS上打开网页出现报错)

为开发方便-将项目部署到本地IIS上打开网页出现报错 1.打开IIS管理 2.点击应用池 3.找到你部署的网站名,右键“高级设置”——>“进程模型”——>“标识”修改为localsystem,点击“确定”. 步骤见下截图: 用户 'IIS APPPOOL\**' 登录失败的解决方案(项目部署到本地IIS上打开网页出现报错)

产品思维学习(三)--产品设计的五个层面

今天的读书会很碰巧有一位同学分享<用户体验要素-以用户为中心的产品设计>这本书.里面讲述了用户体验要素的五个层面:战略层,范围层,结构层,框架层,表现层.也是产品设计的五个层面,所以学习记录下.首先附上这五个层次的图: 首先介绍下用户体验要素这本书,这本书主要以web网页作为例子进行5个层次的论述.看起来已经不符合现在移动互联网的的时代需求了.其实不是,正所谓"心中有剑,折根树枝都能杀人",即使书中的例子没有涉及到移动的端的APP应用.但是仍然试用于相关产品的设计. 战略层