Si buscamos una capacidad clave de cualquier herramienta de gestión y relación con clientes, posiblemente podamos decir que algo fundamental es medir. Es decir, la posibilidad de obtener métricas sobre cualquier cualquier acción, proceso o evento que ocurra dentro de nuestra empresa.
Esto no es discutible, necesitamos medir para poder comparar la situación actual con el histórico, poder realizar una previsión futura, controlar los niveles de servicio, detectar puntos de mejora, saturación, bloqueos, trazabilidad de las acciones, control por cuestiones contractuales o económicas, control por cuestiones de calidad, motivación por consecución de objetivos, etc. Tras comentar todos estos posibles motivos, en general, podríamos decir que necesitamos diferentes niveles de información dependiendo del usuario/departamento que requiere de esta información para realizar su trabajo del día a día.
Cuando se está evaluando las soluciones Contact Center (CC) o los Customer Relationship Management (CRM) desde el punto de vista de tecnología en relación a la capacidad de medir, estos son los factores más importantes que suelen solicitarse, y que deberían entrar en el análisis comparativo entre distintas soluciones tecnológicas:
- Fiabilidad y consistencia: que la solución sea consistente y los datos reflejen la realidad en todo momento, independientemente a que consulte el dato en tiempo real o consulte el dato histórico pasados horas, días o meses.
- Inmediatez: normalmente se desea que la información esté disponible casi al instante, con un periodo de refresco mínimo. De hecho si hablamos del estado de los agentes o las colas de espera, queremos el dato en tiempo real con un refresco de 3 segundos o menos. Y para consolidación/sumarización de datos normalmente aceptamos un pequeño retardo, pero a tod@s nos gusta más si éste no existe.
- Flexibilidad al cambio: es deseable que los cambios rutinarios o evolutivos que se puedan producir en los servicios por incorporar nuevos grupos, cambiar los nombres de estos, etc., se puedan adaptar fácilmente sin provocar un rediseño de todo el enrutamiento de los servicios ni perder información histórica del reporting.
- Adjuntar información: cada vez es más común que se pueda asociar información a cualquier interacción y que esta información esté disponible mientras la interacción esté abierta o incluso después de cerrarla. Al adjuntar información se puede alimentar el reporting de datos adicionales del cliente como número de contrato, líneas o instalaciones, estados del cliente, segmentaciones, motivos de interacción, etc. que se podrá explotar por las diferentes aplicaciones mientras se resuelve la interacción o para realizar búsquedas posteriores por algunos de los valores que se adjuntan.
- Integración con terceras soluciones: la facilidad de integrarse con herramientas de Business Intelligence o Big Data corporativas de la compañía es un factor relevante si se desea realizar un análisis que cruce datos de negocio de diversas fuentes de información de los aplicativos para obtener KPIs, tendencias o impactos que con informes individuales es prácticamente imposible analizar.
- Granularidad de los datos: aunque no siempre se requiere llegar al detalle de registro de cada acción que ocurre por interacción o por agente, también es importante disponer de una granularidad de los datos que nos muestren información sumarizada e información al detalle si es preciso.
- Cálculos y cruce de datos: es casi imprescindible que los reportes permitan crear sus propios datos calculados con fórmulas sobre diferentes campos y que permita cruzar datos de las diferentes tablas para no limitarse a los reportes estándar.
- Perfiles y roles con permisos: un modelo de permisos basado en roles y perfiles es necesario para que los diferentes usuarios que deben acceder al sistema de reporting tengan acceso a la información que deban utilizar según su ámbito o funciones.
- Modelo de datos documentado: una buena documentación del modelo de datos y el significado de cada uno de los campos que se pueden utilizar, ayuda a comprender correctamente los resultados obtenidos en los informes.
[bctt tweet=»No definir en la fase de diseño del proyecto el modelo de reporting, puede ser un error muy grave» via=»no»]
No profundizamos a nivel técnico a pesar de poder existir otras necesidades importantes que se podrán tener en cuenta, tales como infraestructuras, tipo de gestor de base de datos, rendimiento, copias de seguridad, etc. Las funcionalidades enumeradas en el listado superior son realmente importantes, sin embargo, habitualmente cuando se afrontan proyectos de mejora o transformación, las necesidades del modelo de reporting se dejan para una fase final, o incluso se pretende abordar tras la primera puesta en producción. Si los objetivos de reporting no están perfectamente claros y se tienen en cuenta desde el diseño de cualquier propuesta, puede ser un error grave, y decimos esto porque en muchas ocasiones las herramientas no son tan flexibles una vez que se ha decidido configurarlas de una forma concreta, y por supuesto, cambiar el diseño vuelve a suponer un proyecto de gran importancia.
En la continuación de este artículo explicaré cuales suelen ser las necesidades más habituales desde el punto de vista de los usuarios que utilizan el reporting en tiempo real o histórico para ofrecer una visión más completa.
