Cómo tener éxito en su implementación de call center. 3ª. de 3 partes

En la 2ª parte de esta serie se analizaron diferentes etapas de la implementación del call center, como por ejemplo la importancia de contar con un arquitecto de soluciones, los objetivos asociados al arranque del proyecto, las consideraciones tecnológicas y los requerimientos de diseño del proyecto, que es la fase más importante, y cómo embonan estos factores en la integración del call center.

Implementación

El tema del desarrollo de prototipos nos conduce a la implementación en sí. Considerando todos los demás factores como constantes, el éxito de una implementación por lo general se reduce a contar con los recursos adecuados en un entorno adecuado. Eso significa que los desarrolladores y los integradores tengan acceso a los sistemas con los cuales necesitan trabajar, que cuenten con las autorizaciones y permisos es necesario para instalar y configurar los sistemas, y que dispongan del tipo de datos que necesitan para simular condiciones reales operación, entre otros requerimientos. Lo que rotundamente no significa es que alguien se presente en las instalaciones del cliente para dedicarle dos días de trabajo y deba esperar un día y medio para que “lo den de alta”, o hacer que alguien tenga que esperar un mes para la entrega de algún dato sólo para descubrir que el sistema no maneja el tipo de comportamiento necesario para el trabajo de desarrollo.

Una buena práctica de implementación consiste en hacer que la gente adecuada comience a comunicarse desde muy temprano en el proyecto y en asegurarse que tengan la autoridad necesaria para lograr que las cosas se hagan. En papel, la implementación viene después del diseño. Usted no va a poder construir nada mientras no tenga el diseño perfectamente definido y aprobado. Sin embargo, especialmente cuando uno ya tiene una muy buena idea de hacia dónde va, una de las primeras cosas por hacer es comenzar a preparar sus sistemas de desarrollo. Esta es una actividad en la que es posible hacer avances concretos mientras se afina el diseño, especialmente en los casos en que hay preguntas que necesitan ser resueltas antes de concluir el diseño — ¿cómo se va a comunicar mi IVR con este sistema en el backend? ¿Puedo integrar estos controles a la aplicación de CRM o tengo que irme por otra ruta? Y, por supuesto, siguiendo la línea de pensamiento previamente expuesta, entre más pronto se tenga un ambiente de trabajo, más pronto se podrá comenzar a trabajar en un prototipo.

La obra terminada

Un área que siempre se pasa por alto a la hora de seleccionar al integrador del sistema es su capacidad para diagnosticar problemas del sistema durante el proyecto. Así como algunos médicos son mejores que otros para diagnosticar un problema en un paciente, algunos integradores son mejores que otros para diagnosticar cuál es el problema con una implementación. Entre mejor sea su capacidad de diagnóstico, más terso resultará el proceso de implantación.

Contar con las herramientas adecuadas para ayudar a suministrar información sobre los síntomas resultará sumamente útil a lo largo de todo el proceso. Una de las calamidades de todo proyecto de implementación es que de pronto se presenta algún problema que nadie entiende. Pueden pasar días o semanas hasta que se resuelve y, mientras tanto, los proveedores se echan la culpa unos a otros y lo dejan a usted, el propietario del proyecto, a que averigüe qué está sucediendo en un ambiente técnico y sumamente complejo, y a que consiga a alguien que pueda solucionarlo.

Al momento de hacer su evaluación inicial de los proveedores, averigüe cómo es que pretenden aislar y resolver los problemas que lleguen a presentarse durante el proceso de implementación. Estar seguro que sus proveedores pueden resolver cualquier problema rápidamente puede acortar hasta en semanas el tiempo del proyecto, liberar a su personal más pronto, y garantizar que podrá mantener a raya los costos de sus proveedores.

Contar con buenas herramientas de diagnóstico también le permitirá resolver los problemas que se presenten en su ambiente de producción cuando sea necesario hacer cambios, y también acortarán considerablemente el tiempo de resolución. Sus costos totales serán menores y su negocio funcionará mejor si usted puede determinar la fuente específica de un problema en cuestión de horas en vez de días. Preste mucha atención a esto desde el principio de su implementación para cerciorarse que las cosas marchen sobre ruedas en un futuro.

Pruebas de aceptación

Ya hemos planteado la mayor parte de los puntos clave que necesitamos presentar. Hablando de pruebas de aceptación, uno de los principales problemas es el del sentido de “propiedad”. Hay que dejar bien claro que su proveedor es el responsable de garantizar que la solución que ha sido implementada esté funcionando correctamente. Esto se definiría como una prueba de sistema: asegurarse que el sistema en su conjunto funcione bien, de cabo a rabo. La propiedad de cualquier prueba de sistema le corresponde al proveedor. Las pruebas de aceptación, en cambio, son un proceso de aceptación que a menudo se sigue para que el propietario del proyecto pueda determinar que la solución satisface sus necesidades. Por lo tanto, la propiedad de las pruebas de aceptación le corresponde definitivamente a los propietarios y patrocinadores del proyecto, quienquiera que sea que va a “aceptar” el sistema.

Es mejor si la propiedad de los diferentes tipos de pruebas queda entendida de manera explícita desde un principio. Por lo general el proveedor se va a asegurar que el sistema funcione correctamente, pero usted tiene que cerciorarse que satisfaga sus criterios de aceptación. Es importante señalar que estas pruebas pueden ser una misma, y más aún, que incluso cuando se habla de pruebas de aceptación, el proveedor debe poder ayudarle a implementar las pruebas, pues ellos saben cómo hacer que funcione el sistema. Pero, en última instancia, usted necesita recordar que se trata de su sistema y, por consiguiente, tendrá que hacer suya la responsabilidad de asegurarse que las cosas se organicen. Si comenzó bien su proyecto con una descripción adecuada de cómo se debe comportar el sistema, entonces fincó buenos cimientos para las pruebas de aceptación. Cada proveedor necesita presentar casos de prueba para la parte del sistema que les corresponde conforme a las especificaciones definidas por usted. Todos los proveedores, juntos, deben contribuir con aquellos casos que pongan a prueba el funcionamiento del sistema en su conjunto. Una persona debe ser responsable de organizar todo para conformar un paquete coherente de casos de prueba.

Le aconsejamos no poner a prueba únicamente casos positivos; esto es, hay que asegurarse que las pruebas de su sistema no se limiten a confirmar que el sistema funciona como debe ser cuando se usa de la manera en que usted espera que sea utilizado. Hablando de desarrollo de software en general, el 80% del código está dedicado a manejar situaciones de error. Si usted prueba todos los casos positivos, habrá cubierto, por consiguiente, tan sólo el 20% de su funcionalidad. Cerciórese de poner a prueba los puntos de falla y trate de determinar cómo se comporta el sistema cuando no se le utiliza debidamente. Es importante tomar en cuenta que no hay manera de anticipar todas las distintas maneras en que se abusará del sistema en la práctica.

Transición

Es importante planear el proceso de transición con la debida anticipación. Divídalo en etapas siempre que sea posible cuando se trate de un rollout complejo, y apréndase de memoria el procedimiento para revertirlo en caso necesario.

A partir del momento que comience su proyecto usted deberá estar contemplando el momento en que llegue a su término. Al principio, la transición no es más que un momento de la verdad aparentemente distante. Pero muy pronto llegará el momento en que se encuentre previendo contingencias y determinando las listas de actividades para pasar del Viejo al Nuevo Mundo. Y la verdad es que lo deseable es que no se trate de un momento de la verdad, sino más bien de una secuencia ordenada de pasos. Para ello necesita identificar todo lo que pueda implantarse de antemano e implantarlo. Cualquier software en su sistema de IVR o CRM, o en las terminales de sus agentes que pueda instalar de antemano será una cosa menos de qué preocuparse cuando llegue el momento. Entre menos cosas tenga que hacer al mismo tiempo, mejor.

Un aspecto importante de la transición consiste en garantizar que todos los sistemas prescritos estén funcionando, lo que significa que una de las últimas cosas que va usted a hacer es incorporar la configuración del sistema completo. A menudo este es el último paso antes de comenzar la transición, pero con mucha frecuencia ocurre que el equipo de proyecto no se da cuenta de que la información de configuración que necesita no se encuentra disponible en una sola fuente, y además resulta que la que está disponible muchas veces está obsoleta. Es muy importante entender qué información se necesita y recabarla con tiempo. Si además la verifica dos veces para cerciorarse que es la información más exacta y actualizada, habrá dado un paso crucial para una implementación sin sobresaltos.

La capacitación es a menudo un aspecto complicado. Es indispensable capacitar a los agentes y a los supervisores con anticipación. Hay que explicar con lujo de detalles cualquier modificación que vaya a sufrir el comportamiento de los teléfonos o las aplicaciones. Muchas veces la capacitación se aborda en forma precipitada, con lo cual los agentes sienten que son los últimos en enterarse de lo que está sucediendo y los primeros en padecer los efectos secundarios. Aproveche sus sesiones de capacitación para ganarse el entusiasmo de los agentes. Explíqueles la “imagen de conjunto”, cómo es que estos cambios son mejoras que les ayudarán a alcanzar sus objetivos (lo cual, idealmente, ¡debería ser cierto!). Recuerde que los buenos agentes utilizan sus herramientas de manera habitual y como verdaderos expertos. Si van a tener que modificar sus hábitos, hágaselos saber con antelación y explíqueles por qué.

Durante la transición en si, cualquier cosa que pueda hacerse por etapas deberá hacerse así. Por ejemplo, si puede hacer la transición de las aplicaciones número por número en su sistema de respuesta interactiva de voz, hágalo. Si puede hacer la transición de los agentes a la nueva aplicación por grupos, hágalo.

Si quita cualquier elemento del sistema, cerciórese de que sabe cómo volverlo a incorporar en caso necesario. Tenga cuidado en aquellas situaciones en las que esté reutilizando algún equipo de hardware. ¿Está instalando su nuevo servidor de CTI en la misma computadora del sistema viejo? Más le vale que sepa cómo revertir el procedimiento, por si acaso.

Y por supuesto no hay que olvidar todas las formalidades de rigor a la hora de la transición para asegurarse que todos los interesados en el negocio estén al tanto de lo que está sucediendo – qué se está cambiando y cómo puede afectar el desempeño de sus labores, tanto en el mejor como en el peor de los casos. No basta con cerciorarse de tener personal a la mano en caso de una posible falla, sino también que los supervisores estén al tanto de cualquier problema crítico al que necesiten estar atentos y que sepan a quién y cómo deben reportarlo.

La mañana siguiente

Entonces, ¿qué pasa una vez que se acaba la música? La respuesta: nunca se acaba. El ritmo cambia, pero puede estar seguro que siempre seguirá habiendo cambios. Algunas organizaciones prefieren un proceso formal de cierre de proyecto en el que todos los pendientes de proyecto se “empacan”, se palomean oficialmente las listas de comprobación, y se libera a los integrantes del proyecto. Eso suena muy bien y, si usted sabe cómo hacer que funcione (o si es congruente con la manera en que se hacen las cosas en su organización), adelante. Nosotros hemos visto, por experiencia, que algunas transiciones se dan de manera limpia y rápida, pero otras pueden llevarse algún tiempo hasta que las cosas se estabilizan. Cuando llega a haber ruido, generalmente se debe a errores de configuración de hardware (muchas veces en el PBX) que habrían resultado muy difíciles de prever y a veces resulta difícil aislar. En este caso va a necesitar que sus equipos de soporte dediquen tiempo adicional a ir depurando todas las fallas. Eso nos lleva al punto de la transición al área de soporte.

A lo largo del proyecto se trabaja en estrecha colaboración con los equipos de implementación del proveedor, los expertos en integrar la solución. En muchos sentidos, la prueba de fuego para determinar el calibre de un proveedor viene después de la implantación. Si de pronto se encuentra con que no puede comunicarse con su equipo de expertos después de la transición, está usted en aprietos. Es una exageración, pero sin duda sería muy bueno que no hubiese un cambio de guardia radical en cuanto se da la transición. Sería injusto que usted esperase que el ingeniero que implementó su solución le resolviese problemas de configuración de rutina, pero no es poco razonable esperar que esta persona esté disponible para resolver problemas que afecten el desempeño de su call center y no hayan sido debidamente atacados durante el proyecto.

Conclusión

Los proyectos de integración de call centers son complejos por naturaleza, y tradicionalmente son más difíciles que los proyectos básicos de integración de datos que por lo general enfrentan los departamentos de TI. El call center abarca una gran variedad de tecnologías que interactúan no sólo con sus principales sistemas de negocios, sino también con el activo más valioso de su empresa: sus clientes. Muchas implementaciones en este terreno no son consideradas como éxitos, pero hemos descubierto que, siguiendo algunos de los lineamientos aquí presentados, es posible lograr que las cosas funcionen, es posible integrar y optimizar el call center, y usted puede tener éxito en mejorar la atención que brinda a sus clientes sin exceder su presupuesto. Al igual que con otros proyectos en el call center, todo se reduce a contar con gente capaz de hacer el trabajo, seguir aquellos procesos que favorezcan un resultado positivo, y usar una tecnología que satisfaga sus necesidades hoy y en el futuro.

Fuente: ContactCenterWorld