Web, app o automatización: qué construir primero

“Necesitamos una app con IA” puede ser el inicio de una conversación, pero todavía no es un alcance. Antes de escoger tecnología hace falta describir una tarea, quién la realiza y dónde se atasca hoy.

Imagina que una empresa ficticia recibe solicitudes por correo y las copia en una hoja. El problema podría resolverse con un formulario y reglas. O podría necesitar una aplicación para consultar estados. Si las solicitudes llegan en textos muy distintos, la IA podría ayudar a interpretarlas. Son decisiones diferentes y se pueden probar por separado.

Dibuja la tarea actual antes de proponer pantallas

Escribe el recorrido con verbos: recibir solicitud, comprobar datos, asignar responsable, responder y consultar estado. Añade quién hace cada paso, qué información necesita y qué sucede cuando falta un dato.

No empieces con “dashboard, chatbot y login”. Pregunta qué decisión habilita cada elemento. Un panel que nadie consulta añade mantenimiento; una cuenta obligatoria puede impedir que una persona termine una consulta sencilla.

Antes: “Una app con IA para atender todo”. Después: “Un formulario recoge cinco campos; una regla asigna el tipo de solicitud; una persona confirma el responsable antes de responder”. Este brief deja claro qué entra en el primer prototipo y qué queda pendiente.

Cuatro soluciones que conviene distinguir

• Explicar una oferta y recibir consultas: empieza con un sitio o landing con formulario. Amplía si la persona necesita volver a consultar información propia.
• Resolver una tarea recurrente con datos y estados: evalúa una aplicación web. Revisa si hay una necesidad concreta de funciones del dispositivo.
• Usar capacidades del dispositivo en un contexto específico: evalúa una app móvil y prueba las funciones críticas en los dispositivos y navegadores objetivo.
• Trasladar información entre herramientas: empieza con integración y reglas. Evalúa IA si el texto variable resulta difícil de resolver de forma mantenible.

Esta matriz es un criterio de alcance, no una clasificación rígida. Una web puede incluir funciones de aplicación. También puede ofrecer instalación como PWA en navegadores compatibles. El soporte depende del entorno: prueba las funciones necesarias en los dispositivos reales antes de decidir. Documentación de instalación de PWAs en MDN.

Cuándo una regla basta y cuándo evaluar IA

Si el formulario pregunta “campaña, web o soporte”, una regla puede asignar la categoría sin interpretar lenguaje. Si el equipo escribe libremente “necesitamos una página para una feria con reservas”, decidir la categoría puede requerir contexto. Ahí tiene sentido evaluar una clasificación con IA frente al proceso manual.

Empieza por la decisión más limitada: proponer una categoría, extraer campos o preparar un borrador. Conserva el texto original y una forma de corregir el resultado. No necesitas permitir que el sistema envíe respuestas o cambie datos para comprobar si ayuda a preparar el trabajo.

La salida “no tengo suficiente información” forma parte del producto. Un mensaje que mezcla una queja con una solicitud comercial debe poder pasar a revisión. Tampoco conviene inventar una fecha o un presupuesto que la persona no dio.

Un prototipo pequeño que sí permite aprender

Para el ejemplo de solicitudes, construiríamos un recorrido acotado: entrada de datos ficticios, clasificación propuesta, lista de información faltante, revisión humana y borrador editable. La confirmación final queda explícita.

Antes de construirlo, puedes calcular el tiempo que podrías recuperar con el volumen mensual, la duración actual, la parte automatizable y los minutos de revisión que permanecerían por caso. El resultado compara capacidad de trabajo; no clasifica mensajes ni demuestra ahorro real. Una integración necesita comprobar esas entradas con casos observados.

Una integración posterior necesita definir fuentes, permisos, datos enviados al proveedor, registro de errores y quién opera el flujo. El costo de construir y el costo de usarlo son partidas distintas. Incluye alojamiento, mantenimiento y consumo de servicios cuando correspondan; no se pueden calcular sin alcance y volumen de uso.

Define qué significa funcionar

• Finalización de tarea: intentos que completan la tarea / intentos observados, con el mismo criterio.
• Tiempo por tarea: desde el inicio hasta la confirmación, incluyendo revisión. Reporta mediana y muestra.
• Corrección de categoría: coincidencias con una etiqueta revisada por una persona / casos evaluados.
• Revisión humana: casos derivados a revisión / casos procesados.
• Costo por tarea aceptada: costo de operación del periodo / salidas aceptadas del mismo periodo.

La derivación a revisión puede ser correcta: no debe esconderse para que el porcentaje parezca mejor. Añade un recuento de errores que llegan a la confirmación. Si pruebas IA, separa evaluación de clasificación y evaluación del borrador; acertar una categoría no demuestra que el texto de respuesta sea adecuado.

Prepara casos normales, incompletos, ambiguos y ajenos al servicio. Incluye instrucciones dentro del mensaje que intenten cambiar las reglas. Esta forma de evaluación sigue el principio de definir tarea, ejemplos y criterios antes de comparar versiones. Buenas prácticas de evaluación de OpenAI.

Compara el proceso, no solo la interfaz

Para establecer una referencia, observa la tarea manual con el mismo tipo de casos que usarás en el prototipo. Registra tiempo, errores y dudas. Después observa el recorrido asistido incluyendo correcciones: no compares el proceso manual completo con una respuesta automática sin revisar.

Las primeras sesiones sirven para encontrar pasos confusos. No prueban por sí solas un ahorro mensual ni permiten extrapolar un porcentaje de mejora a toda la empresa. Conserva los ejemplos y explica qué cambió entre versiones para que la siguiente prueba sea interpretable.

Sal del prototipo con una decisión concreta

Puedes descubrir que necesitas una landing mejor, un pequeño panel, una regla entre herramientas o una evaluación de IA. Cada resultado orienta el trabajo. Si el paso difícil sigue siendo acordar quién responde, desarrollar una app completa no resuelve esa decisión operativa.

Lleva al brief una tarea, un ejemplo de entrada, la salida esperada, un caso que debe detenerse y la persona responsable de revisarlo. Con eso podemos definir un producto web o app o evaluar una automatización con IA.