Cuando dos sucursales ‘se invierten’: el patrón típico (y por qué no es performance)
Hay un patrón que se repite demasiado: abrís el dashboard semanal y ves que Sucursal Norte se desploma mientras Sucursal Centro “vuela”… como si alguien hubiera cambiado equipos de camiseta. Misma semana, mismos productos, mismos turnos, mismos feriados. Y sin embargo, el ranking parece “invertirse”.
En la mayoría de los casos, eso no es performance. Es atribución por sucursal conversaciones funcionando como una manta corta: ajustás una regla (identidad, ventana, crédito) y el mérito “migra” de sucursal sin que el cliente haya vivido nada distinto.
Para que todos discutan lo mismo (y no sensaciones), tres definiciones que suenan obvias hasta que faltan:
Cliente: la persona (idealmente una sola identidad, aunque cambie de canal).
Conversación: el hilo en un canal (puede haber varias por cliente).
Atribución: la regla que decide a qué sucursal le contás esa conversación, ese cierre o esa venta.
El ejemplo que explica la mayoría de las discusiones internas:
Un cliente escribe por WhatsApp a Norte a las 09:12. Queda “En curso”, falta stock.
A las 18:05 recontacta, pero entra por Centro (reenviado, otro botón, el “WhatsApp de la web”, da igual). Centro confirma stock y marca Resuelto.
Con último toque, Centro se lleva el cierre (y si además contás “conversaciones” sin agrupar recontactos, se lleva también actividad). Con una ventana de recontacto razonable (agrupás <24–72h) y atribuís el caso al primer contacto del caso, el cierre vuelve a Norte. Si atribuís a quien resolvió, Centro vuelve a “ganar”… pero ahora entendés el por qué y podés decidir si ese incentivo te sirve o te destruye la cooperación.
Esto es donde te quemas de verdad: movés agentes, recortás presupuesto o “retás” a una sucursal cuando, en realidad, estabas gestionando un espejo mal puesto.
Regla simple para arrancar sin pelearte con el mundo: antes de discutir “Norte vs Centro”, mirá el total. Si la demanda total (clientes únicos o casos) está estable y lo que cambia es el reparto del crédito, arrancá por atribución. Si el total sube o baja fuerte, recién ahí sospechá de operación.
Qué se rompe primero: unidad de conteo y reglas que crean ‘oposición’ artificial
Cuando dos sucursales parecen “opuestas” (una sube, la otra baja, casi en espejo), lo primero que suele romperse no es la atención. Es la unidad de conteo y la cadena que viene después: identidad → agrupación → atribución.
En multicanal, si esas piezas no están fijadas, el tablero puede inventar una competencia artificial. Es como discutir quién cocina mejor cuando alguien cambió la balanza a “libras” y nadie avisó.
Unidad de conteo: conversación, caso o ticket, cliente, oportunidad
Una conversación es un registro. Un caso es un problema. Un cliente es una persona. Si mezclás esos niveles, terminás comparando manzanas con comprobantes.
Conversaciones miden carga (sirven para capacidad, picos, saturación). Son peligrosas para “ranking” si no deduplicás.
Casos/tickets (agrupando recontactos) miden problemas: se acercan más a calidad y resolución.
Clientes únicos miden personas: te protegen del “crecimiento falso” por duplicación.
Ancla numérica típica: una semana contás 420 conversaciones en Norte y 380 en Centro. La semana siguiente activás agrupación de recontactos a <72h y hablás de “casos”: te quedan 260 vs 255. Si alguien interpreta eso como “cayó la productividad”, estás midiendo otra cosa. No cayeron; cambiaste de timbres a entregas.
Esto es donde te quemas: usar “conversaciones” como KPI de desempeño sin dedupe es invitar a optimizar lo que se cuenta, no lo que importa.
Identidad: cómo los duplicados disparan doble conteo
El segundo quiebre es más silencioso: un mismo cliente aparece con múltiples IDs. No hace falta un sistema “roto”; alcanza con WhatsApp + llamada + email, dos números, o un formulario que crea un lead nuevo sin vincular.
Señales operativas que delatan duplicación y te explican inversiones raras:
- Suben conversaciones, pero clientes únicos queda plano.
- Sube el ratio Conversaciones / Cliente único de una semana a otra.
- Crece el % de conversaciones “sin contacto asociado” o “nuevo” sin motivo.
- Aumentan transferencias y también aumentan “cierres” en la sucursal receptora.
- Mucho recontacto en <24–72h por el mismo motivo.
El error humano típico es culpar a personas (“Centro atiende mejor”) cuando cambió una circunstancia invisible: un número nuevo, un ajuste de routing, o una integración que empezó a duplicar contactos. Es el sesgo de atribución en acción: juzgar gente y no contexto. Si querés el marco conceptual: [1] y una bajada al trabajo cotidiano: [2]
Atribución: último toque vs primer toque vs “quien resolvió”
Acá nace la “oposición” artificial: la misma realidad se puede contar con reglas distintas, y cada una empuja comportamientos.
Último toque: gana quien cierra. Simple. Falla cuando hay transferencias/recontactos: premia al que recibe la pelota cerca del arco.
Primer toque: gana quien inicia. Útil para cobertura/captación. Riesgo: incentiva retener casos para no perder crédito.
Quien resolvió: gana quien deja evidencia de cierre. Alinea con resolución. Riesgo: desincentiva triage o escalación si “perder crédito” duele.
Ejemplo numérico (para que deje de ser discusión filosófica): hay 100 cierres reales. 30 casos empiezan en Norte y terminan en Centro por transferencia. Con último toque: Norte 35, Centro 65. Con primer toque del caso: Norte 60, Centro 40. La operación no cambió. Cambió la historia.
Ventanas: de recontacto vs de atribución, no son lo mismo
Si no lo escribís, alguien lo mezcla.
Ventana de recontacto (agrupar): cuándo dos contactos son el mismo caso. “Si recontacta en <72h por el mismo motivo, se agrupa”.
Ventana de atribución (asignar): hasta cuándo un cierre se puede atribuir a una interacción previa. “Atribuimos el cierre a contactos de los últimos 7 días”.
Ancla operativa con tres conversaciones en 48h:
Mar 10:00 WhatsApp a Norte (consulta precio). Mar 16:30 llamada a Centro (financiación). Mié 09:20 WhatsApp a Centro (confirma) y cierra.
Sin agrupar + último toque: Centro “gana” más actividad y el cierre. Agrupando <48–72h como un caso + primer toque: Norte gana el caso y el cierre.
Reglas de decisión que suelen evitar incendios:
- Soporte/posventa con insistencia normal: 72h para agrupar suele bajar espuma sin esconder problemas.
- Venta muy transaccional: 24h puede bastar.
- Para cierres/ventas con asincronía real (stock, aprobaciones, backoffice): rara vez bajes de 7 días como ventana de atribución. Si lo bajás a 24h, preparate para “magia” en el ranking.
Monitoreo mínimo para detectar que estás fabricando oposición: ratio Conversaciones/Cliente único, % cierres con transferencia en la hora previa, recontacto 24h/72h y tendencia de transferencias. Si dos de esos cuatro se mueven a la vez, no discutas “quién atendió peor”: discutí definiciones.
Workflow de diagnóstico (antes de decidir): del síntoma al responsable correcto
| Estrategia de asignación | Mejor para | Ventajas | Riesgos | Recomendado cuando |
|---|---|---|---|---|
| 5. Cómo redactar un ‘acuerdo de definiciones’ entre soporte y reporting | Alinear interpretación de métricas entre equipos. | Reduce conflictos. mejora confianza en datos. | Difícil de mantener actualizado. resistencia al cambio. | Discrepancias recurrentes en informes o atribuciones. |
| 1. Definir unidad de conteo | Evitar duplicidad en métricas clave (ej. 'cliente', 'conversación'). | Claridad de datos. base sólida para atribución. | Ignorar matices si la definición es rígida. | Inicio de análisis de atribución o conversación. |
| 2. Cómo construir una línea de tiempo por cliente — sin herramientas específicas | Visualizar el recorrido completo del cliente y puntos de contacto. | Identifica patrones y secuencias de interacción. | Consumo de tiempo. datos incompletos si no hay registro. | Sospecha de error de atribución. necesidad de entender el 'por qué'. |
| 3. Cómo cuantificar ‘sensibilidad’ del tablero — delta por cambio de regla | Entender el impacto de cada regla de atribución en resultados. | Demuestra el efecto de las reglas. justifica cambios. | Interpretación errónea sin considerar otras variables. | Propuesta de cambio de regla. necesidad de validar impacto. |
| 4. Criterio de ‘alto riesgo de inversión’ — p.ej., recontacto en <24–72h + cambio de canal + transferencia | Identificar interacciones que requieren atención inmediata. | Prioriza acciones. reduce pérdida de clientes. | Falsos positivos si los criterios son amplios. | Optimizar respuesta a eventos críticos del cliente. |
| 6. Muestreo recomendado — por ejemplo: 20–50 clientes que explican el 60–80% del cambio | Validar hipótesis de atribución con subconjunto representativo. | Eficiencia en análisis. resultados rápidos. | Sesgo si la muestra no es representativa. | Validación rápida antes de implementar cambios a gran escala. |
La tabla de arriba no es “metodología”; es un mapa para ubicar qué se está moviendo: conteo, recorrido, sensibilidad o definiciones. Si no pasás por ese mapa, terminás asignando culpas a quien no puede arreglar el problema.
Elegí el evento que realmente importa (y que se pueda auditar)
Acá se van días. Porque si el “resultado” es discutible, todo lo demás es fe.
Elegí un evento final y dejalo escrito: “Resuelto” (bien definido), “Venta cobrada”, “Cita asistida”. Lo importante no es el nombre; es que tenga evidencia: estado y timestamp. Si tenés “cerrados” sin nota ni motivo, ya encontraste un modo de fallo: cierres administrativos que inflan a una sucursal.
Regla de decisión: si no pueden acordar un evento verificable, todavía no estás listo para incentivos por sucursal. Operá con métricas de flujo (SLA, backlog) mientras cerrás definiciones.
Reconstruí recorridos con una muestra chica (lo suficientemente chica como para hacerla)
No hace falta auditar todo. Hace falta un subconjunto que explique el cambio.
Muestreo recomendado: 20–50 clientes que expliquen el 60–80% del movimiento del ranking (los que concentran transferencias, recontactos o valor).
Construí una mini línea de tiempo por cliente con cinco campos: fecha/hora, canal, sucursal/cola, estado, motivo (de etiqueta o nota). Con eso alcanza para ver el patrón.
Tres casos reales (típicos) que suelen aparecer cuando el ranking “se invierte”:
Cliente 1: Lun 09:10 Norte WhatsApp “stock” (Abierto) → Lun 17:40 transferido → Lun 18:05 Centro (Resuelto). Último toque: Centro. Primer toque del caso: Norte.
Cliente 2: Mié 15:00 Norte llamada “financiación” (Abierto) → 15:20 Centro WhatsApp pero con nuevo contacto/ID → Jue 09:00 Centro (Resuelto). Señal: dos IDs para la misma persona.
Cliente 3: Jue 09:40 Norte WhatsApp “devolución” (Abierto) → 10:05 transferido → 10:07 Centro (Resuelto con duración mínima). Señal: cierre casi instantáneo post-transferencia.
Ese tercer patrón es un acelerador de guerra interna: parece eficiencia, pero muchas veces es “cierro para limpiar cola”.
Medí la “sensibilidad” del tablero (si cambia demasiado, no lo uses para decisiones duras)
La pregunta no es “¿cuál regla es la verdadera?”. Es: “si toco una sola cosa, ¿cuánto se mueve la historia?”
En la muestra, probá variaciones pequeñas: ventana de recontacto 24h vs 72h, atribución último toque vs primer toque vs quien resolvió, y un dedupe mínimo cuando la duplicación es obvia.
Regla de decisión práctica: si con solo cambiar una ventana o una regla se mueve más de 10–15% de cierres entre sucursales en la muestra, tu tablero es frágil. En ese estado, usarlo para mover headcount, incentivos o presupuesto es jugar Jenga sobre la mesa de operaciones.
Poné nombre a la causa (así el responsable es el correcto)
Cuando el cambio ya se ve en casos reales, etiquetá la causa con categorías simples:
Duplicado de identidad (dueño: datos/integraciones).
Recontacto corto contado como “nuevo” (dueño: reporting/definiciones).
Transferencia legítima (dueño: operación; quizá está bien, pero hay que medirla).
Transferencia por mal routing (dueño: operación/routing).
Cierre administrativo (dueño: operación + definición de evento).
Esto se sostiene con anclas aburridas pero decisivas: motivo de transferencia, estado “transferido”, motivo/etiqueta y timestamp del cierre.
Cerrá con un acuerdo de definiciones (una página que te ahorra meses)
Un acuerdo de definiciones (una página, fecha y dueño) es el contrato social entre soporte y reporting. Evita el “alguien tocó una ventana para que cuadre” y el dashboard volvió a invertir sucursales.
Mínimos que conviene fijar: qué es cliente y su identificador, qué es conversación vs caso (ventana 24/72), cuál es el evento final y su evidencia, qué regla atribuye por sucursal, y qué métricas se consideran solo de capacidad (conversaciones) y no de mérito.
Qué conviene medir (y en qué sí confiar) mientras corriges atribución por sucursal
Mientras arreglás atribución por sucursal conversaciones, no podés quedarte sin tablero: el backlog no espera. La jugada inteligente es operar con métricas estables (poco sensibles a identidades/ventanas) y usar las sensibles para diagnóstico, con guantes.
Métricas estables para operar semana a semana: backlog abierto, tiempo a primera respuesta por canal/franja, tiempo a resolución por caso (si “Resuelto” está bien definido), recontacto 24h/72h por motivo, % transferencias con motivo y cumplimiento de SLA. Si tenés CSAT/NPS, atalo al evento real de resolución, no al “cierre de conversación” automático.
Métricas sensibles (útiles, pero no para repartir culpas mientras el modelo esté frágil): conversaciones por sucursal, cierres por conversación, ventas por último toque y win rate si las oportunidades se duplican o saltan de canal.
Dos anclas para no perderte: mirá siempre el ratio Conversaciones / Cliente único y el % de cierres con transferencia en la hora previa. Si esas dos se mueven, interpretá el resto con cautela.
Reportes paralelos temporales (para corregir sin incendiar incentivos)
Durante 2–4 semanas, corré dos reglas en paralelo y decilo explícito:
Regla A: último toque (rápida, sesgada hacia quien recibe el final).
Regla B: quien resolvió o primer toque del caso (más alineada a resolución o captación).
El objetivo no es elegir “la que deja mejor a mi sucursal”. Es medir sensibilidad. Si el gap A vs B te cambia el ranking y coincide con picos de transferencias o recontactos, congelá decisiones irreversibles hasta estabilizar identidad + ventana.
Ejemplo operativo: una sucursal “pierde” conversaciones pero “gana” resolución
Trigger: Norte cae de 500 a 360 conversaciones (-28%) y Centro sube de 420 a 560 (+33%). Se arma el “¿qué hicieron mal?”.
Lectura equivocada: Norte se durmió.
Lectura correcta: por dos semanas mirás backlog, primera respuesta, recontacto 72h, transferencias y tiempo a resolución por caso. Resultado típico: Norte baja conversaciones porque se agrupan recontactos y mejora routing; baja backlog y mejora resolución. Centro sube conversaciones porque recibe más transferencias y porque último toque lo premia. El tablero se “invirtió” pero la operación mejoró.
Lectura correcta de contradicciones (dos escenarios comunes)
Escenario 1: sube recontacto, bajan conversaciones. Suele ser cambio de ventana/dedupe: se registran menos hilos, pero el recontacto por caso sube. Ahí el foco no es volumen: es motivo (stock, garantía, devolución) y tiempo a resolución.
Escenario 2: suben cierres, pero CSAT cae. Modo de fallo típico: cierres administrativos (duración mínima), muchas veces después de transferencias. Se ve con reaperturas y “cierres instantáneos”. La corrección no es retar: es endurecer la definición del evento (nota + motivo) y usar reapertura como freno natural al maquillaje.
Tradeoff real: o seguís mirando “conversaciones por sucursal” porque es fácil (y te empuja a optimizar conteo), o operás con casos + recontacto + backlog + SLA mientras arreglás identidad/atribución (menos glamoroso, mucho más estable). Si tu objetivo es no romper la operación, la segunda opción casi siempre gana.
Tradeoffs reales: reglas de atribución por sucursal y cuándo elegir cada una
No es filosofía: son incentivos. Cada regla crea comportamiento; la clave es elegir la que más se alinee al objetivo y menos daño colateral meta.
Último toque: cuándo sirve y cuándo castiga al que inicia bien
Sirve cuando el flujo es lineal y el último contacto decide el cierre.
Falla con transferencias/recontactos: convierte a la sucursal receptora en “estrella” y dispara política interna (“me están robando cierres”) aunque nadie robe nada. Si encima aparecen cierres de duración mínima, peor: el tablero premia el trámite.
Primer toque: cuándo sirve y cuándo premia captura sin resolver
Sirve para cobertura territorial y presupuestos de captación: responde “quién generó demanda”.
Riesgo real: retener casos para no perder crédito, incluso cuando transferir es lo correcto. Si tu operación requiere escalaciones, esta regla necesita contrapesos.
Atribución al que resuelve: pros y contras en transferencias y escalaciones
Pro: alinea con calidad de cierre.
Contra: puede desincentivar triage/escalación si perder crédito duele, especialmente en culturas con fricción entre sucursales.
Mitigación: protegé transferencias correctas con un motivo claro y medí routing como calidad. La transferencia no es un pecado; el routing malo sí.
Atribución compartida o ponderada: cuándo vale la complejidad
Vale cuando hay muchas transferencias legítimas, objetivos mixtos y madurez para sostener definiciones sin reabrir el debate cada mes.
Regla no escrita: si todavía discuten qué es un cliente o un caso, no empieces por modelos compartidos. Primero identidad y ventanas; después subís el nivel.
Regla recomendada por defecto y cuándo no usarla
Default pragmático: atribuír el evento a quien resolvió, y reportar primer toque en paralelo para captación. Reduce la caza del cierre y mantiene visibilidad de demanda.
No la uses si la resolución depende de un backoffice central y la sucursal solo ejecuta contacto. Ahí “resolver” está mal definido por diseño: separá etapas o dejá explícito qué cuenta como resolución.
Qué hacer con transferencias entre sucursales
Dos decisiones sanas: separar crédito de inicio vs resolución, y clasificar transferencias por motivo (cobertura/inventario/escalación vs error de enrutamiento). Eso te evita esconder un problema real detrás de una regla “que hace que quede lindo”.
Contexto (sin convertirlo en marketing): [3]
Modos de fallo comunes (y cómo detectarlos antes de que cambien decisiones)
Después de “arreglarlo”, se rompe por cambios pequeños: una integración nueva, etiquetas que dejan de usarse, una ventana “retocada”, un canal que empieza a crear duplicados. Por eso conviene tener un catálogo corto de fallos + pruebas rápidas.
Recontacto contado como nuevo: suben conversaciones, no mejora resolución. Prueba: en 30 registros, cuántos son el mismo cliente <72h por el mismo motivo.
Cambio de canal = nuevo cliente: clientes únicos crecen más rápido que cierres. Prueba: tomá 20 cierres y verificá 2+ identificadores por persona.
Transferencias contadas como cierres duplicados: dos sucursales se adjudican el mismo “cierre”. Prueba: cierres de duración mínima con transferencia cercana.
Ventanas distintas entre soporte y reporting: el reporte ejecutivo no coincide con operación. Prueba: ambos equipos miran el mismo cliente y explican su regla; si cuentan historias distintas, ya tenés el bug.
Monitoreo semanal mínimo para que no explote otra vez: ratio conversaciones/cliente único, % cierres de duración mínima, tasa de transferencias por sucursal, recontacto 72h por motivo y diferencia entre tableros en totales (cierres y clientes únicos). No es glamoroso; es lo que evita decisiones caras.
Premortem rápido: si el ranking se invierte y movés agentes basándote en último toque, podés quitar capacidad al triage, sobrecargar al receptor y terminar con más recontacto, más backlog y una guerra interna. Todo por una ventana mal elegida.
Se evita con disciplina simple: antes de tocar incentivos o presupuesto, ejecutá la muestra (20–50 clientes), medí sensibilidad y volvé al acuerdo de definiciones.
Y la brújula final: cuando tu tablero te hace pelearte con gente que trabaja bien, casi siempre el problema no es la gente. Es el tablero.
Fuentes
- thedecisionlab.com — thedecisionlab.com
- repensarelnegocio.com — repensarelnegocio.com
- dataslayer.ai — dataslayer.ai