Descubre cómo mapear el ciclo de vida de una solicitud de cliente antes de diseñar las pantallas, con estados claros, responsables, plazos y notificaciones que los equipos puedan seguir.
Un formulario de solicitudes bien diseñado puede generar un proceso caótico. Los equipos suelen elegir primero los campos, botones y paneles, y después descubren que nadie se puso de acuerdo sobre lo que ocurre cuando un cliente hace clic en «Enviar».
Las pantallas muestran momentos concretos. El ciclo de vida de una solicitud de cliente muestra el recorrido completo: dónde llega la solicitud, quién la revisa, qué decisión toma, cuándo comienza el trabajo y qué se considera un cierre. Sin ese mapa, cada pantalla puede tener sentido por separado, mientras que el trabajo entre una pantalla y otra sigue sin estar claro.
Piensa en un formulario de soporte con un estado llamado «En curso». ¿Significa que alguien leyó la solicitud, que se la asignaron, que contactó con el cliente o que empezó el trabajo? El personal puede usar la misma etiqueta de distintas maneras. Los clientes ven pocos avances y los responsables no pueden saber dónde se atascan las solicitudes.
Empezar por las pantallas también oculta los traspasos. Una solicitud puede pasar de soporte a facturación y después a un gestor de cuentas. Si el equipo no ha definido quién es el responsable en cada paso, todos pueden suponer que otra persona actuará. Las solicitudes terminan en una cola compartida hasta que el cliente vuelve a preguntar.
El mapa del flujo de solicitudes revela estas carencias antes de comenzar el diseño de la interfaz. El equipo debe decidir:
El mapa también evita crear paneles engañosos. Un recuento de solicitudes «abiertas» dice poco si incluye elementos nuevos, solicitudes que esperan información del cliente y trabajos bloqueados por otro equipo. Los estados separados dan al personal un lenguaje común y ofrecen a los clientes una actualización más honesta.
El mapa no tiene que ser complicado. Tiene que describir el trabajo que las personas realizan de verdad, incluidos los datos que faltan, las solicitudes rechazadas y los casos reabiertos. Cuando el recorrido está claro, es más fácil diseñar las pantallas porque cada página tiene una función concreta: recopilar información, ayudar al responsable a actuar o mostrar al cliente en qué punto está su solicitud.
Comienza por la solicitud que tu equipo recibe con más frecuencia. Puede ser una petición de reembolso, un informe de entrega dañada o una solicitud para cambiar los datos de una cuenta. No intentes representar todas las necesidades de los clientes en un solo diagrama. Los mapas demasiado amplios se vuelven imprecisos enseguida.
Escribe el evento inicial con un lenguaje sencillo. Por ejemplo: «Un cliente envía una solicitud de reembolso de un pedido mediante el formulario de soporte». Así estableces cuándo comienza el ciclo de vida. También evitas una discusión habitual más adelante: ¿la solicitud empieza cuando el cliente la envía, cuando soporte la lee o cuando alguien crea un ticket?
Después, define el punto final desde ambas perspectivas. Una solicitud de reembolso completada significa que el cliente ha recibido una decisión clara y que, si se aprueba, el equipo de pagos ha emitido el reembolso. El equipo de soporte también necesita un registro de la decisión, el motivo, el importe y la fecha. Estos datos son más importantes que una pantalla que diga «Completado».
Mantén el resultado separado de la interfaz. «Mostrar un mensaje verde de confirmación» describe una pantalla. «El cliente recibe una confirmación con el importe del reembolso y la fecha prevista de pago» describe el trabajo que debe realizarse. La pantalla puede cambiar durante un rediseño. El trabajo subyacente debe seguir siendo el mismo, tanto si el cliente utiliza un portal web, una aplicación móvil o el correo electrónico.
Una definición breve suele revelar reglas que faltan antes de comenzar el diseño:
Supón que un cliente informa el lunes de un cargo duplicado. La solicitud solo debe terminar cuando el equipo confirme si el cargo se duplicó, envíe la decisión y registre el reembolso, si corresponde. Cerrar el ticket después de la primera respuesta deja el trabajo real sin resolver.
Cuando este recorrido tiene un inicio y un final precisos, el equipo puede añadir estados, responsables, plazos y notificaciones sin hacer suposiciones. AppMaster puede convertir después ese mapa en procesos de negocio y pantallas, pero el mapa debe definir primero el trabajo.
Un estado indica a todos en qué punto se encuentra una solicitud de cliente. Mantén la lista centrada en momentos relevantes del trabajo, no en cada pequeña acción. El personal debe poder leer un estado y saber qué tiene que ocurrir después.
Una solicitud habitual de soporte o servicio puede incluir estos estados:
Usa nombres que coincidan con el lenguaje que las personas ya emplean. «Esperando al cliente» es más claro que «Pendiente de información». «En curso» suele ser más claro que «Activa». Los clientes no deberían necesitar un glosario interno para entender el estado que aparece en un portal.
Los estados de espera requieren especial atención. Separan el trabajo que tu equipo puede hacer hoy del trabajo que depende de otra persona. Una solicitud de reembolso puede pasar de «En revisión» a «Esperando al cliente» cuando el cliente debe proporcionar un recibo. Si un responsable de finanzas tiene que aprobar el importe, pasa a «Esperando aprobación». Estos retrasos necesitan recordatorios y reglas de plazos diferentes.
Evita las etiquetas duplicadas. «Abierta», «Asignada» y «En gestión» suelen describir la misma situación general. Conserva un solo estado, salvo que cada etiqueta cambie el responsable, la acción del personal o el plazo aplicable. Menos estados y transiciones, pero más claros, también hacen que los informes sean más fiables.
Prueba cada solicitud con una pregunta sencilla: ¿puede estar en dos estados a la vez? Si es así, es posible que los nombres se solapen. Modifícalos hasta que cada estado describa una condición clara.
El nombre de un estado no explica por sí solo un flujo de trabajo. Registra cómo se mueve una solicitud, quién puede moverla y qué debe cumplirse antes. Así evitas que un botón de la pantalla cambie una solicitud en el momento equivocado.
Escribe cada transición como una frase sencilla. Por ejemplo: «Un agente de soporte pasa una solicitud de Nueva a En revisión después de comprobar que el cliente ha incluido un número de pedido». La frase indica la acción, la persona que la realiza y la condición necesaria.
Un mapa sencillo puede incluir estos movimientos:
Define el actor permitido para cada flecha. «El equipo» es demasiado impreciso. Usa roles como cliente, agente de soporte, especialista de facturación, responsable de equipo o automatización. Una regla del sistema también puede activar un cambio. Por ejemplo, una automatización puede pasar una solicitud de Esperando al cliente a Cerrada después de 14 días sin respuesta, si esa es la política de tu empresa.
Las excepciones necesitan sus propias transiciones. Un cliente puede cancelar una solicitud Nueva, pero no una que ya se ha completado. Un responsable de equipo puede reabrir una solicitud Cerrada si el problema vuelve a aparecer. Un agente puede devolver una solicitud de En revisión a Nueva solo si se asignó por error. Estas reglas protegen la responsabilidad sobre la solicitud y explican por qué algunos cambios de estado no están disponibles.
Dibuja el recorrido con cuadros y flechas antes de diseñar las pantallas. Busca bucles que nunca terminan, como dos roles que se devuelven la solicitud continuamente. Comprueba también que no haya callejones sin salida. Si una solicitud pasa a Esperando aprobación, define quién aprueba y qué ocurre después de la aprobación o el rechazo.
En AppMaster, el mapa puede convertirse más adelante en lógica de procesos de negocio, mientras que los roles controlan qué acciones ve cada usuario. El mapa debe ser lo bastante claro para que un nuevo miembro del equipo pueda seguir una solicitud desde el envío hasta el cierre.
Una solicitud necesita un responsable identificado siempre que el trabajo esté activo. Esa persona no tiene que completar todas las tareas por sí sola. Sí debe conocer el estado actual, hacer avanzar la solicitud y responder cuando alguien pida una actualización. La responsabilidad compartida suele acabar en que nadie actúe.
El responsable puede cambiar a medida que avanza la solicitud. Un agente de soporte puede encargarse de una solicitud nueva, un especialista puede dirigir la investigación y un gestor de cuentas puede encargarse de la respuesta final al cliente. Incluye cada cambio en el mapa para que el personal no tenga que deducir quién debe actuar.
Mantén separado al responsable de la solicitud de las personas que revisan y aprueban. Un responsable de finanzas puede aprobar un reembolso, pero el agente de soporte puede seguir siendo el responsable de la solicitud. El agente pide la aprobación, controla la respuesta e informa al cliente del resultado. El responsable de finanzas no debería hacerse cargo de todos los seguimientos solo porque hizo clic en «Aprobar».
En cada traspaso, registra el responsable y el equipo activos, el motivo del cambio, el trabajo necesario antes de la siguiente transición y la persona que se hará cargo si el responsable no está disponible.
Planifica las ausencias antes de que provoquen retrasos. Usa una cola de equipo, un sustituto identificado o una regla que reasigne las solicitudes después de un periodo determinado. Si un especialista está de permiso, otra persona debería ver la solicitud en su cola, en lugar de dejarla asignada a alguien que no puede responder.
Haz visible la responsabilidad en la aplicación. Los mensajes privados y los hilos de correo pueden ayudar a realizar el trabajo, pero no deberían definir el flujo de trabajo. Cada registro de solicitud debe mostrar al responsable actual, el traspaso anterior, la hora de asignación y el motivo de la reasignación. Así los responsables pueden detectar las solicitudes que llevan demasiado tiempo esperando y el personal de cara al cliente puede informar sin buscar entre los mensajes.
Por ejemplo, cuando un cliente informa de un error de facturación, el agente de soporte es responsable hasta confirmar que finanzas debe revisarlo. Entonces el analista financiero se encarga de la investigación. Cuando finanzas registra una decisión, la responsabilidad vuelve a soporte para responder al cliente y cerrar la solicitud. Esto evita que dos personas envíen respuestas distintas o que ambas supongan que la otra ya respondió.
Cuando construyas el flujo en una aplicación, incluye los cambios de responsable en la propia transición de estado. AppMaster puede conectar en un mismo proceso de negocio el cambio de estado, la regla de asignación y el registro de auditoría. Esto ayuda a mantener clara la responsabilidad a medida que crece el equipo.
Una solicitud suele necesitar dos plazos. El plazo de respuesta cubre la primera respuesta útil, como confirmar que un agente de soporte ha leído la solicitud y necesita más datos. El plazo de resolución cubre el momento en que el equipo resuelve la solicitud o entrega el resultado acordado.
Separar estas fechas evita un problema habitual: el cliente recibe una confirmación rápida, pero la solicitud permanece sin atención durante días. Una solicitud de acceso puede requerir una respuesta en cuatro horas laborables y completarse en dos días laborables. Una disputa de facturación compleja puede necesitar una respuesta en un día laborable y un plazo de resolución más largo.
Escribe exactamente cuándo comienza cada contador. Muchos equipos inician el plazo de respuesta cuando el sistema recibe la solicitud. El plazo de resolución puede empezar al mismo tiempo o solo cuando el equipo dispone de información suficiente para trabajar. Elige una regla y aplícala de forma coherente.
Define las pausas con el mismo cuidado. Un contador puede pausarse mientras la solicitud espera la respuesta del cliente, la aprobación de un tercero o una ventana de mantenimiento programada. Debe reanudarse cuando llega la información que faltaba o termina el bloqueo. No pauses un plazo porque la persona asignada esté ocupada o ausente. El responsable o el gestor debe reasignar el trabajo.
Añade un escalado antes de que se acerque el plazo. Un recordatorio al responsable cuando haya transcurrido el 75 % del tiempo permitido le da margen para actuar. Al llegar al 90 %, avisa a su responsable o al siguiente equipo encargado. Si se supera el plazo, marca la solicitud como atrasada e indica la siguiente acción.
Una política sencilla podría funcionar así:
Usa solo horas laborables si todos aceptan el calendario que hay detrás. Un equipo que promete ayuda los siete días de la semana no debería detener el contador en silencio cada tarde. Si soporte trabaja de lunes a viernes, define en las reglas del flujo el horario laboral, los festivos y la zona horaria. Las reglas claras hacen que las notificaciones de plazos sean justas para clientes y personal.
Las notificaciones deberían responder a una pregunta práctica: ¿alguien necesita saber algo o hacer algo ahora? Si no, conserva la actualización dentro del registro de la solicitud. Una bandeja de entrada llena de avisos enseña a clientes y empleados a ignorar los mensajes, incluidos los importantes.
Envía un mensaje al cliente cuando la solicitud cambie de una forma que le afecte. Los momentos habituales son la confirmación de recepción, una petición de más información, la aprobación o el rechazo de una solicitud, un cambio en la fecha prevista de finalización y la conclusión del trabajo. No avises al cliente porque un empleado haya corregido un error tipográfico, añadido una nota interna o reasignado una tarea sin cambiar el resultado esperado.
Las alertas internas también necesitan un responsable y un motivo para actuar. Cuando una solicitud pase a «Necesita revisión», avisa al revisor. Cuando un cliente responda a una pregunta, avisa a la persona asignada para continuar. El equipo completo no necesita una alerta por ninguno de estos eventos.
Mantén los mensajes sencillos y específicos. Nombra la solicitud, indica su estado actual y explica qué ocurrirá después. Por ejemplo:
El momento importa tanto como el texto. Un recordatorio de plazo debe llegar a la persona asignada con tiempo suficiente para actuar, no cinco minutos antes de que termine el plazo. Para una ventana de revisión de dos días, normalmente basta con un recordatorio el día anterior y otro después de superar el plazo. Cuando el responsable termina el trabajo, la aplicación debe detener los recordatorios pendientes.
Registra las reglas de notificación junto a cada transición del mapa. Indica quién recibe el mensaje, qué evento lo activa, por qué canal se envía y si la aplicación necesita un recordatorio. Así el comportamiento queda claro antes de construir una pantalla o escribir una automatización.
Un cliente informa de un cargo duplicado mediante un formulario de soporte. El formulario crea la solicitud n.º 4821 con el estado «Nueva» y la asigna a la cola de soporte. El cliente recibe una confirmación inmediata con el número de solicitud y una nota que indica que el equipo revisará el caso en el plazo de un día laborable.
Un agente de soporte abre la solicitud, comprueba el pedido y el registro de pago, y cambia el estado a «En revisión». El agente es el responsable de la solicitud. Si los registros de pago no contienen suficiente información, selecciona «Esperando al cliente» y solicita una captura del extracto bancario o los cuatro últimos dígitos de la tarjeta.
Ese estado necesita un plazo. La aplicación puede recordar al cliente la solicitud después de tres días y cerrar el caso después de siete días sin respuesta. El agente debe recibir una notificación cuando el cliente añada los datos que faltaban, para que la solicitud no pase desapercibida en una cola.
Cuando el cliente responde, la solicitud vuelve a «En revisión» y, siempre que sea posible, regresa al mismo agente. La continuidad importa porque un agente nuevo no debería repetir las mismas preguntas.
Si el agente confirma el cargo duplicado, pasa la solicitud a «Decisión sobre el reembolso» y la asigna a un revisor financiero. Finanzas tiene dos días laborables para aprobar o rechazar el reembolso. Un recordatorio un día antes del plazo da tiempo al revisor para actuar antes de que el cliente tenga que pedir una actualización.
El revisor financiero registra la decisión. Una solicitud aprobada pasa a «Procesando reembolso», donde el equipo de pagos emite el reembolso e introduce su número de referencia. Una solicitud rechazada vuelve a soporte con un motivo que el agente puede explicar con claridad.
Soporte envía el mensaje final solo después de que el equipo haya emitido el reembolso o explicado el rechazo. Entonces el agente cambia el estado a «Cerrada». El cliente recibe un aviso de cierre con el resultado, mientras que el equipo conserva un registro de cada responsable, decisión, plazo y mensaje.
Este mapa evita una carencia habitual: una solicitud que parece terminada en una pantalla, pero sigue esperando una acción en la cola de otro equipo.
La mayoría de los flujos de solicitudes se vuelven confusos porque las etiquetas parecen claras para quienes las diseñaron, pero no para quienes las usan cada día. Un estado llamado «Pendiente» puede significar que el cliente no ha respondido, que un responsable debe aprobar el trabajo o que un técnico está esperando piezas. Cada situación necesita un siguiente paso diferente.
Sustituye las etiquetas imprecisas por estados que expliquen la espera. «Esperando los datos del cliente» indica al solicitante qué debe hacer. «Esperando la aprobación del responsable» indica al responsable qué bloquea el avance. Si el equipo no puede decir quién debe actuar después, cambia el nombre del estado o elimínalo.
La responsabilidad es otra fuente frecuente de problemas. Una solicitud puede implicar a soporte, finanzas y operaciones, pero varios nombres no crean responsabilidad compartida. Define un responsable para cada estado activo. Esa persona puede pedir ayuda a otros y seguir siendo responsable de hacer avanzar la solicitud o explicar el retraso.
Un plazo necesita una acción asociada. Una fecha límite que solo envía un recordatorio sirve de poco cuando nadie responde. Define qué ocurre cuando se acaba el tiempo: avisar al responsable, escalar el caso a un gestor o mover la solicitud a una cola de revisión. Adapta la acción al impacto del retraso.
No construyas pantallas solo porque un estado parezca útil. Cada pantalla debe apoyar una tarea, decisión o transferencia clara. Una pantalla de «Revisión de calidad» tiene sentido solo si alguien comprueba criterios definidos y aprueba la solicitud o la devuelve con un motivo. Si el equipo no puede explicar esa acción de forma sencilla, elimina el estado en lugar de ocultar la incertidumbre detrás de otra página.
Antes de diseñar las pantallas, comprueba cada parte del ciclo de vida con cuatro preguntas:
Esta comprobación revela pronto las carencias. También facilita convertir el mapa del flujo de solicitudes en una aplicación, porque cada estado tiene un propósito, un responsable y una acción definida.
Un mapa de solicitudes debe superar una revisión sencilla antes de que nadie abra un constructor de interfaces. Léelo como si fueras un empleado que gestiona una solicitud real un martes con mucho trabajo. Si no puedes saber qué ocurre después, una pantalla no resolverá la carencia.
Asigna a cada estado una función clara y al menos una salida. «Esperando al cliente» significa que el equipo necesita información, por lo que debería cambiar cuando el cliente responda, cancele o no responda en la fecha acordada. Evita estados que solo describan una sensación general, como «En curso», salvo que el equipo sepa exactamente qué trabajo se realiza allí.
Revisa cada transición preguntando qué la activa y quién puede realizarla. Un agente de soporte puede marcar una solicitud como resuelta después de enviar una respuesta. Un cliente puede reabrirla. Una regla del sistema puede cerrarla después de 14 días sin respuesta. Escribe estos permisos para que nadie cambie solicitudes por accidente.
Usa esta lista de revisión:
Comprueba la responsabilidad en los traspasos, donde suele comenzar la confusión. Si un agente de soporte envía un problema técnico a ingeniería, la solicitud necesita un nuevo responsable identificado. El agente original puede seguir como observador, pero ninguno de los dos debe suponer que el otro responderá.
Mantén prácticas las notificaciones de plazos. Envía un recordatorio interno antes de la fecha límite y escala el caso solo si la solicitud sigue abierta. Informa a los clientes cuando necesites su participación, cuando la solicitud pase a otro equipo y cuando el equipo la resuelva o cierre. No les avises de cada nota interna.
Cuando el mapa se entienda claramente sobre el papel, las pantallas tendrán una función concreta: mostrar el estado, las acciones, el responsable y la fecha límite adecuados a la persona correcta.
Cuando el ciclo de vida de la solicitud de cliente está claro, cada parte del mapa tiene un lugar directo en la aplicación. Los estados se convierten en un campo de estado. Los responsables pasan a ser usuarios o equipos asignados. Los plazos se convierten en campos de fecha y hora. Las transiciones se convierten en acciones como «Asignar», «Pedir datos», «Resolver» y «Reabrir».
Mantén sencilla la primera versión. Una pantalla de solicitud normalmente necesita el cliente, el tipo de solicitud, la descripción, el estado actual, el responsable asignado, la fecha límite, el historial de actividad y los archivos. Una cola separada puede mostrar a cada persona las solicitudes que requieren su atención.
El flujo de trabajo debe controlar las acciones, no limitarse a mostrar una etiqueta. Un agente de soporte puede pasar una solicitud de «Nueva» a «En revisión». Solo el responsable asignado puede marcarla como «Resuelta». Si un cliente responde después de la resolución, la aplicación puede reabrir la solicitud y devolverla a la cola adecuada.
Antes de construir todas las pantallas, prueba una versión funcional con las personas que reciben y resuelven solicitudes reales. Pídeles que completen casos habituales, un caso urgente y una solicitud a la que le falte información. Observa los momentos en que no encuentran una acción, no saben quién es el responsable o necesitan salir de la aplicación para hacer una pregunta.
Usa esos comentarios para corregir el mapa y la pantalla. Un traspaso que confunde a dos equipos puede necesitar un estado como «Esperando aprobación». Una solicitud que tarda demasiado puede necesitar una fecha límite más clara o un recordatorio para su responsable. No añadas estados para describir cada pequeña actividad. Demasiadas opciones hacen que el flujo sea más difícil de seguir.
AppMaster puede convertir este diseño en una aplicación de solicitudes no-code. Su Data Designer puede modelar solicitudes, usuarios, equipos, plazos e historial de estados. El Business Process Editor puede definir asignaciones, cambios de estado, recordatorios y escalados, mientras que las pantallas web o móviles nativas pueden ofrecer colas de solicitudes, vistas detalladas e informes para responsables.
Empieza con un tipo de solicitud y un grupo pequeño de usuarios. Cuando puedan crear, asignar, actualizar y cerrar solicitudes sin soluciones improvisadas, añade el siguiente tipo. El resultado será una aplicación que apoya el trabajo real en un día ajetreado, en lugar de limitarse a mostrar pantallas atractivas que dejan a las personas sin saber qué hacer.
14 jul 2026
10 min
13 jul 20269 min
08 jul 20267 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
