De formularios inteligentes a procesos conectados

De formularios inteligentes a procesos conectados

Si cada solicitud que entra por tu web obliga a alguien a revisar un correo, pedir datos que faltan y copiar información al programa de gestión, el formulario no está resolviendo el proceso: está trasladando trabajo al equipo. Los formularios inteligentes permiten cambiar ese punto de partida, recogiendo información útil y convirtiéndola en una entrada estructurada para la operativa, con reglas que determinan qué debe ocurrir después.

En Fundy planteamos este tipo de desarrollo desde una pregunta: ¿qué necesita la empresa para tramitar una solicitud sin tener que reconstruirla? La respuesta no consiste en añadir campos ni en incorporar inteligencia artificial por defecto. Consiste en conectar la captura de datos con las decisiones, los sistemas y las personas que intervienen, dejando un camino definido tanto para los casos completos como para los que necesitan revisión.

Qué diferencia a un formulario inteligente de uno normal

Un formulario convencional recoge respuestas y las envía a un destino, como un buzón o una base de datos. Uno inteligente incorpora comportamiento según el contexto: adapta las preguntas, comprueba condiciones, consulta información disponible y activa acciones posteriores. La diferencia no está en su apariencia, sino en la relación entre lo que el usuario introduce y lo que la empresa puede hacer con ello.

Un formulario aporta valor operativo cuando permite tramitar la solicitud sin volver a preguntar por información que podía haberse recogido al principio. Eso no significa que todos los casos deban resolverse automáticamente. Un circuito bien diseñado también sabe detenerse, explicar el motivo y derivar la decisión a una persona.

Pensemos en una solicitud de servicio técnico. El formulario puede preguntar primero si existe un contrato de mantenimiento. Si el solicitante se identifica mediante un mecanismo autorizado, el sistema puede consultar qué equipos tiene asociados y evitar que escriba sus referencias. Después, las preguntas cambian según el equipo y el tipo de incidencia, mientras que una avería fuera de cobertura se deriva a un circuito de presupuesto, no al mismo flujo de una intervención cubierta.

La lógica condicional reduce preguntas innecesarias, pero necesita un criterio claro. Ocultar campos sin revisar sus dependencias puede dejar respuestas antiguas que ya no corresponden al caso. Por eso, cuando cambia una respuesta que condiciona otras, conviene limpiar o volver a validar los datos afectados, explicando al usuario qué debe revisar.

Antes de diseñar la interfaz, en Fundy proponemos definir el recorrido completo:

1. Identificar el resultado esperado. Puede ser un expediente abierto, una oportunidad comercial cualificada o una petición pendiente de aprobación. «Enviar un correo» describe una acción técnica, no el resultado del proceso.
2. Para cada decisión, concretar qué datos hacen falta y de dónde deben salir. Si un dato ya existe en un sistema fiable y puede consultarse con los permisos adecuados, no tiene sentido pedir que se transcriba.
3. Establecer reglas de validación y derivación: qué casos avanzan, cuáles quedan pendientes y qué circunstancias requieren intervención humana.
4. Asignar la siguiente acción a un responsable o a una cola de trabajo. La solicitud debe tener un destino operativo, no depender de que alguien recuerde mirar un buzón compartido.
5. Preparar el tratamiento de errores y el seguimiento. El usuario necesita un justificante y el equipo debe poder comprobar qué se ha registrado y qué falta por ejecutar.

Imagen propuesta: diagrama de una solicitud que pasa por validación, asignación de responsable y registro en el sistema de gestión.

La validación merece atención propia porque hay distintos niveles de comprobación. Verificar que una dirección de correo tiene un formato admisible no demuestra que exista ni que pertenezca al solicitante. Del mismo modo, comprobar la estructura de un identificador fiscal no acredita la identidad de quien lo utiliza. Cada control debe responder al riesgo real de la operación y comunicar su alcance sin crear una falsa sensación de seguridad.

También hay reglas de negocio que un campo obligatorio no resuelve. Una fecha puede tener un formato correcto y, aun así, incumplir el plazo mínimo de un servicio. Una referencia puede existir, pero no estar asociada al cliente identificado. Estas comprobaciones deben ejecutarse en el servidor, aunque la interfaz incorpore validaciones para ayudar a completar el formulario. Las restricciones del navegador mejoran la experiencia, pero no sustituyen los controles del servidor.

Cuando esa entrada validada se conecta con el ERP, el CRM o una herramienta de gestión, el formulario pasa a formar parte de la automatización de procesos empresariales. La integración debe establecer qué sistema conserva el registro principal, qué datos se intercambian y qué ocurre si el destino no responde. Sin esas decisiones, se corre el riesgo de sustituir la copia manual por inconsistencias automáticas.

Por ejemplo, aceptar una solicitud y crear el expediente pueden ser acciones separadas. Si el ERP no está disponible, es posible conservar la entrada en un almacenamiento persistente y dejar pendiente su envío mediante una cola. En ese caso, la confirmación debe indicar que la solicitud se ha recibido, no que el expediente ya está creado. El estado mostrado tiene que reflejar lo que realmente ha ocurrido.

Además, reenviar una petición no debería generar duplicados. Los dobles clics, los problemas de conexión y los reintentos del sistema son situaciones que el diseño debe contemplar. Una clave de idempotencia permite reconocer la misma operación y evitar que se ejecute otra vez, siempre que su alcance y su gestión estén definidos. Desactivar el botón de envío ayuda en la interfaz, pero no basta como protección del proceso.

Para dirección de operaciones, la trazabilidad es tan importante como la captura. Un registro con fecha de entrada, estado, responsable y motivo de bloqueo permite distinguir entre solicitudes nuevas y trabajo que lleva tiempo esperando. Conviene utilizar estados comprensibles y vinculados a acciones concretas, como «pendiente de documentación» o «pendiente de aprobación», en lugar de agrupar cualquier incidencia bajo una etiqueta ambigua.

Cada excepción necesita un destino y un responsable; de lo contrario, la automatización solo cambia el lugar donde se acumula el trabajo. Si falla una consulta externa, debe existir una política de reintentos y una vía de revisión. Si falta un documento, el solicitante necesita saber cuál y cómo aportarlo sin reiniciar todo el trámite. Si una regla bloquea el avance, el equipo debe poder consultar el motivo sin acceder a información que no necesita.

La inteligencia artificial puede ayudar cuando hay contenido no estructurado. Por ejemplo, puede proponer una clasificación a partir de una descripción o extraer campos de un documento adjunto. Sin embargo, sus resultados requieren controles adecuados al uso: contrastar valores con catálogos, comprobar campos obligatorios y solicitar revisión cuando existan contradicciones. Una propuesta generada por un modelo no debe confundirse con un dato verificado.

Para condiciones deterministas, como comprobar una cobertura o exigir autorización según el importe, las reglas explícitas ofrecen un comportamiento más fácil de probar y auditar. En Fundy defendemos elegir la tecnología por la necesidad del proceso: incorporar IA donde ayuda a interpretar información y mantener reglas verificables donde la decisión ya está definida.

La seguridad y la experiencia de uso también condicionan el resultado. Un formulario debe pedir únicamente los datos necesarios, informar sobre su tratamiento y limitar quién puede consultarlos. Los adjuntos requieren controles de tamaño, tipo y contenido; los campos ocultos no deben utilizarse para guardar secretos ni acreditar permisos. En móvil, las etiquetas claras, los errores junto al campo y la conservación segura del progreso ayudan a completar trámites sin repetir trabajo.

Para comprobar si la solución funciona, no basta con contar envíos. Hay que observar qué sucede después: cuántas solicitudes necesitan aclaraciones, cuántas requieren transcripción manual, dónde se bloquean y cuánto tiempo transcurre hasta la primera acción útil. Comparar esos indicadores antes y después permite detectar si el formulario está reduciendo carga o simplemente exigiendo más esfuerzo al solicitante.

El primer desarrollo debería abordar un proceso acotado, con reglas conocidas y un responsable operativo. Antes de publicarlo, conviene probar casos completos, respuestas contradictorias, permisos insuficientes, adjuntos rechazados y caídas de los sistemas conectados. Documentar esas reglas y sus pruebas reduce deuda técnica y facilita la escalabilidad cuando aparecen nuevos servicios o circuitos de aprobación.

Agenda una consultoría con Fundy y trae un formulario que hoy genere correos, comprobaciones o transcripciones manuales. Utilizaremos ese recorrido para identificar los datos necesarios, las reglas de decisión y los puntos de integración, de modo que puedas delimitar un primer desarrollo y sus criterios de aceptación antes de invertir en automatizarlo.