angryphoneMe envía un amigo (gracias, Alberto) un titular de Bandaancha que dice “Movistar se siente satisfecho por su servicio de atención al cliente“, y no puedo por menos que saltar automáticamente: ¿CÓMO? ¿SATISFECHO? ¿DE QUÉ? ¿Hablamos de verdad del 609, sin duda el peor de todos los servicios de atención al cliente que he tenido el disgusto de sufrir – nunca mejor utilizado el término – en toda mi experiencia como cliente? Revisando la entrevista a Domingo Vallejo vinculada en el artículo de Bandaancha, me planteo que posiblemente se trate de un titular mal escogido, porque veo referencias a “la satisfacción con el servicio prestado por los centros de atención al cliente que dan servicio desde fuera de España”, algo con lo que yo nunca he tenido ningún problema: me he encontrado operadores competentes e incompetentes, y nunca me ha parecido que la distribución de competencia tuviese nada que ver con el acento hablado por el operador u operadora de turno.

Así que lo siento, juro que no es “criticar por criticar”, pero es que no puedo estar experimentando un servicio como el 609 de Movistar y ver cómo su responsable aparece en los medios diciendo que “se siente muy satisfecho”, cuando lo que tendría que estar es admitiendo importantes problemas de calidad y afirmar que se está trabajando en su pronta resolución, aunque fuese mentira. Sé perfectamente que el resto de las operadoras tampoco son para tirar cohetes en este sentido, pero creo que ésto es algo que no puede funcionar en modo “mal de muchos, consuelo de tontos”.

Pero abandonemos el “modo cliente cabreado”, que resulta obviamente poco productivo, y entremos en “modo académico”, que no en vano soy profesor de un curso electivo sobre CRM en el que trato, entre otras cosas, gestión de call-centers: ¿qué prestaciones debe razonablemente tener un call-center hoy en día, y cómo puntúa en este sentido el 609 de Movistar?

  • Administración multiusuario y seguimiento de cliente: un operador tiene que poder transferir una llamada a otro de un departamento diferente, hacerlo además con toda la información pertinente tanto del cliente como del problema que está sufriendo, y mantener el histórico de redirecciones para su posible consulta. En este sentido es, seguramente, donde el 609 de Movistar obtiene una calificación más baja y donde resulta más enervante para sus clientes: cada redirección, y hablamos de una media de tres o cuatro por incidencia, supone que el nuevo operador vuelva a pedir al cliente su número de móvil y su DNI, y que repita entera la definición de dicha incidencia. La apariencia es que las transferencias de llamada se hacen simplemente por “quitarse al pesado del cliente de encima”, sin criterio alguno: en un número extraordinariamente elevado de ocasiones, la llamada termina simplemente cortándose – lo que conlleva el engorro de volver a empezar el proceso de nuevo – o con un “lo siento, eso no corresponde a este departamento, llame al 609″… que viene a ser a donde habías llamado originalmente…
  • Vínculo con la ficha del cliente en todas las bases de datos de la compañía: El sistema debe permitir acceder al fichero de un cliente, consultar sus datos completos, y obtener una visión de 360º sobre el cliente. El 609 permite a las operadoras acceder a los datos del cliente, pero la impresión es que éstos se encuentran en un 286 del año 1990 unido a la red por un módem de 2400 baudios: el “espere un momento, que estamos accediendo a su ficha” supone esperas nunca inferiores a los tres o cuatro minutos, completamente inaceptables en una interacción de este tipo. Además, los datos que el operador recibe en su pantalla son incompletos: si se hace referencia a determinados aspectos, la llamada debe ser transferida, y el nuevo operador tarda un tiempo similar en volver a acceder a la ficha.
  • Indicadores de perfil de clientes: Alertas e indicadores que ofrezcan al operador una idea de con quién está hablando, de la criticidad del cliente o de su perfil. En el caso del 609, esta prestación debe encontrarse sumamente ausente: el 609 es como un pez, tiene una memoria de tres segundos. Recuerda experiencias anteriores, pero el operador parece ignorarlo, porque solo a demanda del cliente consulta lo que otro operador le dijo en un momento dado. Si bien el sistema tiene apuntadas algunas características del cliente o su historial de interacción, su uso por parte de los operadores resulta muy poco habitual.
  • Call forwarding, con el correspondiente control de seguimiento y asignación de prioridades/severidades: un operador debe poder redireccionar la llamada al responsable adecuado, incluyendo la posibilidad de escalar a otro nivel con el fin de hacer frente a determinadas actitudes. En el caso del 609, plantear ésto es ciencia-ficción. La demanda de hablar con un supervisor no produce el más mínimo efecto – posiblemente por un exceso de uso de este recurso por parte de los clientes (llevados obviamente por la desesperación). Las redirecciones, como ya hemos comentado, se producen sin aparente criterio lógico, provocan una gran molestia al cliente, y en muchas ocasiones acaban sin dar solución al problema – o peor, interrumpiendo abruptamente la llamada por un corte en la comunicación (corte en la llamada… por favor, ¡¡que estamos hablando con Telefonica!!!)
  • Vínculo con la knowledge-base de la compañía: Un operador debe poder consultar en tiempo real problemas similares reportados por otros clientes y solucionados previamente por otros operadores. En el caso del 609, este tema está notablemente ausente: cada problema es un problema nuevo, aunque le haya ocurrido al mismo cliente anteriormente, a no ser que el cliente demande específicamente la consulta de incidencias anteriores. Como resultado, el sistema carece completamente de la capacidad de aprender. Si anteriormente nos planteábamos que el 609 tenía “memoria de pez”, esta es otra prueba más de ello.
  • Monitorización de estadísticas, rendimiento del operador e incidencias resueltas: El administrador del sistema debe poder generar estadísticas concernientes al rendimiento de los operadores con fines de evaluación. En este caso, ignoro completamente lo que el 609 posee en este sentido, pero mi impresión es que no debe ser demasiado eficiente: si yo administrase un call-center y observase, por ejemplo, el número de veces que la llamada simplemente “se corta”, dejando al cliente completamente colgado y maldiciendo a la compañía, no iría por el mundo declarando estar satisfecho con el servicio de atención al cliente de mi compañía.

Lo dicho: Movistar debería estar completamente avergonzada de, siendo una compañía telefónica, proporcionar un servicio de atención al cliente tan sumamente lamentable. Un líder mundial e incumbente en su sector no puede refugiarse en que el resto del sector proporciona servicios de atención al cliente igualmente malos. Telefonica tiene en su servicio de atención al cliente un verdadero problema: sistemas anticuados y de una calidad inaceptable, acompañados seguramente por una escasa motivación del personal. Algo completamente incoherente con su pretensión de ser, supuestamente, una compañía orientada al cliente. Si bien la gestión por excepciones sí funciona razonablemente bien en muchos casos, como tuve personalmente la oportunidad de comprobar, lo hace completamente al margen del sistema y no coordinada con éste, de manera que si bien puede actuar como solución de emergencia en determinados casos y ser muy apreciado por aquellos clientes que lo disfrutan, no sirve para mejorar la calidad global del sistema o para generar unas mejores prácticas de actuación.

 

Tras ser objeto de una cierta polémica durante la semana pasada, está ya finalmente disponible el texto del Open Cloud Manifesto, una iniciativa de varias empresas entre las que destacan IBM, Sun Microsystems, Cisco, Novell, Red Hat, EMC y varias más (entre otras la española Telefonica), para definir lo que serán las reglas de juego de las iniciativas de Cloud Computing que estamos ya viendo y que se generalizarán como el nuevo esquema computacional característico de los tiempos en que vivimos.

La polémica se desató la semana pasada a partir de una entrada de Steven Martin, de Microsoft, en las que atacaba la iniciativa y la tildaba de secretista y de oscura.  Steven afirmaba que lo que había que hacer era poner el documento en un wiki y discutirlo abiertamente, y que la cuestión de los estándares precisaba una discusión larga hasta que el proceso se solidificase. El recurso a este tipo de técnicas no es nuevo en la estrategia de Microsoft: reclamar el desarrollo de un proceso supuestamente abierto en el que poder intervenir, para poder llegar a posiciones de fijación de estándares ventajosas mediante la saturación del proceso con “votos amigos” y estandarizaciones de facto. En realidad, el Open Cloud Manifesto es un documento enormemente generalista y abierto, que pretende sentar definiciones y bases de funcionamiento de cara al futuro, y en ese sentido resulta de lo más recomendable revisar cada una de sus seis páginas.

Junto con ese reciente vídeo de Salesforce.com, el Open Cloud Manifesto es una manera interesante de visualizar los futuros escenarios en los que empresas y particulares desarrollaremos nuestra actividad en los próximos años, lejos ya de la visión ordenador-céntrica propia del siglo pasado. Sin perder de vista los peligros y limitaciones, pero con la mentalidad clara acerca de dónde vamos: un mundo caracterizado por la escalabilidad, el adelgazamiento del datacenter corporativo, la mejora de los procesos de negocio y la reducción de costes para las compañías que inician sus actividades. El documento define las seis principales barreras y desafíos a tener en cuenta de cara a la adopción: la seguridad, la interoperabilidad de datos y aplicaciones, la portabilidad basada en estándares, la gestión y gobernanza de las iniciativas, y la medición y monitorización de los sistemas. Los objetivos propuestos, por tanto, son la libertad de elección de proveedor y arquitectura, la flexibilidad basada en interoperabilidad, la velocidad y agilidad para el cambio y el redimensionamiento, y la disponibilidad de profesionales formados en un conjunto menor de tecnologías.

Para lograr los objetivos, los firmantes del Open Cloud Manifesto ratifican seis principios:

  1. Trabajar juntos para que los retos fundamentales en la adopción sean solucionados mediante colaboración abierta y el uso adecuado de los estándares
  2. No utilizar su posición de mercado para convertir a sus clientes en cautivos de una plataforma concreta  y limitar su libertad de elección
  3. Usar y adoptar los estándares existentes siempre que sea posible, para evitar así reinventarlos o duplicarlos
  4. Recurrir con prudencia a la creación de nuevos estándares, y cuando así sea por necesidad, hacerlo con pragmatismo, reduciendo el número de estándares necesarios, y asegurando que éstos promueven la innovación en lugar de inhibirla
  5. Llevar a cabo iniciativas en función de las necesidades del cliente, no de las necesidades técnicas de los proveedores
  6. Trabajo conjunto y coordinado de todos los actores implicados para evitar que sus iniciativas entren en conflicto o se solapen.

De cara a ver el establecimiento definitivo de esta serie de principios generales, falta por ver cuál es la posición que adoptan algunos de los actores principales al respecto: entre otros, faltan por definirse tres actores importantes y muy activos: Google, Amazon y Salesforce, con iniciativas muy importantes dentro del Cloud Computing a día de hoy. En cualquier caso, el desarrollo de este proceso normativo es importante, y a pesar de toda la parte política involucrada en el tema, parece intentar aprender claramente de los errores del pasado. Veremos como se sigue desarrollando.