De solicitudes por correo a un flujo digital trazable
Una solicitud llega por correo, pasa por varias áreas y termina en una cadena donde nadie sabe quién debe actuar. Convertir ese recorrido en un flujo digital exige acordar responsables, estados y evidencias de cierre antes de elegir una herramienta o diseñar pantallas.
Cuando conocer el avance de una solicitud obliga a buscar mensajes, comparar archivos y preguntar a varias personas, el seguimiento depende de reconstruir la conversación. El correo conserva intercambios, pero corresponde al equipo identificar qué se decidió, cuál es la información vigente y quién tiene el siguiente paso. Si alguien se ausenta, esa reconstrucción puede volverse todavía más difícil.
La trazabilidad es la posibilidad de consultar el recorrido de una solicitud: cuándo ingresó, quién la atendió, qué decisiones recibió y con qué evidencia se cerró. Para conseguirla, cada caso necesita una identidad propia y reglas de atención compartidas. La trazabilidad se diseña en la operación y después se expresa en la herramienta; por eso, agregar un formulario es apenas una parte del cambio.
El correo puede seguir siendo la puerta de entrada
Antes de cambiar de canal, conviene localizar la pérdida de control. Una solicitud puede llegar incompleta, quedar sin asignación o recibir respuestas contradictorias. También puede avanzar correctamente hasta una aprobación que nadie sabe quién debe emitir. Cada situación exige un acuerdo operativo distinto; reunirlas bajo la necesidad de una plataforma impide entender qué debe resolver esa plataforma.
Puedes escuchar este artículo aquí:
El correo puede mantenerse como entrada si cada mensaje inicia o actualiza un caso dentro de un registro compartido. La documentación de Jira Service Management describe este funcionamiento: las solicitudes recibidas por correo pueden convertirse en elementos de trabajo rastreables y sus comentarios incorporarse al mismo registro. La posibilidad existe; su utilidad depende de las necesidades y la configuración de cada organización.
El cambio relevante consiste en establecer dónde se consulta la información vigente. Si una aprobación llega por correo, debe quedar vinculada al caso; si una llamada modifica el alcance, alguien debe registrar el acuerdo. De otro modo, el equipo terminará manteniendo versiones distintas del trabajo, aunque disponga de una herramienta nueva.
“Reenviar una solicitud no equivale a asignar su responsabilidad.”
Cada solicitud necesita identidad, responsable y reglas para avanzar
Imaginemos una empresa que recibe solicitudes de mantenimiento. Una persona reporta una falla, administración pide su ubicación y un técnico revisa el problema. Después se solicita una cotización y el trabajo queda pendiente de autorización. En este escenario hipotético, centralizar los mensajes ayuda, pero todavía falta decidir quién conduce el caso y qué permite avanzar.
El primer paso sería asignar un folio único que vincule el reporte, los archivos, las respuestas y las decisiones. Una respuesta sobre el mismo problema debería actualizar ese caso. Si llegan dos reportes del mismo incidente, el equipo necesita una regla para relacionarlos y evitar que se atiendan por separado sin advertir la duplicación.
Después hay que definir estados con significado operativo. Recepción, revisión, espera de autorización, atención y resolución pueden servir como punto de partida, siempre que cada uno indique quién responde y qué falta. Un caso en espera de autorización debería mostrar quién debe decidir, qué información tiene disponible y desde cuándo está pendiente su respuesta.
Las excepciones también forman parte del recorrido. Cuando faltan datos, debe quedar claro quién los solicita y quién los entrega. Si cambia el responsable, la persona que retoma el caso necesita recibir el contexto y el siguiente compromiso. Si un pendiente supera el tiempo acordado, debe estar definido cuándo interviene otra persona y con qué atribuciones.
El historial debe explicar las decisiones y el cierre
El estado actual muestra dónde está una solicitud; el historial permite entender cómo llegó ahí. En el caso de mantenimiento, convendría conservar cuándo se asignó el trabajo, qué cotización se autorizó y por qué cambió una fecha. Las correcciones deben poder reconocerse sin borrar el contexto que explica las decisiones anteriores.
La guía de registros de aplicaciones de OWASP recomienda capturar información suficiente sobre cuándo, dónde, quién y qué ocurrió. También señala datos que deben excluirse o protegerse, como contraseñas e información sensible. Este criterio ayuda a pensar el historial, pero cada empresa debe determinar qué eventos necesita conservar, quién puede consultarlos y durante cuánto tiempo.
El cierre merece una regla propia. Reportar que un técnico terminó su tarea puede requerir una descripción del trabajo y evidencia pertinente; confirmar que la necesidad quedó atendida puede exigir otra validación. La organización debe decidir qué considera resuelto, cómo comunica el resultado y en qué condiciones permite reabrir el caso.
“Un flujo es trazable cuando permite explicar qué ocurrió, quién decidió y qué falta para resolver.”
Puedes ver este artículo aquí:
La interfaz debe mostrar qué ocurre y qué hacer después
Quien solicita necesita saber si su reporte fue recibido, qué ocurre ahora y si debe aportar algo. Quien atiende necesita reconocer sus pendientes, los bloqueos y la siguiente acción. Estas necesidades deben orientar las pantallas: cada persona debería encontrar la información y las acciones que requiere para cumplir su tarea, con permisos acordes con su responsabilidad.
Las notificaciones deben distinguir entre informar y pedir una acción. Un aviso de aprobación pendiente necesita explicar qué se autoriza, quién debe hacerlo y dónde puede consultar los antecedentes. También conviene confirmar la recepción con un folio: así, la persona puede dar seguimiento sin volver a describir el problema ni enviar otra solicitud por incertidumbre.
Probar el recorrido completo antes de ampliar la solución
Un piloto puede concentrarse en un tipo de solicitud frecuente. Antes de configurarlo, el equipo debería acordar su inicio, el resultado esperado, los estados, las responsabilidades y las excepciones. También debe decidir cómo incorporará los casos que ya están abiertos y desde qué momento el registro compartido será la referencia para consultar su avance.
La evaluación necesita indicadores con límites claros. Para medir el tiempo de resolución, por ejemplo, hay que acordar cuándo empieza y termina el conteo. Medir desde la recepción hasta el cierre validado permite observar un recorrido distinto al que va desde la asignación al técnico hasta que reporta su trabajo. Ambos pueden aportar información, pero responden preguntas diferentes y deben distinguirse.
El Service Manual de GOV.UK recomienda combinar métricas con investigación de usuarios y otras fuentes para comprender el desempeño de un servicio. En el piloto, esto implica revisar los tiempos junto con las dificultades de quienes solicitan y atienden. Conviene incluir casos incompletos, reasignaciones y reaperturas para comprobar si el proceso conserva su claridad cuando aparecen complicaciones.
Con esa evidencia será más fácil decidir si basta configurar una solución existente o si hay necesidades que justifican desarrollo propio. La señal de avance será que otra persona pueda retomar un caso, comprender sus decisiones y continuar el trabajo sin reconstruirlo entre bandejas de entrada. ¿En qué paso se pierde hoy el seguimiento de sus solicitudes y qué tendría que quedar registrado para recuperarlo?
¿Tu idea necesita más claridad antes de convertirse en código? En Señor Zorro, estudio de diseño de productos digitales, te ayudamos a definir, validar y diseñar productos digitales listos para desarrollo. Conoce más en www.srzorro.com.
Escrito por: Editorial
#IdeasAntesDelCódigo #ProcesosDigitales #OperaciónDigital #Trazabilidad #GestiónDeSolicitudes #DiseñoDeProductosDigitales #SeñorZorro
Fuentes
Comentarios