Cómo tener éxito en su implementación de call center
Introducción
Un call center es una unidad de negocios cuyo epicentro es la gente y donde el punto focal radica en una comunicación exitosa. Vivimos en una era en la que la tecnología está revolucionando esas comunicaciones, y los call centers de mayor éxito utilizan una amplia gama de aplicaciones: PBXs y Sistemas de Distribución Automática Llamadas (ACD) que enrutan las llamadas; Sistemas de Audiorespuesta (IVR) y sistemas de buzón de voz que proporcionan una capacidad de respuesta automatizada y de autoservicio; sistemas de Administración de las Relaciones con los Clientes (CRM) que los agentes utilizan para tener acceso a y trabajar con los registros de los clientes; y toda una batería de sistemas de reporteo, supervisión y monitoreo de la calidad que los gerentes utilizan para manejar la operación del call center y medir su desempeño. Hay quienes podrían afirmar que casi todo sistema de negocios en una organización debería, de alguna manera, tener contacto con el call center. Para integrar todo esto en una solución única y coherente que satisfaga las necesidades de los usuarios finales, se necesitan no sólo un buen mapa de ruta, sino también un conocimiento exhaustivo y un entendimiento cabal de cómo se arma el rompecabezas, cuáles son las limitantes y restricciones, y qué es exactamente lo que se puede lograr con los sistemas y el presupuesto que tiene a su disposición. Se necesita algún tipo de guía.
Este artículo tiene el propósito de iniciar un diálogo sobre los pasos que hay que dar para garantizar una integración exitosa de su call center. Por desgracia, debido a la dificultad de combinar tan amplia variedad de sistemas con la impredecible comunicación en tiempo real con el cliente, son muchas las implementaciones que acaban por quedarse cortas respecto a las expectativas. Se puede fracasar de diversas maneras: el proyecto se prolonga y por lo tanto rebasa el presupuesto; los componentes tecnológicos no funcionan armónicamente como los proveedores prometieron; los usuarios finales rehúsan adoptar la tecnología. El fracaso puede ir desde que el sistema se considere como una molestia continua hasta el abandono total. Nosotros definimos el éxito como una entrega a tiempo y conforme al presupuesto, con la tecnología haciendo lo que usted espera que haga, y con la gente que trabaja en su call center entusiasmada con los resultados.
Cómo elegir a sus proveedores
Antes de comenzar un proyecto, es necesario seleccionar a sus proveedores. Todos hemos pasado por ahí: los socios prospectivos presentan sus credenciales y plantean sus propuestas – y usted debe elegir al que se perfile como el socio más compatible.
Al seleccionar un proveedor para una tecnología, usted está, hablando en términos generales, seleccionando dos cosas: la tecnología que vende y quién es. Este no es un tratado de las tecnologías en sí, por lo que damos por sentado que usted ha llevado a cabo la debida diligencia en lo que a elección de tecnología se refiere – ha comparado las soluciones con lo que ofrece la competencia y ha determinado que la tecnología de este proveedor tiene toda la funcionalidad que usted desea, es compatible con su ambiente tecnológico y es congruente con la visión de su organización a futuro. Ahora necesita evaluar si el proveedor es adecuado como prestador de servicios y socio/proveedor para su empresa.
Las estadísticas en la industria de call centers son bastante claras: si no se es cuidadoso, hay una probabilidad significativa de que el proyecto no tenga éxito, y una probabilidad aún mayor de que los costos resultan ser hasta dos veces lo que usted esperaba. Al elegir proveedores, usted está dando el primer paso para determinar si va a mantener su proyecto dentro del presupuesto o si va a pasar a ocupar un lugar en el lado deficitario de la ecuación. Usted necesita elegir a alguien que esté motivado para hacer que usted tenga éxito porque de ese modo también ellos tendrán éxito. Necesita crear una situación ganar/ganar, y la mejor manera de hacerlo es mantener todas las cartas sobre la mesa. Haga un esfuerzo por asegurarse que todos entiendan perfectamente el alcance de trabajo involucrado, y que sus proveedores estén dispuestos a entrarle por un precio justo. A cambio de la energía que usted dedique al “estira y afloja” con el proveedor de su elección con el fin de bajarle el precio hasta el mínimo absoluto posible, el proveedor se limitará a entregar exactamente lo usted adquirió... y nada más. Los márgenes perdidos los va a recuperar de otras maneras – cargos no especificados, funciones adicionales provenientes de modificaciones al alcance, y cargos extra hasta por el más mínimo detalle. A la hora de negociar, asegúrese de delinear con toda claridad qué quiere del proveedor y cómo espera que le sea entregado. La solución es compleja, así que hay que ser cautos.
Si usted crea una situación ganar/ganar con su proveedor – una en la que se entreguen bienes justos a precio justo, no debería haber motivos para que se presenten problemas continuamente en torno al precio. Por supuesto, toda negociación involucra a dos partes. Muchos proveedores rebajan el precio inicial con tal de ganar el negocio y después tratan de reponer lo perdido. Tenga cuidado con esta táctica. Como se mencionó anteriormente, uno de los dogmas de la industria dice que usted acabará pagando el doble de lo que pensó que iba a pagar. Si un precio le parece sospechosamente más bajo que los demás, escrutínelo bajo una lupa de escepticismo y exija que la definición del trabajo sea doblemente clara para garantizar que su proveedor se esté comprometiendo a entregarle éxito.
Específicamente, hay que prestar atención a lo siguiente:
La idea no es asegurarse de que su proveedor esté haciendo todo lo que aparece en la lista, sino más bien cerciorarse de que, de entrada, todo mundo entienda quien va a hacer qué, a fin de que todos puedan trabajar juntos de manera exitosa en un acuerdo mutuamente satisfactorio.
Administración del proyecto
Para tener un proyecto bien administrado, se necesita tener un buen administrador de proyectos.
¿Qué características hay que procurar en un administrador de proyectos? Antes que nada, experiencia en administración de proyectos técnicos en el campo de call centers. Alguien que ya haya guiado una implementación de soluciones exitosa en un call center es mucho más capaz de rendir buenos resultados que alguien que sólo tenga conocimientos generales de administración de proyectos. Un call center es una bestia muy particular, y se necesita alguien experimentado que la conozca bien.
Así que, ¿donde se puede encontrar a esa persona? ¿Va a recurrir a alguien interno, pedir al proveedor que la suministre, o a traer a alguien de fuera?
Administrador de proyectos interno
Las ventajas de utilizar a alguien interno son que la persona conoce su negocio y sabe cómo lograr que se muevan las cosas dentro de la organización. Si dispone de alguien así, que además entienda muy bien las cuestiones técnicas, probablemente es su mejor opción para encabezar el proyecto. Necesita poder interpretar la visión de conjunto y también (con asistencia técnica adecuada) llegar hasta un nivel considerable de detalle cuando se trate de puntos importantes. Esta persona, idealmente, debería ser uno de los principales decisores en la elección del proveedor. Si no está seguro de su capacidad técnica, tal vez valga la pena reconsiderar el nombramiento más detenidamente e incluso analizar la posibilidad de contratar a alguien externo.
Administrador de proyectos suministrado por el proveedor
Pedir al proveedor que proporcione el administrador del proyecto funciona bien si el proveedor va a realizar la mayor parte del trabajo o si está administrando la mayoría de los aspectos de la solución. En ese caso, casi podía uno considerar que el proveedor está obligado a administrar el proyecto. Pero tenga cuidado con sus expectativas. Ciertamente, el proveedor debe ser capaz de administrar la parte que le toca del trabajo, así como de administrar todas las áreas de trabajo en común para las cuales tenga el expertise necesario. Pero una cosa que un proveedor no puede hacer muy bien es movilizar recursos dentro de su empresa ni con otros proveedores involucrados en el proyecto. Aun si se conviene en que el proveedor administre el proyecto, de cualquier manera usted tendrá que proporcionar a alguien propio que tenga la autoridad para hacer cumplir su parte del trato y que pueda hacer suyo el proyecto. El área de mayor preocupación con un administrador de proyectos suministrado por el proveedor es que no son necesariamente objetivos en sus puntos de vista, y esto puede afectar el resultado del proyecto.
Administrador de proyectos consultor
Para un proyecto grande, a menudo es conveniente incorporar un administrador de proyectos contratado externamente si la persona tiene experiencia similar en proyectos similares. Esto le da a usted la ventaja de trabajar con alguien que es neutral desde el punto de vista técnico y profesional respecto a usted y los proveedores, y que puede fungir como árbitro imparcial en caso de discrepancias. La lealtad de su administrador externo debe ser para con el proyecto. Sin embargo, en este caso, necesita asegurarse de dar a esa persona suficiente autoridad para llevar a cabo su labor. No tiene caso traer a alguien de fuera si no se le faculta para hacer que se hagan las cosas.
Se ha hecho mucho énfasis en los aspectos técnicos del rol del administrador de proyectos. ¿Significa que un administrador de proyectos tiene que estar perfectamente familiarizado con todas las tecnologías involucradas en un proyecto? La respuesta rápida es “no”. Se trata de encontrar a alguien que tenga una visión muy completa de la tecnología del proyecto en general, y que tenga la capacidad para entender los detalles técnicos a medida que le sean presentados y explicados. Para ilustrar este punto, veamos un caso de estudio hipotético.
Vamos a crear en nuestra imaginación un proyecto de integración de un call center. Nuestra empresa imaginaria se llama GrowthCorp y cuenta con tres call centers en tres husos horarios distintos. Dos de ellos son idénticos en cuanto a tecnología, pues utilizan el mismo sistema de IVR y el mismo PBX, pero sin automatización CTI en las terminales de los agentes. El tercer centro es producto de una adquisición reciente. Utiliza un PBX y una plataforma de IVR distintos, pero tiene una integración CTI SmartCall de primera clase con un sistema de CRM GreatService. Actualmente no hay una red que enlace los tres centros. GrowthCorp ha decidido que quiere tener un solo call center virtual. A nivel corporativo también ha decidido adoptar GreatService como solución de CRM.
Luego de examinar muchas soluciones distintas, GrowthCorp decide (dejando de lado los diferentes drivers de negocios) lo siguiente: Va a establecer una red para enlazar los tres centros usando la misma plataforma de PBX para tener un único call center virtual con buena redundancia geográfica entre las tres regiones geográficas. Para la plataforma de PBX, ha optado por conservar el sistema A que utilizan dos de sus centros, pues ofrece buena capacidad de interconexión en red y una excelente plataforma para una migración futura hacia VoIP. Sin embargo, quiere utilizar el combo de IVR y CTI del centro C, ambos compatibles con el PBX A. En pocas palabras, el proyecto en general sería más o menos así:
En el proyecto tomarán parte representantes de los siguientes grupos:
Las probabilidades de que encuentre un administrador de proyectos con amplia experiencia en todas estas áreas son muy remotas. Pero lo que usted está buscando es alguien que haya administrado integraciones parecidas. El trabajo de su administrador de proyectos no consiste en entender todas las minucias técnicas de un proyecto tan vasto. Su labor es coordinar las actividades y asegurarse de que todo se haga. De modo que, aunque su administrador de proyectos no tiene que entender los detalles de configuración de cada uno de los componentes, si debería entender las dependencias entre todas las partes del sistema. Su administrador de proyectos debe poder entender cómo embonan las piezas y cómo sortear las múltiples “excusas” que sin duda le presentarán, a fin de determinar qué es real y qué no lo es.
Por encima de todo, su administrador de proyectos debe ser capaz de crear un ambiente de equipo en el que las dependencias se discutan, se evalúen y se incorporen al plan del proyecto. En lo que se refiere a los detalles técnicos, ese es el rol más importante de su administrador de proyectos: debe fungir como un agilizador, cerciorándose de que todos los detalles se ventilen y se incorporen a un plan integral.
Metas de negocios
Su gerente de proyecto tiene otro rol primario, en cierto sentido aún más importante. El gerente de proyecto necesita entender los motivadores de negocios del plan y cerciorarse de que estén siendo tomados en cuenta. Antes de comenzar cualquier tipo de labor de implantación, lo primordial es asegurarse de que se esté implementando una solución orientada a satisfacer las necesidades originales del negocio. En alguna parte hay alguien que ha formulado un caso de negocios para este proyecto. Lo más probable es que ese caso de negocios esté expresado en pesos y centavos, pero puede haber otros factores menos tangibles.
El gerente de proyecto debe saber cuáles son y nunca perder de vista el objetivo original. El gerente de proyecto también necesita incluir en el proceso a los usuarios finales del sistema. En todo proyecto de gran envergadura, usted va a estar afectando sistemas que han evolucionado hasta su estado actual debido a un conjunto perfectamente definido de razones.
Ahora, es posible que los sistemas no funcionen, que las razones hayan sido las equivocadas y que el proyecto pretenda solucionar las cosas. Si es así, usted necesita saberlo. Pero hay otros casos en los que un sistema se comporta como se comporta debido a otros motivos.
El arquitecto de la solución
Anteriormente presentamos una lista de las diferentes áreas involucradas en el proyecto y señalamos que no es probable que vaya usted a encontrar un gerente de proyecto que tenga experiencia en todas las distintas tecnologías que abarca el proyecto. Pero eso no quiere decir que no haya alguien involucrado en el proyecto que sí entienda a fondo la tecnología. Esa persona es el arquitecto del sistema.
El arquitecto es la persona que arma la solución. Esta persona puede ser un recurso interno de su empresa, un integrador de sistemas externo o bien uno de los proveedores que estén tomando parte en el proyecto. En cualquier caso, es la persona que ha llevado a cabo el diseño general y debe ser responsable de comunicarlo al resto del equipo. Más que eso, esta persona tiene que hacer suya la solución. Usted tiene que hacer que el arquitecto de la solución asuma esa responsabilidad, especialmente al principio, en las etapas de planeación. Hay que asegurarse que el panorama general del proyecto no esté guardado en las cabezas de los integrantes del equipo del proveedor responsable de contestar a su solicitud de propuesta. La solución propuesta, ya sea que estemos hablando de un recurso interno o externo, nos exige que nos aseguremos que esa persona esté presupuestada y asignada.
Un último comentario a este respecto: en un proyecto lo bastante pequeño, el arquitecto del sistema y el gerente del proyecto bien pueden ser una misma persona. En un proyecto grande, por lo general eso no sucede.
Armando las piezas
OK. Se ha dado la luz verde al equipo. Se ha dado la orden, se han generado las órdenes de compra, y ha llegado la hora de celebrar la junta de kickoff. ¿Qué debería usted esperar lograr en sus primeras juntas y a quién debe invitar? Por encima de todo, sea ambicioso. Se trata de echar a volar (no a gatear) el proyecto.
Sostenga una junta de arranque e introducción en toda forma. Invite a todos los involucrados dentro de su organización, incluyendo a los patrocinadores de negocios, a los responsables de la implementación y a los usuarios finales.
Los proveedores le vendieron la solución y son quienes estarán llevando a cabo la implementación, así que deben mandar tanto al ejecutivo de cuenta que hizo la venta como al gerente responsable de implementarla. La junta de kickoff debe tener tres metas principales:
Tenga a la mano a una persona para que dibuje un diagrama de todas las piezas y haga que el grupo participe en un recorrido guiado por el flujo y la manera en que se supone que las llamadas y los contactos deberán viajar por el sistema. Este es el momento en donde se empieza a ganar tracción. Todos en su equipo van a tener una visión ligeramente distinta de la llamada, pues cada quien la ve desde la perspectiva de su propia tecnología o necesidad de negocios. Cada proveedor tendrá un entendimiento inicial del proyecto con base en lo que tiene que entregar y seguramente ya tendrá una serie de preguntas e inquietudes fundamentadas en ese entendimiento. Ese recorrido guiado es en donde empiezan a visualizar la imagen de conjunto y donde los jugadores empiezan a aglutinarse como equipo. Permita que la gente se desvíe hacia los detalles si eso les ayuda a involucrarse y participar. Tire de las riendas si el foco comienza a difuminarse.
Tecnología de juntas y colaboración
La realidad de negocios determina que no siempre es posible congregar en una misma sala de juntas a todas las personas que usted necesita el mismo día. Si es necesario, aproveche la tecnología para permitir que algunas personas participen de manera remota, ya sea por teléfono o mediante aplicaciones tipo Webex™. Aproveche toda la tecnología que tenga a su alcance para salvar esas distancias, sin descuidar la importancia de las primeras dos o tres juntas en donde usted va a impartir propósito y rumbo al proyecto. Las primeras impresiones siempre son importantes y un proyecto tendrá más éxito si usted gestiona cuando menos una junta presencial de los principales involucrados. Haga que su proveedor vuele hasta la oficina remota para conocer a los miembros de su equipo, o traiga a los principales involucrados de la oficina remota al corporativo para una de las juntas iniciales del proyecto. Una vez que la gente se conoce, las juntas subsiguientes pueden llevarse a cabo fácilmente utilizando cualquier tecnología que se desee.
Requerimientos de diseño
En muchos sentidos, la etapa de requerimientos y diseño del proyecto es la más importante de todas. Esta es su mejor oportunidad para lograr que las cosas se hagan bien a la primera. Es en esta fase que hay que ponerse de acuerdo sobre qué se va a hacer y cómo se va a hacer. Cualquier cosa importante que se omita en esta etapa regresará más adelante para cobrar venganza -- si corre usted con suerte, unas semanas antes de la entrada en producción, cuando todavía se puede hacer algo al respecto, a cambio, simplemente, de una demora en la fecha prometida. En nuestra experiencia, la mayoría de los proyectos no son tan afortunados. En pocas palabras: en la medida de lo posible, resuelva sus problemas desde el principio, en la fase de diseño. Asegúrese de poner sobre la mesa absolutamente todos los requerimientos.
Aquí estamos hablando de un nivel muy general. Para el proyecto del ejemplo que presentamos anteriormente, se requieren un gran número de requerimientos y sesiones de diseño.
Una cosa que usted observará en relación con esta lista de requerimientos es que son sumamente diversos. Provienen de diferentes partes del call center que representan las necesidades de diferentes grupos.
Usted no va a obtener todos sus requerimientos en un solo lugar. Asegúrese de consultar a todas las personas que pudieran tener requerimientos o a aquellas que pudieran estar al tanto de restricciones o limitantes que incidan sobre su capacidad para satisfacer los requerimientos.
Es probable que se tope con requerimientos que se contraponen unos a otros. En la lista anterior vemos que los agentes siempre deben seleccionar un código de motivo de la llamada antes de poder tomar otro contacto. Antes de eso tenemos un segundo requerimiento que dice que no debe se debe hacer necesario modificar las pantallas del sistema CRM. Al parecer el grupo de sistemas ha trabajado mucho para lograr que el sistema de CRM funcione exactamente cómo quieren y consideran que la aplicación debe mantenerse congelada durante los próximos meses. Entonces llega un requerimiento que les obliga a abrir el código fuente y quizá hasta incluir por ahí algún botón nuevo. En este caso se trata de un requerimiento proveniente de las operaciones del call center que se contrapone a una restricción por parte del área de TI. La única manera de resolver este tipo de conflictos sin tener que acudir a instancias superiores es congregar bajo el mismo techo a todos los interesados desde el principio. Ponga los requerimientos sobre la mesa, ventílelos. Utilice un poco de psicología -- si alguien empieza a plantar obstáculos, déjelo hablar e involúcrelo en la solución. Mantenga a la gente concentrada en la meta en común. Recuérdeles lo valioso que es lo que se está haciendo.
Documentos y especificaciones
Durante esta fase, usted va a generar dos tipos de documentación: documentos de requerimientos y especificaciones funcionales. La especificación funcional es el documento de diseño resultante de recopilar sus requerimientos y elaborar su diseño (y, una vez más, estamos hablando de un documento compuesto por muchos elementos, muchas especificaciones diferentes juntas en una misma carpeta).
Ahora, como todo veterano del mundo corporativo sabe, un documento puede cobrar vida y convertirse en un fin en sí mismo. En ningún otro caso se manifiesta este fenómeno con mayor claridad que aquí. Hemos tomado parte en más de un proyecto en el que la elaboración y aprobación de una especificación se convirtió, en sí misma, en un proyecto existente casi en un universo paralelo. Luego, una vez que la especificación quedó concluida y aprobada, nunca más se volvió a hacer referencia a ella, casi como si desapareciese de la faz de la Tierra una vez que se termina de elaborar. La declaración de requerimientos y la especificación funcional constituyen un contrato entre el usuario final y la gente que va a realizar el trabajo: juntos, están afirmando “esto es lo que pretendemos lograr y así es como lo vamos a lograr.” Para ello, estos documentos deben ser exhaustivos y exactos. Pero no deben ser un fin en sí mismos. Su especificación funcional debe ser el resultado de su diseño, y no la razón por la que se hizo.
En el peor de los casos, la especificación se convierte en una especie de campo de batalla
El proveedor redacta su visión de cómo será el producto final y cómo va a funcionar. Usted, como cliente, lee ese documento y desarrolla su propio punto de vista. Luego lo modifica para alinearlo mejor con su propia visión y se lo devuelve al proveedor. Todo mundo afirma que está de acuerdo, todo mundo firma, y luego el proveedor va e implementa su propia visión de lo plasmado en ese documento definitivo, con toda una serie de supuestos y sesgos. Pero usted sabe que eso va a ocurrir, y por lo tanto se muestra renuente a firmarlo; “mejor vamos a afinarlo otro poquito, y otro poquito”. Como usted lo sabe, lo firma, y se convierte en ley.
Cuando usted quiere que el sistema haga algo que pensó que estaba cubierto, el proveedor va a señalar la especificación y a decir: “¿Ya ve? Eso no está”, o “¿Ya ve? Eso fue lo que hicimos; lo que pasa es que no es exactamente como usted pensaba que iba a ser”. Así que ¡nadie quiere firmar el documento! Lograrlo puede llevarse meses -- meses de tiempo del proyecto desperdiciados para que todo mundo pueda cubrirse debidamente el trasero, pero mientras tanto no está ocurriendo nada productivo en aras del proyecto. Créame: el proveedor no gana dinero si se la pasa haciendo revisiones a las especificaciones, y usted tampoco logra que se ejecute el proyecto.
La solución a todos estos problemas es también una práctica muy recomendable de ingeniería. Simplifique la especificación y el proceso de aprobación y luego trabaje rápidamente para elaborar una aplicación prototipo que pueda ser susceptible de revisión, crítica constructiva y mejora. Déle retroalimentación al proveedor. “Mueve este botón para acá; cambia esta lógica”. Por lo general hacer estos cambios no requiere grandes cantidades de trabajo si el proveedor entiende bien sus requerimientos de negocios e hizo su tarea antes de empezar. Este le permite a su equipo hacer aportaciones válidas sobre algo concreto. A la mayoría de nosotros no se nos da muy bien crear cosas a partir de la nada, pero sí tendemos a ser bastante buenos para señalar cómo mejorar aquello que podemos ver y con lo que podemos interactuar. Un prototipo le permite a su equipo ver lo que el sistema está haciendo y cómo va a funcionar, y aportar ideas válidas sobre cómo su negocio puede interactuar con él.
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
Un call center es una unidad de negocios cuyo epicentro es la gente y donde el punto focal radica en una comunicación exitosa. Vivimos en una era en la que la tecnología está revolucionando esas comunicaciones, y los call centers de mayor éxito utilizan una amplia gama de aplicaciones: PBXs y Sistemas de Distribución Automática Llamadas (ACD) que enrutan las llamadas; Sistemas de Audiorespuesta (IVR) y sistemas de buzón de voz que proporcionan una capacidad de respuesta automatizada y de autoservicio; sistemas de Administración de las Relaciones con los Clientes (CRM) que los agentes utilizan para tener acceso a y trabajar con los registros de los clientes; y toda una batería de sistemas de reporteo, supervisión y monitoreo de la calidad que los gerentes utilizan para manejar la operación del call center y medir su desempeño. Hay quienes podrían afirmar que casi todo sistema de negocios en una organización debería, de alguna manera, tener contacto con el call center. Para integrar todo esto en una solución única y coherente que satisfaga las necesidades de los usuarios finales, se necesitan no sólo un buen mapa de ruta, sino también un conocimiento exhaustivo y un entendimiento cabal de cómo se arma el rompecabezas, cuáles son las limitantes y restricciones, y qué es exactamente lo que se puede lograr con los sistemas y el presupuesto que tiene a su disposición. Se necesita algún tipo de guía.
Este artículo tiene el propósito de iniciar un diálogo sobre los pasos que hay que dar para garantizar una integración exitosa de su call center. Por desgracia, debido a la dificultad de combinar tan amplia variedad de sistemas con la impredecible comunicación en tiempo real con el cliente, son muchas las implementaciones que acaban por quedarse cortas respecto a las expectativas. Se puede fracasar de diversas maneras: el proyecto se prolonga y por lo tanto rebasa el presupuesto; los componentes tecnológicos no funcionan armónicamente como los proveedores prometieron; los usuarios finales rehúsan adoptar la tecnología. El fracaso puede ir desde que el sistema se considere como una molestia continua hasta el abandono total. Nosotros definimos el éxito como una entrega a tiempo y conforme al presupuesto, con la tecnología haciendo lo que usted espera que haga, y con la gente que trabaja en su call center entusiasmada con los resultados.
Cómo elegir a sus proveedores
Antes de comenzar un proyecto, es necesario seleccionar a sus proveedores. Todos hemos pasado por ahí: los socios prospectivos presentan sus credenciales y plantean sus propuestas – y usted debe elegir al que se perfile como el socio más compatible.
Al seleccionar un proveedor para una tecnología, usted está, hablando en términos generales, seleccionando dos cosas: la tecnología que vende y quién es. Este no es un tratado de las tecnologías en sí, por lo que damos por sentado que usted ha llevado a cabo la debida diligencia en lo que a elección de tecnología se refiere – ha comparado las soluciones con lo que ofrece la competencia y ha determinado que la tecnología de este proveedor tiene toda la funcionalidad que usted desea, es compatible con su ambiente tecnológico y es congruente con la visión de su organización a futuro. Ahora necesita evaluar si el proveedor es adecuado como prestador de servicios y socio/proveedor para su empresa.
Las estadísticas en la industria de call centers son bastante claras: si no se es cuidadoso, hay una probabilidad significativa de que el proyecto no tenga éxito, y una probabilidad aún mayor de que los costos resultan ser hasta dos veces lo que usted esperaba. Al elegir proveedores, usted está dando el primer paso para determinar si va a mantener su proyecto dentro del presupuesto o si va a pasar a ocupar un lugar en el lado deficitario de la ecuación. Usted necesita elegir a alguien que esté motivado para hacer que usted tenga éxito porque de ese modo también ellos tendrán éxito. Necesita crear una situación ganar/ganar, y la mejor manera de hacerlo es mantener todas las cartas sobre la mesa. Haga un esfuerzo por asegurarse que todos entiendan perfectamente el alcance de trabajo involucrado, y que sus proveedores estén dispuestos a entrarle por un precio justo. A cambio de la energía que usted dedique al “estira y afloja” con el proveedor de su elección con el fin de bajarle el precio hasta el mínimo absoluto posible, el proveedor se limitará a entregar exactamente lo usted adquirió... y nada más. Los márgenes perdidos los va a recuperar de otras maneras – cargos no especificados, funciones adicionales provenientes de modificaciones al alcance, y cargos extra hasta por el más mínimo detalle. A la hora de negociar, asegúrese de delinear con toda claridad qué quiere del proveedor y cómo espera que le sea entregado. La solución es compleja, así que hay que ser cautos.
Si usted crea una situación ganar/ganar con su proveedor – una en la que se entreguen bienes justos a precio justo, no debería haber motivos para que se presenten problemas continuamente en torno al precio. Por supuesto, toda negociación involucra a dos partes. Muchos proveedores rebajan el precio inicial con tal de ganar el negocio y después tratan de reponer lo perdido. Tenga cuidado con esta táctica. Como se mencionó anteriormente, uno de los dogmas de la industria dice que usted acabará pagando el doble de lo que pensó que iba a pagar. Si un precio le parece sospechosamente más bajo que los demás, escrutínelo bajo una lupa de escepticismo y exija que la definición del trabajo sea doblemente clara para garantizar que su proveedor se esté comprometiendo a entregarle éxito.
Específicamente, hay que prestar atención a lo siguiente:
- ¿Puede el proveedor hablar de manera coherente y significativa sobre cómo piensa implementar la solución?
- ¿Puede abordar con inteligencia las ramificaciones de funciones específicas que está ofreciendo suministrarle?
- ¿Busca un entendimiento concreto de su negocio y su entorno?
- Cuando alguien le dice que este componente se va a comunicar con aquel, ¿le dicen quién se va a encargar de que así sea?
- ¿Existe algún software o middleware adicional que se va a requerir pero que no ha sido identificado o desglosado en el costo?
- ¿Quién va a administrar qué partes del proyecto? Si espera que su proveedor administre todo el proyecto, ¿se lo ha hecho saber con todas sus letras?
- Si es necesario llevar a cabo trabajo de desarrollo en su front o back-end actual, ¿cómo se van a repartir las responsabilidades?
- ¿Quién es responsable de las pruebas del sistema, y por establecer ambientes de pruebas?
- ¿Cómo se va a capacitar a los usuarios finales? Si los agentes del call center van a utilizar nuevas interfaces, ¿quién va a proporcionar a los instructores?
- ¿Están contempladas todas las interfaces?
- ¿Qué tipo de documentación le van a entregar?
La idea no es asegurarse de que su proveedor esté haciendo todo lo que aparece en la lista, sino más bien cerciorarse de que, de entrada, todo mundo entienda quien va a hacer qué, a fin de que todos puedan trabajar juntos de manera exitosa en un acuerdo mutuamente satisfactorio.
Administración del proyecto
Para tener un proyecto bien administrado, se necesita tener un buen administrador de proyectos.
¿Qué características hay que procurar en un administrador de proyectos? Antes que nada, experiencia en administración de proyectos técnicos en el campo de call centers. Alguien que ya haya guiado una implementación de soluciones exitosa en un call center es mucho más capaz de rendir buenos resultados que alguien que sólo tenga conocimientos generales de administración de proyectos. Un call center es una bestia muy particular, y se necesita alguien experimentado que la conozca bien.
Así que, ¿donde se puede encontrar a esa persona? ¿Va a recurrir a alguien interno, pedir al proveedor que la suministre, o a traer a alguien de fuera?
Administrador de proyectos interno
Las ventajas de utilizar a alguien interno son que la persona conoce su negocio y sabe cómo lograr que se muevan las cosas dentro de la organización. Si dispone de alguien así, que además entienda muy bien las cuestiones técnicas, probablemente es su mejor opción para encabezar el proyecto. Necesita poder interpretar la visión de conjunto y también (con asistencia técnica adecuada) llegar hasta un nivel considerable de detalle cuando se trate de puntos importantes. Esta persona, idealmente, debería ser uno de los principales decisores en la elección del proveedor. Si no está seguro de su capacidad técnica, tal vez valga la pena reconsiderar el nombramiento más detenidamente e incluso analizar la posibilidad de contratar a alguien externo.
Administrador de proyectos suministrado por el proveedor
Pedir al proveedor que proporcione el administrador del proyecto funciona bien si el proveedor va a realizar la mayor parte del trabajo o si está administrando la mayoría de los aspectos de la solución. En ese caso, casi podía uno considerar que el proveedor está obligado a administrar el proyecto. Pero tenga cuidado con sus expectativas. Ciertamente, el proveedor debe ser capaz de administrar la parte que le toca del trabajo, así como de administrar todas las áreas de trabajo en común para las cuales tenga el expertise necesario. Pero una cosa que un proveedor no puede hacer muy bien es movilizar recursos dentro de su empresa ni con otros proveedores involucrados en el proyecto. Aun si se conviene en que el proveedor administre el proyecto, de cualquier manera usted tendrá que proporcionar a alguien propio que tenga la autoridad para hacer cumplir su parte del trato y que pueda hacer suyo el proyecto. El área de mayor preocupación con un administrador de proyectos suministrado por el proveedor es que no son necesariamente objetivos en sus puntos de vista, y esto puede afectar el resultado del proyecto.
Administrador de proyectos consultor
Para un proyecto grande, a menudo es conveniente incorporar un administrador de proyectos contratado externamente si la persona tiene experiencia similar en proyectos similares. Esto le da a usted la ventaja de trabajar con alguien que es neutral desde el punto de vista técnico y profesional respecto a usted y los proveedores, y que puede fungir como árbitro imparcial en caso de discrepancias. La lealtad de su administrador externo debe ser para con el proyecto. Sin embargo, en este caso, necesita asegurarse de dar a esa persona suficiente autoridad para llevar a cabo su labor. No tiene caso traer a alguien de fuera si no se le faculta para hacer que se hagan las cosas.
Se ha hecho mucho énfasis en los aspectos técnicos del rol del administrador de proyectos. ¿Significa que un administrador de proyectos tiene que estar perfectamente familiarizado con todas las tecnologías involucradas en un proyecto? La respuesta rápida es “no”. Se trata de encontrar a alguien que tenga una visión muy completa de la tecnología del proyecto en general, y que tenga la capacidad para entender los detalles técnicos a medida que le sean presentados y explicados. Para ilustrar este punto, veamos un caso de estudio hipotético.
Vamos a crear en nuestra imaginación un proyecto de integración de un call center. Nuestra empresa imaginaria se llama GrowthCorp y cuenta con tres call centers en tres husos horarios distintos. Dos de ellos son idénticos en cuanto a tecnología, pues utilizan el mismo sistema de IVR y el mismo PBX, pero sin automatización CTI en las terminales de los agentes. El tercer centro es producto de una adquisición reciente. Utiliza un PBX y una plataforma de IVR distintos, pero tiene una integración CTI SmartCall de primera clase con un sistema de CRM GreatService. Actualmente no hay una red que enlace los tres centros. GrowthCorp ha decidido que quiere tener un solo call center virtual. A nivel corporativo también ha decidido adoptar GreatService como solución de CRM.
Luego de examinar muchas soluciones distintas, GrowthCorp decide (dejando de lado los diferentes drivers de negocios) lo siguiente: Va a establecer una red para enlazar los tres centros usando la misma plataforma de PBX para tener un único call center virtual con buena redundancia geográfica entre las tres regiones geográficas. Para la plataforma de PBX, ha optado por conservar el sistema A que utilizan dos de sus centros, pues ofrece buena capacidad de interconexión en red y una excelente plataforma para una migración futura hacia VoIP. Sin embargo, quiere utilizar el combo de IVR y CTI del centro C, ambos compatibles con el PBX A. En pocas palabras, el proyecto en general sería más o menos así:
- Instalar el PBX A en el call center C y luego enlazar los tres centros en red.
- Dotar a todo el sistema de la solución IVR del centro C.
- Implementar el sistema de CRM GreatService en los tres centros, junto con CTI SmartCall.
En el proyecto tomarán parte representantes de los siguientes grupos:
- El proveedor de servicios de telecomunicaciones, a fin de determinar cómo enrutar las llamadas hacia y entre los tres centros
- El proveedor del PBX, para instalar el nuevo conmutador y configurar el enrutamiento de la red en función de habilidades
- El proveedor del sistema IVR, para configurar los nuevos programas de IVR para el centro virtual.
- El proveedor de CTI, para configurar la integración de CTI para el centro virtual
- El proveedor de CRM, para dar respaldo durante la implementación a nivel empresa.
Las probabilidades de que encuentre un administrador de proyectos con amplia experiencia en todas estas áreas son muy remotas. Pero lo que usted está buscando es alguien que haya administrado integraciones parecidas. El trabajo de su administrador de proyectos no consiste en entender todas las minucias técnicas de un proyecto tan vasto. Su labor es coordinar las actividades y asegurarse de que todo se haga. De modo que, aunque su administrador de proyectos no tiene que entender los detalles de configuración de cada uno de los componentes, si debería entender las dependencias entre todas las partes del sistema. Su administrador de proyectos debe poder entender cómo embonan las piezas y cómo sortear las múltiples “excusas” que sin duda le presentarán, a fin de determinar qué es real y qué no lo es.
Por encima de todo, su administrador de proyectos debe ser capaz de crear un ambiente de equipo en el que las dependencias se discutan, se evalúen y se incorporen al plan del proyecto. En lo que se refiere a los detalles técnicos, ese es el rol más importante de su administrador de proyectos: debe fungir como un agilizador, cerciorándose de que todos los detalles se ventilen y se incorporen a un plan integral.
Metas de negocios
Su gerente de proyecto tiene otro rol primario, en cierto sentido aún más importante. El gerente de proyecto necesita entender los motivadores de negocios del plan y cerciorarse de que estén siendo tomados en cuenta. Antes de comenzar cualquier tipo de labor de implantación, lo primordial es asegurarse de que se esté implementando una solución orientada a satisfacer las necesidades originales del negocio. En alguna parte hay alguien que ha formulado un caso de negocios para este proyecto. Lo más probable es que ese caso de negocios esté expresado en pesos y centavos, pero puede haber otros factores menos tangibles.
El gerente de proyecto debe saber cuáles son y nunca perder de vista el objetivo original. El gerente de proyecto también necesita incluir en el proceso a los usuarios finales del sistema. En todo proyecto de gran envergadura, usted va a estar afectando sistemas que han evolucionado hasta su estado actual debido a un conjunto perfectamente definido de razones.
Ahora, es posible que los sistemas no funcionen, que las razones hayan sido las equivocadas y que el proyecto pretenda solucionar las cosas. Si es así, usted necesita saberlo. Pero hay otros casos en los que un sistema se comporta como se comporta debido a otros motivos.
El arquitecto de la solución
Anteriormente presentamos una lista de las diferentes áreas involucradas en el proyecto y señalamos que no es probable que vaya usted a encontrar un gerente de proyecto que tenga experiencia en todas las distintas tecnologías que abarca el proyecto. Pero eso no quiere decir que no haya alguien involucrado en el proyecto que sí entienda a fondo la tecnología. Esa persona es el arquitecto del sistema.
El arquitecto es la persona que arma la solución. Esta persona puede ser un recurso interno de su empresa, un integrador de sistemas externo o bien uno de los proveedores que estén tomando parte en el proyecto. En cualquier caso, es la persona que ha llevado a cabo el diseño general y debe ser responsable de comunicarlo al resto del equipo. Más que eso, esta persona tiene que hacer suya la solución. Usted tiene que hacer que el arquitecto de la solución asuma esa responsabilidad, especialmente al principio, en las etapas de planeación. Hay que asegurarse que el panorama general del proyecto no esté guardado en las cabezas de los integrantes del equipo del proveedor responsable de contestar a su solicitud de propuesta. La solución propuesta, ya sea que estemos hablando de un recurso interno o externo, nos exige que nos aseguremos que esa persona esté presupuestada y asignada.
Un último comentario a este respecto: en un proyecto lo bastante pequeño, el arquitecto del sistema y el gerente del proyecto bien pueden ser una misma persona. En un proyecto grande, por lo general eso no sucede.
Armando las piezas
OK. Se ha dado la luz verde al equipo. Se ha dado la orden, se han generado las órdenes de compra, y ha llegado la hora de celebrar la junta de kickoff. ¿Qué debería usted esperar lograr en sus primeras juntas y a quién debe invitar? Por encima de todo, sea ambicioso. Se trata de echar a volar (no a gatear) el proyecto.
Sostenga una junta de arranque e introducción en toda forma. Invite a todos los involucrados dentro de su organización, incluyendo a los patrocinadores de negocios, a los responsables de la implementación y a los usuarios finales.
Los proveedores le vendieron la solución y son quienes estarán llevando a cabo la implementación, así que deben mandar tanto al ejecutivo de cuenta que hizo la venta como al gerente responsable de implementarla. La junta de kickoff debe tener tres metas principales:
- Comunicar el propósito del proyecto – Explique al grupo de qué se trata el proyecto. Desde una perspectiva de 20,000 pies de altura, explique en qué consiste y por qué se está llevando a cabo. La explicación debe estar enfocada al negocio y es mejor que la introducción la haga uno de los patrocinadores de alto nivel ejecutivo. Esta junta sirve para que la gente se conozca y se finquen relaciones. Pero también es crítico que usted establezca con claridad desde ese momento por qué se está llevando a cabo el proyecto, determine qué problemática es la que se está atacando y cuáles son las metas últimas de la iniciativa.
- Definir los criterios de éxito – Esto debe incluir el propósito del proyecto y qué significa que el proyecto tenga éxito. También es necesario abordar la importantísima cuestión de la fecha de entrada en producción.
- Poner la bola en juego – Es a esto a lo que nos referimos cuando le decimos que sea ambicioso. Es bueno poner la pelota en juego con una discusión técnica. Para ello, en el caso de proyectos grandes, es probable que se requiera llevar a cabo una sesión de continuación/seguimiento, con menos ejecutivos de cuenta y más personal técnico. Con esto se debe dibujar el panorama de conjunto a fin de echar a volar las ideas para las sesiones de diseño y planeación que vendrán a continuación.
Tenga a la mano a una persona para que dibuje un diagrama de todas las piezas y haga que el grupo participe en un recorrido guiado por el flujo y la manera en que se supone que las llamadas y los contactos deberán viajar por el sistema. Este es el momento en donde se empieza a ganar tracción. Todos en su equipo van a tener una visión ligeramente distinta de la llamada, pues cada quien la ve desde la perspectiva de su propia tecnología o necesidad de negocios. Cada proveedor tendrá un entendimiento inicial del proyecto con base en lo que tiene que entregar y seguramente ya tendrá una serie de preguntas e inquietudes fundamentadas en ese entendimiento. Ese recorrido guiado es en donde empiezan a visualizar la imagen de conjunto y donde los jugadores empiezan a aglutinarse como equipo. Permita que la gente se desvíe hacia los detalles si eso les ayuda a involucrarse y participar. Tire de las riendas si el foco comienza a difuminarse.
Tecnología de juntas y colaboración
La realidad de negocios determina que no siempre es posible congregar en una misma sala de juntas a todas las personas que usted necesita el mismo día. Si es necesario, aproveche la tecnología para permitir que algunas personas participen de manera remota, ya sea por teléfono o mediante aplicaciones tipo Webex™. Aproveche toda la tecnología que tenga a su alcance para salvar esas distancias, sin descuidar la importancia de las primeras dos o tres juntas en donde usted va a impartir propósito y rumbo al proyecto. Las primeras impresiones siempre son importantes y un proyecto tendrá más éxito si usted gestiona cuando menos una junta presencial de los principales involucrados. Haga que su proveedor vuele hasta la oficina remota para conocer a los miembros de su equipo, o traiga a los principales involucrados de la oficina remota al corporativo para una de las juntas iniciales del proyecto. Una vez que la gente se conoce, las juntas subsiguientes pueden llevarse a cabo fácilmente utilizando cualquier tecnología que se desee.
Requerimientos de diseño
En muchos sentidos, la etapa de requerimientos y diseño del proyecto es la más importante de todas. Esta es su mejor oportunidad para lograr que las cosas se hagan bien a la primera. Es en esta fase que hay que ponerse de acuerdo sobre qué se va a hacer y cómo se va a hacer. Cualquier cosa importante que se omita en esta etapa regresará más adelante para cobrar venganza -- si corre usted con suerte, unas semanas antes de la entrada en producción, cuando todavía se puede hacer algo al respecto, a cambio, simplemente, de una demora en la fecha prometida. En nuestra experiencia, la mayoría de los proyectos no son tan afortunados. En pocas palabras: en la medida de lo posible, resuelva sus problemas desde el principio, en la fase de diseño. Asegúrese de poner sobre la mesa absolutamente todos los requerimientos.
Aquí estamos hablando de un nivel muy general. Para el proyecto del ejemplo que presentamos anteriormente, se requieren un gran número de requerimientos y sesiones de diseño.
- Cuando un agente transfiera la llamada a un supervisor, tiene que ir seguida automáticamente de un mensaje en pantalla (“screen pop”)
- 60% de las llamadas deben terminar en el sistema IVR
- Si el IVR y el sistema CTI no están funcionando, las llamadas de todos modos tienen que ser canalizadas a un agente
- Las oportunidades de ventas identificadas en el sistema de audiorespuesta deben disparar un “screenpop” en la terminal del agente
- Los agentes deben tener la capacidad para poner a grabar una llamada
- No debe hacerse necesario modificar elementos de las pantallas de CRM
- Si el sistema CRM no funciona o está demasiado lento, los agentes de todos modos deben tener acceso a la información que ingresó el cliente
- Una sola tabla de reporte debe poder mostrar la siguiente información: actividad del sistema IVR para una llamada, asignación por habilidades, tiempo que pasó el agente en esa llamada, agente asignado a la llamada, trabajo posterior a la llamada
- Todas las ventas deben tener una impresión de voz
- Todas las llamadas deben terminar con un código de motivo ingresado por el agente
Una cosa que usted observará en relación con esta lista de requerimientos es que son sumamente diversos. Provienen de diferentes partes del call center que representan las necesidades de diferentes grupos.
Usted no va a obtener todos sus requerimientos en un solo lugar. Asegúrese de consultar a todas las personas que pudieran tener requerimientos o a aquellas que pudieran estar al tanto de restricciones o limitantes que incidan sobre su capacidad para satisfacer los requerimientos.
Es probable que se tope con requerimientos que se contraponen unos a otros. En la lista anterior vemos que los agentes siempre deben seleccionar un código de motivo de la llamada antes de poder tomar otro contacto. Antes de eso tenemos un segundo requerimiento que dice que no debe se debe hacer necesario modificar las pantallas del sistema CRM. Al parecer el grupo de sistemas ha trabajado mucho para lograr que el sistema de CRM funcione exactamente cómo quieren y consideran que la aplicación debe mantenerse congelada durante los próximos meses. Entonces llega un requerimiento que les obliga a abrir el código fuente y quizá hasta incluir por ahí algún botón nuevo. En este caso se trata de un requerimiento proveniente de las operaciones del call center que se contrapone a una restricción por parte del área de TI. La única manera de resolver este tipo de conflictos sin tener que acudir a instancias superiores es congregar bajo el mismo techo a todos los interesados desde el principio. Ponga los requerimientos sobre la mesa, ventílelos. Utilice un poco de psicología -- si alguien empieza a plantar obstáculos, déjelo hablar e involúcrelo en la solución. Mantenga a la gente concentrada en la meta en común. Recuérdeles lo valioso que es lo que se está haciendo.
Documentos y especificaciones
Durante esta fase, usted va a generar dos tipos de documentación: documentos de requerimientos y especificaciones funcionales. La especificación funcional es el documento de diseño resultante de recopilar sus requerimientos y elaborar su diseño (y, una vez más, estamos hablando de un documento compuesto por muchos elementos, muchas especificaciones diferentes juntas en una misma carpeta).
Ahora, como todo veterano del mundo corporativo sabe, un documento puede cobrar vida y convertirse en un fin en sí mismo. En ningún otro caso se manifiesta este fenómeno con mayor claridad que aquí. Hemos tomado parte en más de un proyecto en el que la elaboración y aprobación de una especificación se convirtió, en sí misma, en un proyecto existente casi en un universo paralelo. Luego, una vez que la especificación quedó concluida y aprobada, nunca más se volvió a hacer referencia a ella, casi como si desapareciese de la faz de la Tierra una vez que se termina de elaborar. La declaración de requerimientos y la especificación funcional constituyen un contrato entre el usuario final y la gente que va a realizar el trabajo: juntos, están afirmando “esto es lo que pretendemos lograr y así es como lo vamos a lograr.” Para ello, estos documentos deben ser exhaustivos y exactos. Pero no deben ser un fin en sí mismos. Su especificación funcional debe ser el resultado de su diseño, y no la razón por la que se hizo.
En el peor de los casos, la especificación se convierte en una especie de campo de batalla
El proveedor redacta su visión de cómo será el producto final y cómo va a funcionar. Usted, como cliente, lee ese documento y desarrolla su propio punto de vista. Luego lo modifica para alinearlo mejor con su propia visión y se lo devuelve al proveedor. Todo mundo afirma que está de acuerdo, todo mundo firma, y luego el proveedor va e implementa su propia visión de lo plasmado en ese documento definitivo, con toda una serie de supuestos y sesgos. Pero usted sabe que eso va a ocurrir, y por lo tanto se muestra renuente a firmarlo; “mejor vamos a afinarlo otro poquito, y otro poquito”. Como usted lo sabe, lo firma, y se convierte en ley.
Cuando usted quiere que el sistema haga algo que pensó que estaba cubierto, el proveedor va a señalar la especificación y a decir: “¿Ya ve? Eso no está”, o “¿Ya ve? Eso fue lo que hicimos; lo que pasa es que no es exactamente como usted pensaba que iba a ser”. Así que ¡nadie quiere firmar el documento! Lograrlo puede llevarse meses -- meses de tiempo del proyecto desperdiciados para que todo mundo pueda cubrirse debidamente el trasero, pero mientras tanto no está ocurriendo nada productivo en aras del proyecto. Créame: el proveedor no gana dinero si se la pasa haciendo revisiones a las especificaciones, y usted tampoco logra que se ejecute el proyecto.
La solución a todos estos problemas es también una práctica muy recomendable de ingeniería. Simplifique la especificación y el proceso de aprobación y luego trabaje rápidamente para elaborar una aplicación prototipo que pueda ser susceptible de revisión, crítica constructiva y mejora. Déle retroalimentación al proveedor. “Mueve este botón para acá; cambia esta lógica”. Por lo general hacer estos cambios no requiere grandes cantidades de trabajo si el proveedor entiende bien sus requerimientos de negocios e hizo su tarea antes de empezar. Este le permite a su equipo hacer aportaciones válidas sobre algo concreto. A la mayoría de nosotros no se nos da muy bien crear cosas a partir de la nada, pero sí tendemos a ser bastante buenos para señalar cómo mejorar aquello que podemos ver y con lo que podemos interactuar. Un prototipo le permite a su equipo ver lo que el sistema está haciendo y cómo va a funcionar, y aportar ideas válidas sobre cómo su negocio puede interactuar con él.
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
No hay comentarios:
Publicar un comentario
Importante es tu opinion: