• okcc坐席进线太慢,怎么办?


    有客户反馈坐席进线太慢,坐席等一个电话,要等很久。

    要知道,呼叫中心存在的核心价值之一,就是充分提高坐席的工作效率。

    如果坐席进电话太慢,基本意味着,这是一个失败的产品。

    详细了解后,原来客户采用的模式是播放语音后转坐席。

    后来,我们统计了呼叫数据,进行了详细分析,找到了症结所在。

    基于统计数据,再加上2个合理假设,建立一个分析模型,对数据进行分析,发现客户投诉真实成立。

    坐席接听电话的平均间隔超过22秒,考虑到这是平均值,实际情况翻一倍也很正常,意味着,很多情况下,坐席要等待超过半分钟才会接到下一个电话。

    统计的坐席实际利用率,75%左右,属于较低水平。

    这种效率,必然不可忍受。

    核心原因也在于,市场形式的变化,语音群呼消失了很长一段时间,我们对于语音群呼的分析不够,即使群呼,转坐席的也比较少见,很多都是记录一个按键。

    例如,我们设计的预测外呼,综合考虑呼损及坐席效率,有一个基础假设,接通率大致在20%,但从上面数据分析来看,呼叫接通率超过30%,但实际能接通到坐席的比例,没有超过5%。

    特别的,我们对于少量坐席的群呼,算法又有针对性优化;而市场上的客户群体,特别是语音群呼,坐席数量都不多,所以,这个问题一直没有被明显暴露。

    而这个客户,语音群呼这个模式下,居然有接近30个坐席;20% vs 5%,这就是导致坐席进线慢的核心原因所在。

    继续引申下去,如果要达到一个相对合理的进线效率,系统应该是如何表现的呢?

    我理解的,在坐席工作强度不引起其反感的情况下,坐席的利用率能到达85%,应该算是一个比较优秀的水平。

    上图中,根据我设计的模型,系统需要的平均并发数大致在460左右,CPS为13.5。

    考虑到实际的呼叫过程中,呼叫接通并不是平均分布,理论上应该呈现为正态分布,可以大致认为,最高并发数要能达到这个平均并发数的2倍才较为合理。

    意味着,要支撑起85%的坐席利用率,28个坐席的呼叫任务,播放语音转坐席,系统的并发数要能支撑到900线以上,CPS要到30左右。

    跟我们实际观测到的现状,较为吻合。

    当然,在坐席利用率75%的情况下,呼损(有意向等待坐席接听电话但因为坐席全忙而挂掉)高达25%,这个数据非常恐怖了,如果提高到85%,这个呼损会到多少?

    虽然,对于语音群呼而言,呼损再高,客户也不会直接感受到。

     

  • 相关阅读:
    Tomcat 安装
    c#入参使用引用类型为啥要加ref?
    Jetson Nano资料合集
    基于纯前端类Excel表格控件实现在线损益表应用
    上传图片并显示#Vue3#后端接口数据
    http实现文件分片下载
    Vue 3 相对于 Vue2,模板和组件的一些变化
    php 5.3开始使用mysqlnd作为的默认mysql访问驱动
    免费数据 | 新库上线 | CnOpenData中国保险中介机构网点全集数据
    nProgress的简单使用
  • 原文地址:https://blog.csdn.net/weixi_kelaile520/article/details/126172815