Formulario en dos pasos e integración con una API
Un formulario en dos pasos tenía que comprobar la elegibilidad de un vehículo en un servicio externo, convertir cada respuesta en un estado de resultado claro y llevar la atribución de campaña hasta el envío.
- Periodo
- 2025
- Contexto
- Trabajo profesional
- Cliente
- No revelado
Contexto
Una landing necesitaba un flujo personalizado en dos pasos para sustituir a un formulario más sencillo: un primer paso que recogía los datos del vehículo y comprobaba su elegibilidad en un servicio externo, y un segundo paso que recogía los datos de contacto y enviaba el caso que cumplía los requisitos.
El equipo construyó el sitio y el flujo desde cero en WordPress, en lugar de montarlo con un plugin de formularios. Necesitaba elegibilidad dirigida por API, estados de resultado diferenciados, atribución mantenida a lo largo de los dos pasos y una señal de finalización una vez creado el caso, cosas que quedan fuera de lo que hace un constructor de formularios estándar.
El servicio externo lo mantenía otro desarrollador ajeno al equipo, que aportó la documentación de los endpoints y la orientación técnica necesarias para construir y probar sobre él. El flujo salió en producción en 2025 y se sigue manteniendo hoy.
- Plataforma
- WordPress
- Flujo
- Formulario en dos pasos
- Integración
- API REST externa
- Estado
- En producción
El reto
El principal reto era coordinar las distintas piezas en torno a una API de terceros: los estados de elegibilidad, los casos duplicados, la atribución a lo largo de los dos pasos y la señal de finalización. La integración también tenía que ser lo bastante flexible para admitir cambios después del lanzamiento.
Mi responsabilidad
Experiencia del formulario
- Construí el flujo personalizado del formulario en dos pasos.
- Implementé el comportamiento principal del frontend y los estados de la interfaz.
- Creé la dirección visual inicial y el concepto de los dos pasos, y después colaboré con una persona de diseño en el orden de los campos y en los ajustes de UX.
Integración con la API
- Construí el plugin de WordPress personalizado que actúa como capa de integración.
- Implementé la integración a partir de la documentación aportada por la persona que desarrolló la API externa.
- Implementé la gestión de los estados de elegibilidad.
- Implementé la gestión de duplicados y de procesos ya abiertos.
- Implementé la gestión del estado de no elegibilidad.
Seguimiento y atribución
- Implementé el seguimiento a lo largo del embudo.
- Implementé la gestión de la atribución de campaña. Incluidos los parámetros UTM, GCLID y CID.
- Implementé los eventos de dataLayer.
- Implementé la señal de finalización que se envía una vez creado el caso.
Iteración en producción
- Implementé el modal legal y su interacción asociada.
- Implementé el campo de hora de contacto preferida.
- Trabajé en mejoras de rendimiento después de que el cliente comunicara que el sitio iba lento.
- Apoyé el experimento del embudo con una segunda variante publicada.
Solución
Construí un flujo personalizado en dos pasos respaldado por un plugin de WordPress que actúa como capa de integración. El primer paso recoge los datos del vehículo y pregunta al servicio externo si el caso cumple los requisitos. El plugin interpreta la respuesta y la interfaz la resuelve en un estado de resultado claro: elegible, no elegible o una reclamación que ya existe para el vehículo.
Solo continúan los usuarios que cumplen los requisitos. El segundo paso recoge los datos de contacto y envía el caso. La atribución de campaña capturada cuando llega el visitante viaja con él durante los dos pasos, y una señal de finalización marca el caso una vez creado.
Decisiones
Puse la petición de elegibilidad detrás de una capa de integración de WordPress en lugar de llamar al servicio externo desde el navegador, de modo que la configuración se queda en el servidor.
Mantuve la lógica de integración separada de la interfaz, para que el formulario pudiera seguir cambiando después del lanzamiento sin tener que reconstruir la conexión con la API.
Enfoque técnico
Recoger
Los datos del vehículo se recogen en el primer paso, con la interfaz manteniendo su propio estado de entrada.
Preparar
Los datos recogidos se ensamblan en la petición que enviará la capa de integración.
Cualificar
La petición de elegibilidad pasa por la capa de integración de WordPress en lugar de salir del navegador, de modo que la configuración se queda en el servidor.
Resolver el estado
La respuesta se resuelve en un estado de resultado orientado al usuario, en lugar de mostrarse como un éxito o un fallo en bruto.
Completar
Los usuarios que cumplen los requisitos continúan al segundo paso, donde se recogen los datos de contacto y se envía el caso.
Atribuir
La atribución de campaña capturada al llegar se mantiene a lo largo de los dos pasos y se emite como eventos de dataLayer, y una señal de finalización marca el caso una vez creado.
El sistema
- Elige qué llega para ejecutarlo.
Los datos del vehículo recogidos en el primer paso pasan a una capa de integración de WordPress, que es la única parte que se comunica con la API externa. La respuesta que vuelve se resuelve en un estado de resultado orientado al usuario, que se enruta por una de tres vías. Un vehículo que no cumple los criterios sale por una rama de rechazo y no avanza más. Un vehículo que ya tiene una reclamación sale por otra rama distinta, que es excepcional y no un fallo. Un vehículo que cumple los requisitos continúa al segundo paso, donde se recogen los datos de contacto, se envía el caso y se devuelve una confirmación. La atribución de campaña capturada cuando llega el visitante se mantiene a lo largo de los dos pasos, y una señal de finalización marca el caso una vez creado; ambas funcionan en paralelo a este flujo y no como pasos dentro de él.
Estados de la interfaz
El servicio externo devuelve una única respuesta; la interfaz tiene que convertirla en algo con lo que una persona pueda actuar. Dos de los tres resultados detienen el recorrido, y deliberadamente no se presentan igual.
No elegibleFig. 2 — El vehículo no cumple los criterios de elegibilidad, así que el recorrido se detiene aquí. Reclamación existenteFig. 3 — La petición es válida, pero ya existe una reclamación para el vehículo, así que la interfaz explica ese estado en lugar de tratarlo como un error.
El experimento del embudo
El flujo original revelaba la estimación antes de que el lead estuviera completo, lo que daba a los usuarios un motivo para abandonar en el punto en que lo que faltaba dependía de ellos. El equipo decidió probar a mover esa revelación a después de completar el formulario, que es lo que hace la segunda variante.
La variante B no se limita a ocultar la cifra. Muestra que existe una cifra y hace que completar el formulario sea la manera de verla.
Resultado
El flujo en dos pasos funciona en producción y procesa envíos reales a través de la integración con la API externa.
Se ha mantenido en uso activo y ha seguido recibiendo cambios de producto desde su lanzamiento en 2025.
Lecciones aprendidas
Este proyecto me dio experiencia práctica con la integración de APIs de principio a fin. Aprendí a trabajar a partir de la documentación de los endpoints, a probar peticiones y respuestas, a conectar una capa de integración de WordPress con un servicio externo y a convertir los estados de la API en un comportamiento claro del frontend.
El seguimiento fue otra parte importante del proyecto. Tuve que mantener la atribución UTM, GCLID y CID a lo largo del embudo, emitir eventos de dataLayer y enviar la señal de finalización una vez creado el caso.
Como el flujo siguió en producción y siguió cambiando, también aprendí el valor de mantener la lógica de integración separada de la interfaz. Eso facilitó seguir iterando sobre el formulario sin reconstruir la conexión con la API.
Tecnologías
Más de mi trabajo
Todos los proyectos- 01 · Trabajo para clientesDatos de reservas de varios hoteles, consolidados para informesLos datos de reservas de doce hoteles dependían de listas mensuales revisadas a mano, así que el workflow incorpora las reservas de forma continua y mantiene un único conjunto de datos coherente e histórico para los informes de clientes.Ver proyecto
- 02 · Trabajo para clientesBuscador interactivo de clubes de golf y flujo de inscripciónUna campaña estacional necesitaba un único flujo de inscripción para varios clubes, cada uno con reglas de disponibilidad fijadas por el cliente, de modo que cada lead llegara al club correcto con el siguiente paso correcto.Ver proyecto
- 03 · Trabajo para clientesReconstrucción en WordPress y sistema de contenido estructuradoUn nuevo sitio WordPress construido para que un equipo no técnico pueda publicar artículos, ebooks y webinars mediante contenido estructurado, con formularios de captación conectados al CRM que el cliente ya usaba.Ver proyecto
Abierto a puestos de integración, automatización e implementación técnica.
CV
Un resumen de mi experiencia y mi trabajo.
Email
La mejor forma de escribirme sobre un puesto.
LinkedIn
Experiencia, trayectoria y novedades profesionales.
GitHub
Código seleccionado, experimentos y trabajo técnico.