top of page

Del WhatsApp disperso a una plataforma de seguimiento

  • Foto del escritor: Editorial
    Editorial
  • hace 2 minutos
  • 5 min de lectura
Del WhatsApp disperso a una plataforma de seguimiento Revista ideas antes del código

Una empresa puede parecer organizada porque todos responden mensajes, aunque detrás exista una operación difícil de seguir. Cuando solicitudes, responsables, evidencias y pendientes viven dentro de conversaciones, el problema no es la falta de comunicación: es la ausencia de una estructura digital que permita saber qué ocurrió, quién debe actuar y qué sigue pendiente.


El problema no era WhatsApp, sino todo lo que ocurría dentro de él

Imaginemos una empresa de servicios donde buena parte de la operación se coordina mediante WhatsApp. Un cliente envía una solicitud, alguien la recibe, pide algunos datos y después reenvía la información al grupo donde espera encontrar a la persona responsable.


Horas después surge una pregunta aparentemente sencilla: ¿ya se atendió?

Comienza entonces la reconstrucción: buscar el mensaje original, identificar quién tomó la solicitud, localizar fotografías y confirmar si el problema realmente quedó resuelto.


El equipo trabaja. Los mensajes circulan. Las personas responden. Pero la operación depende demasiado de la memoria, de la interpretación y del seguimiento manual.


Microsoft encontró que los trabajadores analizados en Microsoft 365 destinaban una proporción importante de su jornada a reuniones, correo y chat, mientras una parte significativa también reportaba perder tiempo buscando información. Asana ha descrito este fenómeno como work about work: tiempo invertido en coordinar, perseguir actualizaciones y localizar información en lugar de ejecutar el trabajo que realmente genera valor.


“Cuando preguntar por el estado de una tarea se convierte en parte del trabajo diario, el problema ya no es de comunicación: es de diseño operativo.”

Puedes escuchar este artículo aquí:


WhatsApp no era el enemigo. El problema estaba en haber convertido una herramienta de conversación en el lugar donde también se intentaban administrar responsables, prioridades, evidencias, fechas, estados y decisiones.


De mensajes dispersos a solicitudes trazables

El cambio conceptual más importante aparece cuando dejamos de pensar en mensajes y comenzamos a pensar en solicitudes.


Un mensaje puede decir: “Hay un problema en esta habitación”.

Una solicitud estructurada puede contener quién la reportó, dónde ocurrió, categoría, prioridad, descripción, fotografías, responsable, estado, historial y resultado.


Esa diferencia transforma completamente la operación.


En lugar de buscar conversaciones, el usuario consulta pendientes. En lugar de preguntar quién está atendiendo algo, observa al responsable asignado. En lugar de escribir “¿cómo vamos?”, revisa el estado. Y en lugar de encontrar una fotografía perdida entre decenas de mensajes, accede a la evidencia vinculada directamente con el caso correspondiente.


En UX existe un principio fundamental: el usuario siempre debería poder entender qué está ocurriendo dentro del sistema. En una operación digital esto significa algo muy concreto: saber qué se recibió, quién debe actuar, qué sigue pendiente y cuándo una solicitud puede considerarse realmente terminada.


Diseñar la experiencia consiste precisamente en hacer visibles esas respuestas.

Por eso digitalizar una operación no comienza diseñando pantallas.

Comienza definiendo el proceso.


Revista ideas antes del código Del WhatsApp disperso a una plataforma de seguimiento

El flujo antes que la interfaz

En un Caso Zorro, el primer ejercicio no debería ser imaginar un dashboard. Debería ser dibujar el recorrido real de una solicitud desde que alguien la reporta hasta que puede considerarse cerrada.


Ese recorrido puede resumirse en una secuencia simple:

registrar, clasificar, asignar, atender, comprobar y cerrar.

Cada etapa necesita reglas.


Registrar significa capturar la información indispensable sin convertir el formulario en una barrera. Clasificar permite separar solicitudes por tipo, área o prioridad. Asignar define quién debe actuar. Atender registra avances. Comprobar añade evidencia. Cerrar establece que el trabajo efectivamente terminó.


Parece sencillo, pero obliga a resolver preguntas que una conversación puede mantener indefinidas.


¿Qué significa exactamente que una solicitud esté “en proceso”? ¿Quién puede declararla resuelta? ¿Qué ocurre si fue enviada al área equivocada? ¿Puede reabrirse? ¿Qué evidencia debe existir antes de cerrarla?


Esas decisiones pertenecen al producto antes que al código.


La interfaz llega después.


Puedes ver este artículo aquí:


La plataforma debía reducir preguntas, no agregar pantallas

Uno de los errores más comunes sería observar el caos de los chats e inmediatamente pedir una aplicación con dashboard, notificaciones, estadísticas, inteligencia artificial, filtros y decenas de funcionalidades.

Eso sólo digitalizaría el desorden.


La primera versión debería resolver correctamente el flujo central.

Cada solicitud necesita un identificador. Cada responsable debe saber qué le corresponde. Cada cambio de estado debe quedar registrado. Las fotografías y comentarios deben conservar contexto. Las prioridades deben obedecer a criterios comprensibles.


La conversación puede seguir existiendo.


Pero debe cambiar su papel.


La conversación puede iniciar el proceso. No debería ser el lugar donde el proceso vive.


Una plataforma de seguimiento convierte cada interacción relevante en una unidad de trabajo observable. Ese cambio permite que la operación deje de depender exclusivamente de quién recuerda qué se dijo y comience a construir trazabilidad.


El verdadero MVP era recuperar trazabilidad

Antes de desarrollar una plataforma completa habría que probar los momentos críticos.


¿Puede alguien registrar una solicitud en pocos segundos? ¿El responsable recibe suficiente información para actuar sin reconstruir la conversación?

También habría que comprobar si un supervisor puede distinguir lo urgente de lo reciente, si una solicitud puede cambiar de área sin perder contexto y si la evidencia permite confirmar que algo realmente quedó resuelto.


El MVP no necesita resolver toda la empresa.


Puede comenzar con un solo flujo de alto volumen y suficiente fricción. Después se mide si disminuyen las preguntas, las solicitudes extraviadas, la duplicación y el tiempo necesario para entender qué está ocurriendo.


Si funciona, entonces pueden llegar automatizaciones, indicadores, reglas de escalamiento, integraciones y eventualmente inteligencia artificial.


Primero debe existir algo más elemental: una versión compartida de la realidad.


“Una buena plataforma operativa no hace que el equipo escriba más; hace que tenga que preguntar menos.”

Revista Ideas antes del código infografía 03
Puedes descargar libremente esta infografía.

Ese es uno de los cambios más importantes cuando una organización pasa de administrar el trabajo mediante conversaciones a diseñar una operación digital.

La oportunidad no consiste en reemplazar un grupo de WhatsApp por una app.

Consiste en transformar información dispersa en un proceso visible, trazable, medible y mejorable.


Y antes de preguntar cuánto costaría desarrollar esa plataforma, probablemente convenga responder algo más importante: ¿qué parte de tu operación todavía depende de que alguien recuerde, pregunte o busque un mensaje para saber qué debe suceder después?


¿Tu idea necesita más claridad antes de convertirse en código? En Sr. Zorro App Design Studio te ayudamos a definir, validar y diseñar productos digitales listos para desarrollo. Conoce más en www.srzorro.com.


Banner Ideas antes del código Promocional

Escrito por: Editorial



Fuentes



Comentarios


bottom of page