Perfect Match, reducir el riesgo de una promesa de matching sobre datos imperfectos

Una promesa por encima de sus datos

Perfect Match le promete al comerciante describir su proyecto para recibir las agencias adecuadas, en lugar de buscar solo en una lista. Detrás de la promesa, una herencia: fichas de agencia salidas de una migración desde la antigua herramienta de partners, servicios mapeados automáticamente, campos vacíos. Las exploraciones de producto que precedieron convergían en la misma constatación: el déficit de confianza existe de los dos lados. El comerciante quiere pruebas al momento de elegir; la agencia aparece en proyectos fuera de su calibre, sobre la base de una ficha que nunca construyó. Ese déficit no se arregla con un filtro más. Se arregla decidiendo qué puede prometer el producto con los datos de los que realmente dispone.

Retomar, jerarquizar, nombrar el desacuerdo

La discovery había quedado detenida a mitad de camino seis meses antes. Retomarla fue primero un replanteamiento. La lectura inicial hacía del recorrido del comerciante el tema: un brief, una página de resultados, un algoritmo. Insuficiente: sin datos de agencia confiables, ese recorrido promete un match que no puede cumplir. El ciclo se encuadró entonces sobre dos casos de uso indisociables y jerarquizados: el recorrido del comerciante, atendido primero porque carga la promesa, y los datos de agencia, instrumentados porque solo ellos pueden cumplirla. Dos poblaciones de agencias se distinguieron desde ese planteamiento: la agencia histórica, cuya ficha migrada debe ser reapropiada antes de cualquier matching, y la agencia nueva, que construye la suya desde cero.

Ese planteamiento hizo emerger un desacuerdo real: ¿eran confiables los datos migrados? Una lectura decía que sí, las fichas están ampliamente completas. La otra decía que no, completa no significa validada, y hacer matching sobre información declarativa sin confirmar equivale a hacer matching sobre ruido. En lugar de zanjar por intuición, la divergencia se asentó como tal en el registro de decisiones del proyecto, con un arbitraje sobre evidencia por parte de la persona que tiene acceso a los datos. Un desacuerdo nombrado vale más que un consenso tibio: dentro de seis meses, el equipo sabrá por qué se definió la regla, no solamente cuál.

La auditoría antes de las pantallas

La intuición de partida sostenía que un buen matching exigía campos nuevos: tamaño de proyecto gestionado, presupuesto, disponibilidad. Bastaba con pedirles a las agencias que los llenaran. Esa hipótesis merecía verificarse antes de dibujar cualquier cosa. Cada señal disponible o considerada pasó entonces por revisión y se clasificó en tres familias: los filtros eliminatorios que excluyen del pool, los criterios de pertinencia que ordenan, los criterios de desempate que deciden entre buenos candidatos. Y para cada una, cuatro preguntas: el dato existe, de dónde viene, está probado o es declarativo, qué pasa cuando falta.

La decisión que invirtió el plan

El resultado contradecía el plan. Los campos planteados al inicio eran los más frágiles de la matriz: declarativos, inverificables, y la disponibilidad caduca en unas semanas. En el sentido contrario, señales ya probadas dormían en lo existente: el ranking del directorio, el nivel de expertise otorgado por el programa, las certificaciones verificadas.

El dilema quedó planteado. Primera opción: esperar los datos nuevos, pedirles a las agencias que llenaran los campos faltantes, y lanzar un matching rico sobre información declarativa cuya fiabilidad seguiría siendo inverificable. Segunda opción: lanzar más sobrio, únicamente sobre los datos probados, asumiendo un matching menos fino pero donde cada regla se defiende. El razonamiento cupo en una pregunta: ¿con qué se va a encontrar el comerciante en el lanzamiento? Con un stock de fichas incompletas, un matching exigente en datos excluye agencias por una migración que no eligieron, y vacía las páginas de resultados.

La decisión: la primera versión gira exclusivamente sobre los datos probados existentes, y los campos declarativos llegan después, como refinamiento. Una regla por defecto completa el dispositivo: un dato ausente da un puntaje neutro y nunca excluye, fuera de los filtros duros. Consecuencias directas: el lanzamiento ya no depende de una recolección todavía hipotética, la reapropiación de la ficha migrada se convierte en el punto de partida del recorrido de agencia, y los casos límite se convierten en pantallas a diseñar primero.

Pantallas probadas como los datos

La misma lógica se aplicó al diseño. Una maqueta habría mostrado el recorrido donde todo sale bien: tres agencias impecables, perfiles completos, un match evidente. La realidad del lanzamiento son datos incompletos, zonas casi vacías, briefs sin correspondencia. Los dos recorridos se construyeron entonces en un playground interactivo dentro del repositorio del producto, en Vue con PUIK, el design system open source de PrestaShop. Claude Code produjo las pantallas dentro de un marco definido de antemano; la dirección de diseño, las decisiones y la revisión siguieron siendo humanas. Cuando un componente faltaba en el design system, se convertía en un candidato propuesto al sistema y no en una divergencia local: un design system no se consume, se alimenta.

La página de resultados se diseñó a partir de los casos límite. Ninguna agencia corresponde al brief: la pantalla lo dice, propone ampliar la búsqueda y remite a la lista completa. La shortlist está incompleta: muestra lo que existe, anuncia el número, no infla nada. En un deck de maquetas, esos estados son los frames que nadie abre. En un playground, son situaciones contra las que la revisión tropieza, como tropezaría un comerciante. La revisión de producto cambió de naturaleza: el equipo ya no comenta una intención, pone a prueba un comportamiento.

Lo que está ganado, lo que falta probar

La funcionalidad ya despegó. Hay criterios de éxito definidos sobre la finalización del brief, la aceptación de la shortlist y la progresión de las fichas de agencia, pero ningún dato de adopción existe al momento de escribir estas líneas, y nada más se va a afirmar aquí. Lo que está ganado cabe en tres puntos: un modelo de pertinencia donde cada regla es trazable hasta un hecho, un lanzamiento calibrado sobre los datos que el producto realmente posee, y una práctica de revisión en playground que ya desborda este proyecto para volverse un hábito de equipo. La pregunta que contará dentro de seis meses no es si las pantallas quedaron bien: es si la regla del puntaje neutro bastó para proteger la confianza mientras el stock de fichas se sanea.

Mi mandato terminó en agosto de 2026. El proyecto se transmitió con sus instrumentos: el playground reproducible, el registro de decisiones, los criterios de éxito definidos. Un diseño que no sobreviviera a ese traspaso no habría merecido la palabra.