Caso de producto · izzi telecom

Cada actividad, a quien sí puede atenderla

Un sistema que tomaba la carga de Inbound y la repartía entre los agentes del call center según las reglas de cada manager, con temporizador en tiempo real, estados del agente, bitácora y reportes.

en producción a nivel nacional hecho solo, de punta a punta
Así funcionaba

Asignar, atender, cerrar con ticket

Recreación ilustrativa con datos ficticios; no es el sistema original.

Nacionalagentes de call center en todo el país
Por managerreglas de asignación personalizadas
Tiempo realtemporizador visible en cada actividad
Solode punta a punta: datos, back, front y reportes

La necesidad

Repartir el trabajo con las reglas de cada manager

El equipo de Inbound depositaba las actividades por atender, y había que repartirlas entre los agentes del call center a nivel nacional. Cada manager tenía su propia forma de asignar, y necesitaba saber cuánto tardaba cada actividad y qué tan productivo era su equipo.

El problema

Mucho trabajo, muchas reglas y poca visibilidad

Para que la asignación fuera justa y medible había que resolver varias cosas a la vez:

La carga llegaba de otro equipoEn Excel o en una base de datos, y había que tomarla tal cual.
Cada manager tenía su lógicaPor ejemplo, que nadie atendiera más de tres actividades a la vez.
Saber quién estaba disponibleNo asignar trabajo a quien estaba en comida o indispuesto.
Medir y documentarCuánto tardaba cada actividad, la productividad y el uso de los estados.
Con pocos recursos de servidorLos recursos del servidor eran limitados y el sistema se volvía lento; tenía que responder bien con lo que había.

Cómo lo solucioné

Un sistema de asignación con reglas, tiempos y bitácora

Lo que construí

  1. Carga desde Excel o base de datos

    El sistema tomaba las actividades que Inbound depositaba, ya fuera en un Excel o directamente desde su base de datos.

  2. Asignación con lógica por manager

    Cada manager definía sus reglas, como un máximo de tres actividades activas por agente, y el sistema asignaba conforme a ellas.

  3. Temporizador en tiempo real y cierre con ticket

    Cada actividad mostraba su tiempo transcurrido en vivo; para cerrarla, el agente capturaba el número de ticket de la plataforma de atención.

  4. Estados del agente y bitácora

    El agente indicaba si estaba disponible, en comida o indispuesto, y solo recibía actividades estando disponible. Cada cambio de estado quedaba registrado para documentar malas prácticas.

  5. Reportes, gráficas y exportación

    Gráficas de productividad y exportación de la base de datos; los reportes se procesaban en segundo plano y se enviaban por correo para descargarlos.

Optimización con recursos limitados

Aquí aprendí mucho de optimización. Como el servidor tenía pocos recursos y había lentitud, trabajé en tres frentes hasta que dejó de haberla:

base de datosConsultas, índices y procedimientosOptimicé las consultas, agregué índices y moví lógica a procedimientos almacenados para que la base respondiera más rápido.
frontCSS y JavaScript minificadosArchivos más ligeros que cargaban más rápido en cada pantalla.
navegadorProcesamiento en el clienteParte del trabajo se movió al navegador de cada usuario para descargar al servidor.

Cómo se hizo

Lo desarrollé solo, de punta a punta: desde la conexión con los datos de Inbound hasta la interfaz de los agentes y los reportes de los managers.

LaravelPHPSQL ServerTailwind CSS

El resultado

El sistema se usó en producción con agentes de call center a nivel nacional: las actividades se repartían según las reglas de cada manager, cada cierre quedaba ligado a su ticket y los managers tenían tiempos, productividad y bitácora para tomar decisiones. Y, con la optimización, el sistema dejó de ser lento aun con los recursos limitados del servidor.

La recreación del sistema la hice con ayuda de Claude (IA) y usa datos ficticios; el sistema original lo desarrollé en izzi.

Conversemos en LinkedIn Volver al portafolio