04 · Portfolio

Un screening que cabe en una conversación de WhatsApp

RH publica una vacante con un QR, el candidato contesta por WhatsApp y el sistema entrega solo los perfiles que pasan. Las reglas se configuran, no se programan.

Construido y sin lanzar: los envíos están pausados desde el 17 de agosto de 2026 mientras se separa el número de una campaña de anuncios. Las imágenes son de diseño, no capturas de producción.

Rol
Head of Product. Discovery, especificación, UX y desarrollo.
Contexto
Self Check · 2026
Stack
Supabase Edge Functions · Postgres con RLS · pg_cron · UniPile (WhatsApp) · React + TanStack Query
La página del módulo · la promesa y la conversación de ejemplo al lado
La página del módulo · la promesa y la conversación de ejemplo al lado
Antes

El screening de volumen se hace a mano: alguien de RH lee respuestas de un formulario, o llama, y el criterio vive en su cabeza.

Después

El candidato conversa por WhatsApp, el motor evalúa cada respuesta contra las reglas de esa vacante y RH recibe el perfil clasificado con la regla que se aplicó.

El problema

El reclutamiento de volumen es donde peor se decide sobre personas: cientos de candidatos, una plantilla de RH que no crece y un formulario que nadie rellena.

El candidato de volumen no abre un portal de empleo, pero contesta un WhatsApp en dos minutos. Y el filtro tenía que vivir en manos de RH, para que cambiar un criterio no fuera un despliegue.

El objetivo

Que RH publique una vacante, defina sus preguntas y sus reglas sin ayuda de nadie, y solo mire a los candidatos que ya pasaron el filtro.

La métrica
Aprobados sobre conversaciones iniciadas

Los escaneos y las conversaciones abiertas se inflan poniendo el cartel en más sitios: miden difusión, no filtro. El aprobado sobre conversación iniciada es lo único que se rompe si las reglas están mal puestas.

Discovery

A quién tenía delante antes de diseñar nada.

Usuario tipo

Carolina

Generalista de RH en una empresa con contratación de volumen

Publica la misma vacante cada pocas semanas y recibe cientos de candidatos por campaña. Su plantilla no crece con la demanda, y el formulario del portal lo abandona casi todo el mundo antes de terminarlo.

Qué necesita

Cambiar un criterio el mismo día que se lo piden, sin abrir un ticket, y mirar solo a los candidatos que ya pasaron el filtro.

Qué se lo impide

El criterio vive en su cabeza o en el chat del equipo, así que cada persona filtra distinto y nadie puede explicar un descarte. El candidato de volumen no abre un portal de empleo, pero contesta un WhatsApp en dos minutos.

«Leer trescientas respuestas lo puedo hacer. Lo que no puedo es leerlas dos veces porque cambió un requisito.»

Historia de usuario

Como responsable del producto quiero que un despliegue que se olvide del interruptor de envío no mande ningún mensaje, para que el modo de fallo sea el silencio y no el spam a candidatos reales.

El alcance
10
tipos de pregunta

Texto, opción única y múltiple, sí/no, número, rango, ubicación, disponibilidad, salario y documento.

4
efectos de regla

Rechazar, marcar para revisión, aprobar y puntuar, con una precedencia fija entre ellos.

5
etapas del embudo

Escaneos, conversaciones iniciadas, aceptaron continuar, completadas y aprobadas, con el detalle de dónde se cae la gente.

Cómo funciona

Dos formas de empezar, un solo camino.

Una conversación arranca por QR o porque RH da de alta a alguien. Se diferencian en quién habla primero y en nada más, y eso fue deliberado.

  1. entra
  2. consiente
  3. contesta
  4. se evalúa
  5. lo revisa RH
  1. 01

    entra

    Por QR, con un token opaco en el texto precargado del mensaje, o por alta manual. WhatsApp no deja pasar datos en el enlace, así que el texto es el único canal.

    La decisión

    WhatsApp no deja pasar datos en el enlace, así que la vacante viaja dentro del texto precargado del mensaje. Es un token opaco y no un identificador legible, porque ese texto lo ve el candidato antes de enviarlo.

    El cartel como se publica: un grupo de empleo, el QR y el enlace con la vacante dentro
  2. 02

    consiente

    El primer mensaje pide permiso y ofrece la salida. Un screening que empieza sin consentimiento es un problema legal con forma de producto.

    La decisión

    El primer mensaje pide permiso y ofrece la salida antes de preguntar nada. Un screening que empieza sin consentimiento es un problema legal con forma de producto, y el sitio donde se resuelve es este, no la letra pequeña de un portal.

    Maqueta de la apertura: quién escribe, para qué vacante y cuántas preguntas van a ser
  3. 03

    contesta

    Preguntas de una en una, con parseo tolerante: "sip" es un sí, "18 mil" son dieciocho mil. Tres intentos y un mensaje de ayuda distinto en cada una.

    La decisión

    Una pregunta por mensaje y parseo tolerante: un "sip" es un sí y "18 mil" son dieciocho mil. Cada reintento cambia el texto de ayuda, porque repetir la misma frase tres veces es lo que hace que la gente cierre la conversación.

    Maqueta del tramo medio: una pregunta por mensaje y las opciones a un toque
  4. 04

    se evalúa

    Cada respuesta se mide contra las reglas de esa vacante y se guarda copia de la regla aplicada. Un rechazo corta la conversación sin decir cuál fue el criterio.

  5. 05

    lo revisa RH

    tu decisión

    El aprobado y el marcado llegan al panel con su explicación: qué regla, con qué respuesta, a qué hora. Llamar a alguien sigue siendo decisión de una persona.

    La decisión

    El panel enseña qué regla se aplicó, con qué respuesta y a qué hora. Al evaluar se guarda una copia de la regla tal como estaba en ese momento, así que cambiar un criterio no reescribe la historia de quien ya pasó por el filtro.

    Los candidatos ya filtrados por vacante, con su puntaje y el motivo del descarte a la vista
Lo que no construí
  • La API de WhatsApp de MetaPlantillas a aprobar y una cuenta de negocio

    Descartada como punto de partida, no como destino. Queda escrita detrás del adaptador de proveedor para poder migrar sin tocar el flujo, pero para validar el producto no hacía falta pasar por la aprobación de plantillas de Meta.

  • Generar el QR en el servidorUna llamada por cada vez que se mira

    Descartado. El QR solo codifica una URL y es determinista: no hay nada que calcular. Se renderiza en el cliente en SVG, doce kilobytes, y el mismo componente exporta el PNG de 1024 para el cartel impreso.

  • Contar el cupo de envío por organizaciónLo razonable si cada cliente tuviera su número

    Descartado, y es la decisión que más consecuencias tiene. El número de WhatsApp es uno solo para todo el producto: si se banea, el servicio se cae para todos los clientes a la vez. El cupo de primer contacto se cuenta global al número, quince a la hora y sesenta al día.

  • Las reglas dentro del código del flujoUn despliegue por cada criterio que cambie

    Descartado. Las reglas se leen de la base, y al evaluarlas se guarda una copia de la regla tal como estaba en ese momento. Cambiar un criterio no reescribe la historia de quien ya pasó por el filtro.

Cómo se lo pedí a desarrollo

La regla de la que estoy más contento no añade nada al producto: decide cómo falla. Es lo que escribí después del único incidente que ha tenido.

Criterios de aceptación
  • El interruptor sin definir significa pausado. El valor por defecto es el seguro y no el cómodo, así que un despliegue olvidadizo se cae hacia el silencio.
  • El corte vive en un único punto de paso, la función que manda texto, para que no exista una segunda vía que se lo salte.
  • Hay además un corte temprano en el webhook: la máquina de estados no avanza si no se le puede contestar al candidato, para no dejarlo a medias de un cuestionario que no va a poder terminar.
  • El inbound se sigue recibiendo y el mensaje crudo se guarda entero, así que mientras está pausado nada se pierde y todo se puede reprocesar.
  • Las funciones de alta y de recordatorio contestan un error explícito con su motivo, para que RH no lo lea como una caída del proveedor.

El valor por defecto invertido va contra la costumbre: lo normal es que una variable ausente signifique "sigue funcionando". Aquí significa lo contrario porque los dos fallos no son comparables. Un producto parado un día se arregla poniendo una variable; cien candidatos que reciben el saludo de un screening al que no se apuntaron no se arreglan.

Cómo lo lancé

No está lanzado, y la lista no son fases con fecha: es lo que bloquea al primer cliente real, en orden. Es la lista con la que trabajo.

  1. 01

    número propio y proveedor conectado

    Sin un número separado de la campaña de anuncios no hay producto. El resto no importa hasta que se resuelva.

    Qué medíaConversación completa punta a punta con teléfonos reales
  2. 02

    desplegar el alta manual y el recordatorio

    Las dos funciones están escritas y sin subir, así que hoy devuelven un 404. Están del lado fácil del bloqueo.

    Qué medíaAlta manual que llega al candidato
  3. 03

    prueba de aislamiento entre clientes

    Las políticas por organización están puestas en todas las tablas, pero puestas no es probado. Sin esa prueba no se enseña a dos clientes a la vez.

    Qué medíaCero filas visibles entre organizaciones distintas
  4. 04

    trazas de error

    Un webhook que falla en silencio pierde candidatos y nadie se entera hasta que RH pregunta por alguien que nunca llegó.

    Qué medíaErrores vistos antes de que los vea el cliente
  5. 05

    aviso de privacidad publicado

    El consentimiento del primer mensaje tiene que apuntar a un documento que exista. Hoy pide permiso para algo que no está escrito.

    Qué medíaEl consentimiento enlaza a algo
Lo que me llevé

El único incidente no fue técnico. El número estaba compartido con una campaña de anuncios, y quien dejaba su teléfono en el formulario del anuncio recibía el saludo del screening. La respuesta no fue filtrar mejor, fue contestar solo cuando la conversación es nuestra: un catch-all amable es una puerta abierta con buenos modales.

Vuelta al primeroUn copiloto de IA que sustituyó el sourcing booleano01 · SelfRecruit · 2026Abrir caso
Gabriel SerranoProducto de IA · SaaS B2B · fintech y HRTech
BlogLinkedIn ↗© 2026 Gabriel Serrano