Tres formas de crear un Job: diseñar asistencia con IA en un marketplace de staffing

El día que un cliente tuvo que crear 47 Jobs en una sola sesión, quedó claro que el formulario no podía seguir siendo la única puerta de entrada.

No era un problema del formulario como patrón. Era un problema de volumen, contexto y repetición. Una operadora de staffing podía empezar un lunes a las 7 AM con turnos para dos semanas, distintos clientes, horarios, roles, skills y pay rates. En ese escenario, completar campo por campo era una forma lenta de traducir algo que la persona ya tenía armado en su cabeza o en una planilla.

Terminamos diseñando tres rutas para crear un Job: dictado por voz, texto libre y carga de Excel. La clave no fue hacer tres productos distintos, sino lograr que todas esas rutas terminaran en la misma pantalla de revisión.

Contexto: cuando el formulario gana, los operadores pierden

Wolf es un marketplace multi-lado para la industria de staffing en Estados Unidos. Conviven tres tipos de usuarios: administradores de la staffing company, clientes que contratan personal y job seekers que reciben los Jobs en la app mobile.

Cuando llegué al producto, el flujo principal era el formulario clásico. 47 Jobs × 14 campos = 658 entradas. A 2 segundos por campo —siendo optimistas— son 22 minutos de carga manual para una tarea que, conceptualmente, ya estaba resuelta antes de abrir la plataforma.

El formulario no era el problema. El problema era que fuera la única puerta de entrada al sistema.

La hipótesis: cómo se entra un dato no es cómo se guarda

La primera decisión de UX fue separar dos cosas que estábamos mezclando: cómo una persona expresa una intención y cómo el sistema necesita representarla internamente.

Dentro del sistema, un Job seguía siendo el mismo objeto: schedule, uno o más JobTypes, requirements y pay rate. Esa estructura no cambiaba. Lo que sí podía cambiar era la forma en que la operadora llegaba a ese objeto.

1. 01Voz. Para quien está coordinando turnos mientras hace otra cosa. La persona dicta algo como: "Necesito 4 cocineros para el sábado de 8 AM a 4 PM en Hilton Austin, pay rate 22". El sistema estructura la información y la muestra para confirmar.
2. 02Texto libre. Para quien prefiere escribir una instrucción completa sin recorrer 14 campos. Misma intención, otro canal.
3. 03Excel. Para los casos donde la información ya existe en una planilla. Carga del archivo, mapeo de columnas, revisión y confirmación.

El formulario quedó como cuarta opción: útil cuando se necesita control granular o cuando el Job no encaja en un patrón previo.

Decisión #1 — Convergencia visual antes de enviar

La decisión que ordenó todo fue obligar a que las tres rutas terminaran en la misma pantalla de revisión. Al principio parecía un detalle, pero evitó que voz, texto y Excel se convirtieran en tres experiencias separadas.

Si la persona no ve el Job final antes de publicarlo, no confía en el sistema. Y si no confía, vuelve al formulario.

La pantalla de revisión se convirtió en el contrato. Lo que aparece ahí es exactamente lo que se va a crear. Cualquier dato inferido queda marcado con una señal sutil; al abrirla, se muestra de dónde salió esa interpretación. Cada campo se puede editar en línea antes de publicar.

La entrada podía ser flexible; la verificación, no. Esa asimetría fue lo que permitió lanzar asistencia inteligente sin debilitar la confianza de los usuarios.

Decisión #2 — Manejar el desastre del Excel real

La ruta por voz y texto libre era relativamente directa de prototipar. Excel fue otra historia. En staffing, las planillas reales suelen venir con estructura irregular:

• Columnas con nombres distintos según quién armó el archivo (pay, payrate, pay_rate, $/hr).
• Schedules expresados como rango, días concretos o texto libre.
• Múltiples JobTypes dentro de una sola fila usando comas, slashes o columnas según el cliente.
• Filas vacías mezcladas. Headers en la fila 3 en vez de la 1. Hojas con notas que nadie leyó.

La salida fácil era diseñar el caso ideal y mostrar un error genérico cuando algo no calzaba. En productos operacionales, ese error genérico es exactamente donde la gente abandona el flujo.

Lo que hicimos

1. 01Parser tolerante. El backend intenta varias estrategias de mapeo. Cada una produce una confianza.
2. 02UI de reconciliación. Si la confianza es alta, se aplica el mapeo y se muestra un aviso para revisar. Si la confianza es baja, se abre un paso explícito donde la persona arrastra columnas hacia campos.
3. 03Revisión fila por fila. Antes de publicar, cada fila aparece como un Job individual. Los Jobs con advertencias se marcan en naranja y se editan en línea.
4. 04Publicación parcial. Si 45 de 47 Jobs están listos y 2 tienen advertencias, se pueden publicar los 45 y dejar los otros 2 como borrador.

La publicación parcial fue lo que más discusión generó con ingeniería. La preocupación era válida: había que manejar borradores pendientes en la base de datos. Pero en pruebas vimos el patrón con claridad: si obligábamos a resolver todo el Excel antes de crear un solo Job, la persona prefería cerrar el flujo y empezar desde el formulario.

El acuerdo fue simple: los borradores persisten 7 días y se avisa 48 horas antes de limpiarlos. Resolvió el problema de UX sin dejar estados pendientes para siempre.

Decisión #3 — Cuándo NO usar IA

Después del segundo mes en producción apareció un dato incómodo: para Jobs muy simples —un turno, un trabajador, un cliente conocido— la ruta de voz o texto libre podía ser más lenta que el formulario.

Tenía sentido. Decir "necesito un electricista para mañana de 9 a 5 en Marriott downtown" toma varios segundos, y luego hay que revisar el resultado. Si el formulario optimizado resuelve ese caso en tres campos, no vale la pena esconderlo.

La asistencia inteligente no reemplaza la experiencia del producto. Es una entrada más.

Esa distinción fue importante para el roadmap. No todo debía volverse conversacional. La mejor experiencia era dejar que cada caso usara la entrada que realmente le convenía.

Lo que aprendimos

1. 01Separar intención de representación. El sistema interno puede ser rígido. La forma en que el usuario llega a él no tiene por qué serlo.
2. 02La pantalla de convergencia es el contrato. Cualquier flujo paralelo necesita un punto único donde la persona verifica antes de confirmar.
3. 03Diseñar el camino del error con el mismo rigor que el caso ideal. Mapeo de columnas, publicación parcial y borradores persistentes son decisiones de UX, no solo de implementación.
4. 04No usar asistencia inteligente donde no aporta. Si el formulario es más rápido para Jobs simples, hay que mantenerlo visible y optimizado.

Yo era el único Product Designer del producto, pero esto fue trabajo de equipo. Lo sacamos adelante con colaboración constante con 7 ingenieros y varias rondas de pruebas con operadoras reales en Texas y el Midwest. El Design System también fue clave: creció de 0 a 60-100+ componentes durante ese periodo y permitió que las tres rutas se lanzaran con consistencia visual sin romper el roadmap.