La respuesta breve
Omni-Channel no es un mecanismo de distribución, sino un modelo de capacidad. En cada momento, este modelo se plantea una única pregunta: ¿cuánto trabajo puede asumir este agente ahora? Si la respuesta a esta pregunta es incorrecta —porque el chat y el correo electrónico recibieron el mismo peso—, el enrutamiento funcionará exactamente como se configuró y perjudicará el servicio.
Por lo tanto, la secuencia de trabajo es la siguiente: primero el modelo de capacidad y los pesos, luego las habilidades, después los Entitlements y los Milestones, y solo al final las automatizaciones de escalamiento.
Modelo de capacidad: el punto que lo determina todo
Omni-Channel asigna a cada agente una "cuota de trabajo" (Capacity) y a cada elemento de trabajo un peso. Un centro que define un peso uniforme para todos los canales obtiene uno de dos resultados: los agentes de chat se colapsan bajo la carga, o los agentes que gestionan correos electrónicos parecen ocupados mientras están disponibles.
Un punto de partida razonable para la calibración:
| Tipo de trabajo | Característica | Peso relativo recomendado |
|---|---|---|
| Llamada telefónica | Completamente sincrónica | Ocupa toda la capacidad |
| Chat en vivo | Sincrónico con pausas cortas | Alto, generalmente 2-3 en paralelo como máximo |
| Correo electrónico / formulario | Asincrónico | Bajo |
| Caso en espera del cliente | Inactivo | Cero - debe liberar capacidad |
La última línea es la más común en errores: un Case que espera por el cliente y que sigue ocupando capacidad hace que los agentes parezcan ocupados cuando no tienen trabajo activo.
Habilidades: menos es más
El Skills-Based Routing suena como una mejora obvia, pero en la práctica es la fuente más común de solicitudes atascadas. Cuantas más habilidades se añaden, mayor es la probabilidad de que no haya un agente disponible que cumpla con todas ellas.
Tres reglas que lo impiden: definir habilidades solo cuando su ausencia impide realmente el tratamiento; definir para cada requisito un nivel de Fallback que se activa después de un tiempo de espera definido; y revisar mensualmente cuántas solicitudes se asignaron a través de Fallback —un porcentaje alto indica que el modelo no coincide con la dotación del centro de contacto.
Entitlements y Milestones: del compromiso al mecanismo
Un SLA que solo aparece en un informe es una notificación a posteriori. Entitlements y Milestones lo convierten en un mecanismo activo:
- Entitlement define qué cliente tiene derecho a qué nivel de servicio —normalmente una configuración predeterminada y algunas excepciones contractuales.
- Milestone define los puntos de tiempo medidos: primera respuesta, actualización periódica, resolución.
- Business Hours determinan cuándo corre el reloj, y deben configurarse para cada zona horaria y cada canal por separado.
- Stopped Time congela el contador en espera del cliente —sin esto, las métricas penalizan al centro de contacto por el comportamiento del cliente.
- Acciones de Milestone generan una alerta y un escalamiento antes de la infracción, generalmente alrededor del 75-80% del tiempo.
La regla fundamental: si la primera alerta llega después de la infracción, el mecanismo mide, pero no gestiona.
Las decisiones fundamentales sobre la definición de Case y el reloj del SLA están detalladas en Implementación de Service Cloud.
¿Cómo saber si el modelo no funciona?
Cinco señales tempranas, antes de que las métricas mensuales revelen un problema:
- Alto porcentaje de asignaciones a través de Fallback —las habilidades no coinciden con la dotación.
- Solicitudes en la cola de asignación que superan unos pocos minutos —falta de capacidad o una regla de Overflow inexistente.
- Agentes que informan de una sobrecarga mientras el informe de capacidad muestra disponibilidad —pesos incorrectos.
- Concentración de infracciones de SLA a una hora fija del día —problema de personal, no de enrutamiento.
- Alta tasa de solicitudes asignadas y abandonadas inmediatamente —los agentes rechazan el trabajo que no les conviene.
Medición continua
| Métrica | Qué revela |
|---|---|
| Tiempo en la cola de asignación | Si el modelo encuentra un agente a tiempo |
| Utilización promedio de la capacidad | Si los pesos son realistas |
| Infracciones por Milestone | Dónde exactamente se rompe el SLA |
| Tasa de escalamientos evitados | Si la alerta temprana funciona |
| Brechas en las infracciones entre canales | Si un canal específico se ve perjudicado en el enrutamiento |
Orden de implementación
Se activa un canal con un único Entitlement y sin habilidades, se calibran los pesos con datos reales durante dos semanas, y solo entonces se añade un segundo canal y habilidades. Una implementación completa en un solo día impide la capacidad de identificar qué componente causó la sobrecarga, y generalmente termina con la desactivación del enrutamiento y el retorno a las colas manuales.
Resumen
Omni-Channel es un modelo de capacidad y no de distribución, y el SLA es un mecanismo de alerta, no un informe. Estos dos principios determinan si el centro de contacto funcionará según el sistema o encontrará formas de eludirlo, y la diferencia se revela ya en la primera semana de operación.