Una hoja de cálculo da paso a tarjetas de borrador, revisión y aprobación

El portal debe mostrar el paso entre estados y la decisión que permite avanzar.

Descubre dónde dejó de ayudar la hoja

Una hoja de cálculo puede ser suficiente mientras el equipo encuentre la versión correcta, entienda el estado del trabajo e identifique a la siguiente persona que debe actuar. El cambio empieza a tener sentido cuando estas tareas exigen aclaraciones repetidas. Registra esas dificultades antes de decidir que necesitas una aplicación propia.

Imagina un equipo que prepara propuestas comerciales en una hoja compartida. Cada fila tiene el cliente, un documento, un responsable y una celda de aprobación. Al cabo de un tiempo, el responsable necesita preguntar en el chat si el documento enlazado es la última versión y si el comentario se refiere al precio actual.

Es un ejemplo hipotético, pero plantea una pregunta concreta para investigar: ¿qué información queda fuera del registro? Si las decisiones viven en mensajes, archivos distintos y colores cuyo significado varía, la hoja ya no permite reconstruir el proceso. El equipo dedica esfuerzo a confirmar el estado antes de poder trabajar.

También interesa observar quién utiliza la hoja y en qué contexto. Una revisión desde el móvil puede exigir abrir un documento, ampliar una imagen y volver a la celda para escribir. El diseño de un portal debe reducir ese recorrido concreto, en lugar de presentar la misma cuadrícula con colores diferentes.

Yo empezaría por seguir algunas solicitudes completas, desde su preparación hasta la decisión final. Anotaría dudas, versiones confundidas y pasos manuales. Esta observación aporta material para planificar una aplicación antes de empezar a programar y permite explicar a la IA qué debe mejorar sin pedirle que invente el proceso.

Para preparar el siguiente paso, consulta Desarrollar aplicaciones con IA.

Define qué significa cada estado

Los estados deben representar situaciones diferentes y tener condiciones claras de entrada y salida. Borrador, en revisión, cambios solicitados y aprobado pueden bastar para empezar. Para cada paso, define quién actúa, qué debe estar completado y qué información queda guardada después de la decisión para que otros puedan entenderla.

“En revisión” puede significar que el autor ha terminado la preparación y ha entregado una versión concreta a otra persona. Si todavía faltan anexos obligatorios, la solicitud sigue en borrador. Esta distinción evita que el revisor reciba trabajo incompleto y tenga que descubrir por su cuenta si puede empezar a evaluarlo.

“Cambios solicitados” debe incluir un motivo que permita actuar. En el ejemplo de la propuesta, escribir “revisar el precio de la segunda opción” es más útil que cambiar únicamente el color de la fila. El autor sabe qué debe corregir y el revisor puede confirmar después si se ha atendido la observación.

La aprobación debe quedar asociada a la versión examinada. Si alguien cambia el importe, el texto o un anexo relevante después de aprobar, define si la decisión anterior sigue siendo válida. Yo devolvería la nueva versión a revisión cuando el cambio afecte a lo aprobado. El historial anterior continúa disponible.

Escribe estas reglas con ejemplos de transiciones permitidas y prohibidas. Una persona puede retirar un borrador; quizá no deba archivar silenciosamente una solicitud ya aprobada. No existe una secuencia universal para todas las empresas. El portal debe representar las responsabilidades acordadas para ese trabajo, incluidas las excepciones que suceden realmente.

Separa preparar, revisar y decidir

Los permisos deben corresponder a la responsabilidad de cada persona en el proceso. Quien prepara puede necesitar editar; quien revisa puede pedir ajustes; quien aprueba toma una decisión con un efecto definido. Aclara si una persona puede acumular funciones y cómo confirma el sistema esa autorización antes de aceptar un cambio.

Un botón oculto no demuestra que la acción esté protegida. La aplicación debe comprobar en el servidor si esa persona puede modificar esa solicitud, aunque el intento llegue por otro camino. Esto es especialmente relevante cuando el portal guarda información de distintos clientes o algunos colaboradores solo participan en determinados proyectos.

Define también la sustitución del responsable. Si la persona que aprueba está ausente, ¿quién puede asumir su función y quién autoriza el cambio? Sin una regla, el equipo puede empezar a compartir accesos o pedir que otra persona apruebe en su nombre. El historial deja entonces de explicar quién tomó realmente la decisión.

El criterio es parecido al de definir quién aprueba qué en un proyecto con un equipo externo. La herramienta debe mostrar el límite de cada intervención y preservar la autoridad de quien decide. Comentarios, preparación y aprobación pueden coexistir sin confundirse en un único permiso de edición.

La IA puede ayudar a resumir observaciones o preparar una propuesta de cambio. Eso no le da automáticamente autorización para marcar la solicitud como aprobada. Si añades esa ayuda, muestra qué se ha sugerido y conserva la decisión en el punto del proceso que hayas definido para la persona responsable.

Etapas que separan la preparación por IA, la validación humana y la ejecución autorizada

Preparar un cambio y autorizar que avance son decisiones distintas que el portal debe registrar.

Construye la primera versión alrededor de una solicitud completa

La primera versión debe permitir completar un tipo de solicitud de principio a fin, incluida una devolución para realizar ajustes. Muestra el material que se revisa, la versión, el responsable y las acciones disponibles. Prueba este recorrido antes de añadir informes o integraciones que dependan de estados todavía poco claros para el equipo.

En el ejemplo hipotético, el revisor abriría la propuesta y encontraría el importe, el documento y las condiciones necesarias para decidir. Podría aprobar o pedir una corrección sin buscar información en otras conversaciones. El autor recibiría la observación en la misma solicitud, vinculada a la versión que se estaba evaluando.

Al trasladar datos desde la hoja, no deduzcas aprobaciones a partir de celdas ambiguas. Una fila verde puede significar “enviado” para una persona y “aprobado” para otra. Conserva el registro original e identifica los casos que necesitan confirmación antes de asignarles un estado con consecuencias en el portal.

Prueba también situaciones simultáneas: el autor cambia el documento mientras el revisor tiene abierta la versión anterior. La aplicación debe impedir que una decisión sobre información antigua apruebe silenciosamente el contenido nuevo. Es una regla concreta para entregar a quien implementa y comprobar después con dos sesiones de prueba.

Incluye el móvil y los errores en el ensayo. Un anexo que no se abre, una sesión caducada o una conexión lenta no deben dejar a la persona pensando que ha aprobado cuando la decisión no se ha guardado. La confirmación presentada debe corresponder al resultado efectivo, con una forma clara de volver a intentarlo.

Confirma si el portal ha aclarado la decisión

Evalúa el portal por la capacidad de encontrar la solicitud correcta, comprender qué falta y completar la decisión sin reconstruir conversaciones. Compara estos recorridos con la situación inicial y recoge las dificultades del equipo. La adopción solo queda demostrada cuando las personas pueden trabajar en el nuevo proceso y el historial sigue siendo comprensible.

Yo observaría cuántas solicitudes necesitan aclaraciones sobre versión, responsable o estado. Separaría el tiempo de preparar una revisión del tiempo que el trabajo pasa esperando una decisión. Un portal puede simplificar la preparación sin resolver una regla interna que hace depender todas las aprobaciones de la misma persona.

Después de la prueba, elige una fecha para dejar de utilizar la hoja como registro actual y consérvala como archivo consultable. Mantener dos fuentes en paralelo sin una regla crea decisiones contradictorias. El equipo necesita saber dónde se registra un cambio y qué historial prevalece cuando los registros difieren.

Hay mantenimiento después de la entrega: gestionar accesos, ajustar campos, recuperar información y corregir fallos. Define quién se encarga de estas tareas y cómo se exportan los datos. La posibilidad de construir software a medida no elimina el trabajo de mantenerlo utilizable cuando cambian el equipo o el proceso.

Este es un uso concreto de IA en los procesos del negocio más allá del chatbot. La hoja ayuda a descubrir el proceso; el portal puede facilitar su ejecución y seguimiento. El paso merece la pena cuando elimina dudas reales sin perder las decisiones y responsabilidades que exige el trabajo.