La respuesta breve
Service Cloud no reduce por sí mismo los tiempos de respuesta, sino que aplica las configuraciones que se le proporcionan. Si no se ha definido qué constituye un Case, quién lo recibe y cuándo empieza a contabilizarse el tiempo, el sistema medirá con precisión un proceso indefinido. En consecuencia, las métricas podrían parecer mejores o peores de lo que son en realidad, sin una conexión directa con la calidad del servicio.
Cuatro decisiones clave determinan el resultado: la definición de un Case, el modelo de asignación, el reloj del SLA y la ubicación del conocimiento. El resto de la implementación (pantallas, canales, automatizaciones) se deriva de estas.
Decisión 1: Qué constituye un Case
Muchos centros de contacto abren un Case para cada interacción con el argumento de que "así se tienen datos". El resultado es el opuesto: miles de registros que se cierran en un minuto inflan el volumen, mejoran artificialmente el tiempo medio de resolución y ocultan las solicitudes que realmente se estancan.
Una definición efectiva distingue entre tres tipos:
| Tipo de interacción | ¿Se abre un Case? | Razón |
|---|---|---|
| Pregunta respondida en la llamada | No, se registra como Interacción | No requiere seguimiento ni compromiso |
| Solicitud que requiere acción o espera | Sí | Necesita seguimiento y SLA |
| Incidencia que podría repetirse | Sí, con clasificación de causa | Requiere análisis de tendencias |
Decisión 2: Quién recibe la solicitud
El fallo común es el Routing basado únicamente en el departamento, lo que crea una gran cola de la que los agentes "pescan" las solicitudes sencillas. Las solicitudes complejas envejecen en la parte inferior de la cola hasta que alguien las escala telefónicamente, y todo el mecanismo de SLA se convierte en una simulación.
Un modelo de asignación adecuado define tres dimensiones: la habilidad requerida, la capacidad real del agente (no el número de Cases, sino su 'peso') y las reglas de escalada basadas en tiempo. El Omni-Channel Routing soporta las tres, pero solo si se han definido habilidades reales. Definir "habilidad: soporte" para todos los agentes es equivalente a no definir nada.
Una descripción completa de la asignación omnicanal se encuentra en Omnichannel y SLA en Service Cloud.
Decisión 3: Cuándo corre el reloj
Esta es la decisión que más organizaciones omiten, y es la que determina la fiabilidad de las métricas. Preguntas que deben tener una respuesta documentada:
- ¿Cuándo se inicia el reloj? – ¿En el momento de recibir la solicitud o al inicio del siguiente horario laboral? Los Business Hours deben definirse para cada zona horaria relevante.
- ¿Cuándo se detiene? – Un Case en espera de respuesta del cliente debe pausar el contador; de lo contrario, el centro de contacto es penalizado por la lentitud del cliente.
- ¿Qué se mide exactamente? – Tiempo de primera respuesta, tiempo de resolución, o ambos con objetivos separados para cada nivel de urgencia.
- ¿Qué sucede antes de una desviación? – Un Milestone que genera una alerta al 80% del tiempo es más valioso que un informe mensual de desviaciones.
Los Entitlements y Milestones son el mecanismo que implementa estas cuatro preguntas. Activarlos sin una decisión escrita previa generará alertas que se ignorarán en dos semanas.
Decisión 4: Dónde se encuentra el conocimiento
La Knowledge Base no es un proyecto separado, sino una condición para reducir la carga de trabajo. El fallo habitual: los artículos se escriben en el lanzamiento, nadie los mantiene y, en seis meses, los agentes vuelven a preguntar en un chat interno.
Lo que funciona: un ciclo de vida definido para cada artículo: Owner, fecha de revisión y métrica de uso. Un Case cerrado sin un artículo vinculado y que aparece cinco veces en el mismo trimestre es un disparador automático para la creación de un artículo. Para profundizar en el tema, consulte Gestión del conocimiento en Salesforce.
Métricas operativas
| Métrica | Definición | Umbral de revisión |
|---|---|---|
| First response time | Hasta el primer contacto humano | Desviación superior al 10% de los Cases |
| First contact resolution | Cerrado sin escalada | Por debajo del 60% |
| Reopen rate | Case reabierto en 7 días | Superior al 8% |
| Backlog aging | Cases abiertos por encima del SLA | Tendencia semanal al alza |
| Knowledge attach rate | Cases con artículo vinculado | Por debajo del 30% |
El "Reopen rate" es la métrica más importante y generalmente la más descuidada: expone cierres prematuros realizados para cumplir con el objetivo de tiempo.
Orden de trabajo recomendado
Primera fase: Definición de Case, uno o dos canales, Routing básico, SLA para un nivel de urgencia y diez artículos de Knowledge para las preguntas frecuentes. Segunda fase: Canales adicionales, habilidades, Entitlements completos, Self-Service. Implementar todo a la vez genera un centro de contacto que se enfrenta a cambios de proceso, cambios de herramienta y cambios de medición en la misma semana, y generalmente vuelve a las soluciones parciales.
Resumen
Una implementación exitosa de Service Cloud se mide por una pregunta: ¿Puede el director del centro de contacto mostrar, desde el sistema y sin hojas de cálculo auxiliares, dónde se encuentran las solicitudes que exceden el tiempo y por qué? Si las cuatro decisiones están cerradas, la respuesta existe. Si no, se tendrá un nuevo sistema, pero el mismo centro de contacto.