Pregunta incómoda: ¿cuándo fue la última vez que tu pipeline de hiring estuvo realmente actualizado?
No “más o menos”. No “la mayoría de los candidatos”. Actualizado, fila por fila, columna por columna, con cada candidato exactamente donde tiene que estar. Si la respuesta es “nunca” o “hace tiempo”, no estás solo. Es la regla, no la excepción.
El kanban de hiring se vende como la solución al caos del proceso. En la práctica, la mayoría de los equipos lo abandona en seis semanas. Termina viviendo desactualizado, en paralelo a un Sheet, un Slack y la memoria de un recruiter.
Este post es sobre por qué pasa eso y qué hace el 20% que sí funciona.
Por qué un kanban de hiring falla
Hay un patrón clarísimo cuando un pipeline se abandona. No es por falta de capacitación ni por resistencia al cambio. Es porque el recruiter siente que actualizarlo es burocracia, no trabajo.
Si yo te pido que muevas una tarjeta de “Entrevista 1” a “Entrevista 2”, y a cambio no obtenés nada —ni un insight, ni un atajo, ni una alerta— el cerebro lo cataloga como tax administrativo. Y el tax administrativo es lo primero que se sacrifica cuando hay carga real.
El kanban roto tiene cinco síntomas:
- Stages que vienen “de fábrica”. Etapas genéricas que no matchean cómo la empresa realmente contrata.
- Movimientos manuales sin valor agregado. Mover una tarjeta no aporta nada visible.
- Ausencia de información en la card. El recruiter tiene que hacer click para saber quién es ese candidato.
- Cero alertas. El sistema no te avisa cuando algo está estancado.
- Aislamiento del resto del flujo. El kanban no se conecta con el assessment, ni con las entrevistas, ni con el sourcing.
Kanban que NO se usa vs kanban que SÍ
| Criterio | Kanban que NO se usa | Kanban que SÍ se usa |
|---|---|---|
| Stages | Genéricas, vienen del template | Configurables por empresa y por rol |
| Movimientos | Drag & drop sin contexto | Drag & drop con fit score visible en cada card |
| Bulk operations | Hay que mover de a uno | Bulk move para mandar 20 candidatos a “rechazado” o “siguiente etapa” |
| Información en la card | Nombre y un avatar | Nombre, fit score, fuente, días en etapa, alertas |
| Alertas | Ninguna | Vacancy estancada, drop-off anómalo, candidatos sin feedback |
| Sourcing | Hay que copiar el link de LinkedIn manualmente | Chrome extension agrega candidatos directo desde LinkedIn |
| Approval workflows | Por email, fuera del sistema | Approval en la card, log auditable |
| Integración con assessment | Manual: pedís el test aparte | El test se dispara desde la card |
La diferencia no es estética. Es que el segundo modelo le ahorra trabajo al recruiter en vez de pedirle trabajo extra.
Qué hace que un pipeline se actualice solo
La pregunta correcta no es “¿cómo logro que mi equipo actualice el pipeline?”. Es “¿cómo logro que actualizar el pipeline sea más fácil que no actualizarlo?”.
Estas son las palancas que vemos funcionar.
Stages configurables por empresa
Cada empresa tiene su proceso. Una scaleup de software tiene “screening → técnica → cultural → oferta”. Un BPO tiene “screening → assessment → entrenamiento → assignment”. Un retail tiene “aplicación → grupal → individual → oferta”. Un kanban con stages fijos pierde con cualquiera de ellos.
La plataforma permite definir las stages a nivel company y, dentro de eso, ajustes por rol. No es customización por customización: es la condición mínima para que el equipo vea el kanban como su proceso, no como uno impuesto.
Drag & drop con fit score visible
Mover una card no debería ser un acto de fe. Cuando el recruiter ve, en la card, el fit score del candidato contra ese rol específico, mover la card pasa a ser una decisión informada. El score actúa como anclaje: “este tiene 87% de fit, lo paso. Este tiene 42%, lo descarto”.
El fit score no reemplaza el criterio del recruiter. Lo acompaña. Y el acompañamiento es lo que vuelve el kanban un asistente, no una tarea.
Bulk move
Cuando una vacancy se cierra y hay que mover 30 candidatos a “rechazado” con un mismo template de email de feedback, el bulk move convierte 30 minutos en 30 segundos. La adopción se gana en estos detalles, no en las features principales.
Approval workflows dentro de la card
El hiring manager tiene que aprobar al candidato para pasar a oferta. Ese approval no puede vivir en un email perdido. Tiene que estar en la card: el approver recibe la notificación, aprueba o rechaza con comentario, y todo queda logueado. Cuando el equipo legal o el CFO pregunta cómo se aprobó esa contratación, hay una respuesta auditable.
Chrome extension para sourcing sin fricción
El recruiter encuentra un candidato en LinkedIn. Con la extensión, ese candidato se agrega al rol con un click. Se dispara la invitación al assessment automáticamente. La card aparece en el kanban con la información ya cargada. No hay copy-paste, no hay un Sheet intermedio, no hay “después lo cargo”.
Esa fricción cero es lo que cambia la economía mental del proceso. Si agregar candidatos cuesta, no se agregan. Si cuesta cero, el pipeline se llena.
La trampa de las “features” sin uso real
Hay un sesgo común en evaluación de pipelines: comparar feature-list. “El mío tiene drag & drop, bulk move, integración con Slack, AI suggestions, etc.” Las features importan, pero importan menos que el uso real.
Algunas preguntas más útiles cuando estás eligiendo o auditando un pipeline:
| Pregunta | Si la respuesta es no… |
|---|---|
| ¿El recruiter ve valor inmediato al mover una card? | Va a dejar de moverlas |
| ¿Hay alertas que avisan cuando algo está estancado? | El abandono no se va a detectar |
| ¿Se puede customizar stages sin pedirle a un consultor? | El proceso real va a vivir afuera |
| ¿La card muestra fit score, source y días en etapa? | El recruiter va a tener que clickear constantemente |
| ¿Hay un Chrome extension o forma de sumar candidatos sin copy-paste? | El kanban va a estar incompleto |
| ¿El approval del hiring manager queda dentro del sistema? | Vas a depender de emails para audit trail |
Si dos o más respuestas son no, el pipeline va a ser usado con disciplina los primeros 30 días y abandonado entre el día 60 y el 90. Lo vimos en proyectos donde no fuimos elegidos: el cliente vuelve a los 6 meses pidiendo migración del Sheet en el que terminó viviendo el proceso real.
El pipeline como source-of-truth, no como reporte
El segundo shift mental importante: el pipeline no es un reporte. Es el lugar donde el proceso vive. Si el proceso vive en otro lado —en Slack, en la cabeza del recruiter, en un Sheet— el pipeline está condenado a estar desactualizado por definición.
Esto tiene implicancias concretas en cómo se diseña:
- La invitación al assessment se manda desde la card, no afuera.
- Los feedbacks de entrevista se cargan en la card, no en un doc aparte.
- El approval del hiring manager pasa por la card.
- Las notas y comentarios viven en la card.
Cuando todo eso converge, actualizar el pipeline deja de ser una tarea: es el efecto colateral de hacer el trabajo.
Cómo migrar a un pipeline que el equipo use
Si venís de un proceso roto, estas son las fases que vemos funcionar:
Fase 1: definir las stages reales, no las que vienen en el template. Hacé un workshop de 90 minutos con recruiters y hiring managers. Mapeá el proceso como realmente sucede.
Fase 2: configurar 2-3 alertas mínimas. Vacancy estancada, drop-off anómalo, candidatos sin feedback hace más de X días.
Fase 3: instalar la Chrome extension en todo el equipo. Es la pieza que reduce la fricción de entrada de candidatos. Sin esto, el pipeline empieza vacío.
Fase 4: matar el Sheet paralelo. Esto es el más político. Si el equipo mantiene su Sheet, el pipeline pierde. Tiene que haber una decisión explícita: el source of truth pasa a ser el pipeline.
Fase 5: revisión semanal corta. 15 minutos donde el lead y el recruiter miran los candidatos estancados, no todos. Si la herramienta funciona, esa revisión es rápida.
Cómo encaja con el resto
El pipeline no resuelve hiring solo. Resuelve la coordinación del proceso. Si querés ver cómo se conecta con reporting, evaluación de competencias y arquetipos, te dejo el hub post. Y si querés ver el módulo en detalle: /funcionalidades/pipeline.
Implementalo con nosotros
Si tu equipo está viviendo en un Sheet o en un ATS que nadie actualiza, no te falta una herramienta más. Te falta un proceso que no se sienta como burocracia. Te ayudamos a diseñar las stages, configurar las alertas y conectar la Chrome extension al sourcing para que el pipeline empiece a llenarse solo.
Agendá una demo de 15 minutos.
¿Preguntas? Escribime a fran@talen.to.
Sigue explorando
Perfiles OCEAN+ relacionados
Descubri que dimensiones de personalidad buscar en cada rol.
Artículos Relacionados
Reportería de HR que importa: qué métricas trackear más allá de time-to-hire
Tu CHRO no quiere otro dashboard. Quiere que el dashboard le avise cuando algo se rompe. Guía a las métricas que mueven la aguja y al sistema de alertas que las vuelve accionables.
No es un test psicométrico, es una plataforma de hiring intelligence
Por qué Talen.to dejó de ser solo un assessment y se volvió ATS + assessment + reporting + workflows en una sola plataforma. Pipeline, shortlists, interview panels y reporting suite explicados.
Lo que Talen.to hace y que probablemente no sabías
Nuestro sitio comunica el 10% de lo que la plataforma realmente hace. Acá está el inventory completo: pipeline, reporting, evaluaciones multi-evaluador, calibración propia y mucho más.