Hace un par de años tuve una discusión con un proveedor de hosting por un problema relacionado a la baja de mi dominio, esto debido a que ingresaron mal mis pagos a su sistema. Al darme cuenta del problema y ver mi sitio caído, ingreso mi solicitud dentro del sistema de tickets identificándolo con prioridad “urgente”, había pagado por un servicio que estaba caído,no por circunstancias generales de la red sino que por una decisión de mi proveedor. La respuesta del proveedor fue nula, y aunque a los dos días el servicio estaba nuevamente habilitado no hubo siquiera un correo de aviso de rectificación de la situación, entonces mi respuesta fue enviar un nuevo ticket exigiendo una explicación formal a la situación. Finalmente, la respuesta del proveedor, fue lo más lejano a una retribución verbal por su mala gestión.
Protocolos.
Una definición de protocolo dice que este es “el conjunto de conductas, reglas y normas sociales que se aplican por conocer, respetar y cumplir: no sólo en el medio oficial ya establecido, sino también en el medio social, laboral, académico, político, cultural …” (Wikipedia) y en mi opinión, el objetivo de un protocolo es tener un mapa mental de todos los procedimientos a ejecutar, en situaciones dadas, con el fín de evitar PROBLEMAS y conseguir (sobre todo en el caso de las empresas de servicios) un servicio SATISFACTORIO.
Resulta que los protocolos de mi proveedor de hosting definían que si un ticket estaba mal priorizado, por ejemplo usar la prioridad más alta (Caída de Hosting) sin ser el caso, no habría respuesta para el cliente e inclusive podría haber un cobro asociado. Este protocolo lo que busca es hacer más eficiente la gestión del soporte técnico en vista de la cantidad de gente que prioriza de URGENTE situaciones que podrían no serlo (ayuda para configurar el correo por ejemplo). En mi caso y dado que no existía una prioridad asociada a Caída de Dominio, lo más lógico es pensar que su paralelo es Caída de Hosting (en términos de jerarquía comparten la misma problemática), por lo tanto y dado que mi ticket, según la conclusión sacada por el analista de turno, estaba mal priorizado, decidieron resolver su error pero no informarme de esto. La respuesta a mi nuevo ticket pidiendo explicaciones fue indicarme que había hecho mal uso de las prioridades y que no correspondía una respuesta, palabras para disculparse por botar un servicio que había sido pagado dentro de las fechas correspondientes fueron inexistentes.
Las conversaciones vía tickets duraron bastante (no voy a entrar en detalles para no alargar el tema) y poco a poco la cordialidad de nuestro proveedor comenzaba a desaparecer, hasta llegar al punto de faltar absolutamente a cualquier estándar de buen servicio (e inclusive, buena educación) pero yo no soltaría la discusión hasta obtener una disculpa por una falta al servicio contratado. Finalmente y tras ser invitado a dejar los servicios del hosting termino llamando a sus oficinas, pidiendo hablar con la persona indicada y obteniendo al fin (unas muy forzadas) disculpas por el mal servicio.
A grandes rasgos hay 3 problemas graves en el diseño de servicio de este proveedor de hosting:
1. Problemas de diseño de la arquitectura de la plataforma de soporte, dejando hoyos evidentes en todos los procesos de interacción usuario > soporte_hosting (la categorización de prioridades no incluía todos los servicios que ofrece el hosting) lo que permitía “errores” de selección de prioridad por parte de los usuarios.
2. Problemas en el diseño de protocolos, las personas detrás del soporte son personas, personas con cerebro que piensan y pueden reflexionar sobre situaciones dadas. Tomar un protocolo como una regla a ejecutar, cual robot, es una situación transversal a muchos servicios, principalmente de post-venta, lo vemos en call-centers, servicios al cliente y otros donde, por lo general, sólo es posible de resolver “pidiendo hablar con el supervisor o jefe”. En mi caso particular el interlocutor era el dueño del hosting, por lo que la situación era aún más difícil de resolver.
3. Una deficiente definición de la relación con los clientes. Un cliente siempre es un cliente y se debe respetar, puede estar equivocado pero jamaz se le puede dejar en el aire sin solución alguna. En este caso particular probablemente lo que debió haber ocurrido fue PRIMERO resolver el problema, SEGUNDO pedir disculpas por haber faltado al servicio, explicar las razones y FINALMENTE (y sólo en este momento) comentar que el ticket estaba mal priorizado (en este caso también había un problema allí) y pedir que en el futuro se eviten esos problemas.
Situaciones como la que expongo seguramente le debe haber pasado en cualquier momento a alguna persona que contrata un servicio. Es tan importante la planificación (diseño) de todos los procesos e interacciones que se ven involucrados en la prestación de servicios que un mal diseño de este, permite y fomenta los errores en la ejecución con usuarios finales. La frustración es evidente y la fidelidad con la marca (si es que existía) se pierde.
