Cómo centralizar solicitudes internas en una pyme con un flujo único

Cuando una incidencia llega por WhatsApp, una petición de material por correo y una tarea urgente se comunica de palabra, el problema no es solo la cantidad de mensajes. La empresa pierde una visión común: cuesta saber qué se ha pedido, quién debe actuar, qué es realmente prioritario y si el asunto quedó resuelto. El resultado suele ser más seguimiento manual, interrupciones y solicitudes que dependen de que alguien las recuerde.

Centralizar solicitudes internas no exige implantar de entrada un ERP ni convertir cada pequeña necesidad en un trámite pesado. Consiste en acordar una entrada única, la información mínima necesaria, una persona responsable, unos estados comprensibles y una forma de confirmar el cierre. El objetivo es que el equipo deje de perseguir respuestas y pueda consultar el estado de cada petición en un lugar compartido.

El problema no es WhatsApp: es la falta de un recorrido común

Los canales informales pueden ser útiles para avisar de algo puntual, pero no son un buen registro operativo cuando intervienen varias personas. Un mensaje puede quedar enterrado, un correo puede no llegar a quien debía priorizarlo y una llamada no deja un estado visible para el resto. Si además cada departamento usa su propio criterio, las urgencias aparentes terminan desplazando trabajos que quizá tenían mayor impacto.

Un flujo de trabajo es una serie de actividades necesarias para completar una tarea. Para que funcione, conviene definir qué entra en el proceso, qué resultado se espera, quién participa, qué controles existen y cómo se seguirá su evolución. Esta lógica sirve para una incidencia de almacén, una necesidad de mantenimiento o una solicitud a administración, aunque la empresa use herramientas sencillas. [2] [4]

Empieza por una solicitud frecuente y fácil de acotar

No intentes centralizar todas las conversaciones internas el primer día. Elige un único tipo de petición que ocurra cada semana, implique a más de una persona y obligue hoy a preguntar repetidamente por su estado. Pueden ser incidencias operativas, necesidades de mantenimiento, solicitudes entre almacén y oficina o peticiones de soporte administrativo. Un alcance limitado permite detectar fallos sin alterar toda la operativa.

Antes de escoger una aplicación, reúne durante media hora a quienes solicitan, priorizan y resuelven ese tipo de casos. Responded por escrito a cinco preguntas: qué activa la solicitud, qué datos hacen falta, quién decide la prioridad, quién coordina la respuesta y qué evidencia confirma el cierre. Si no podéis explicar el recorrido en una página, todavía hay decisiones de proceso que resolver antes de automatizar. [4] [6]

• Elige una petición repetitiva y visible.
• Evita incluir asuntos con reglas muy distintas en el mismo piloto.
• Define qué peticiones quedan fuera del circuito inicial y por qué.

Diseña la entrada, la prioridad y los estados mínimos

El formulario de entrada debe pedir lo justo para que la persona responsable pueda actuar sin iniciar una cadena de aclaraciones. Una base razonable incluye asunto breve, categoría, descripción, área o proyecto afectado, impacto operativo, fecha necesaria si aplica y persona solicitante. Los adjuntos o fotografías deben ser opcionales salvo que sean imprescindibles para entender el caso. Un formulario demasiado largo devuelve la burocracia a quien pide ayuda.

Usa cinco o seis estados con un significado acordado: Recibida, Pendiente de clasificar, En curso, Pendiente de información, Pendiente de validación y Cerrada. Cada solicitud necesita también una persona responsable visible. Esa persona no tiene que hacer todo el trabajo, pero sí actualizar el caso, coordinar a quien corresponda y comprobar que el cierre es válido. “Urgente” debería responder a una regla concreta, como una operación parada o el bloqueo de varias personas, no a una percepción individual. [4]

• Evita categorías duplicadas o demasiado genéricas.
• Distingue entre prioridad e importancia para quien solicita.
• No cierres un caso solo porque se ha enviado un mensaje: confirma la solución o la validación requerida.

Aplica un circuito sencillo antes de automatizar

Un circuito inicial puede tener seis pasos: la persona registra la petición; alguien la clasifica; se asigna un responsable; el responsable trabaja o coordina la solución; quien solicitó aporta información o valida cuando sea necesario; y el caso se cierra con una nota breve. Este recorrido aporta trazabilidad sin exigir una plataforma compleja. Lo importante es que todos sepan dónde empieza el trabajo y qué condición permite darlo por terminado. [3] [5]

Ejemplo hipotético: una pyme detecta que faltan etiquetas para preparar pedidos. En lugar de avisar en varios chats, la persona de almacén registra una solicitud con la categoría “material operativo”, indica el impacto y añade una fotografía del stock. Administración la clasifica, asigna un responsable y deja el caso En curso. Si necesita una referencia concreta, pasa a Pendiente de información. Cuando el material está disponible, el solicitante valida la recepción y el responsable lo cierra.

Mide el uso del flujo y ajusta el piloto durante cuatro semanas

Desde la primera semana, revisa cuatro datos específicos del flujo: solicitudes recibidas por categoría, porcentaje atendido dentro del plazo acordado, tiempo mediano desde la entrada hasta el cierre y porcentaje de casos reabiertos o devueltos por falta de información. También conviene contar las peticiones que siguen entrando por canales no previstos. No son métricas para controlar a personas, sino señales para localizar cuellos de botella, formularios confusos o prioridades mal definidas. [4]

Mantén el piloto unas cuatro semanas con un equipo, sede o clase de solicitud. Al finalizar, elimina campos que nadie completa, agrupa categorías confusas y revisa si una persona concentra demasiadas asignaciones. Solo después automatiza acciones repetitivas y estables, como avisar al responsable, asignar según categoría o recordar un plazo superado. Las soluciones de gestión de procesos deben adaptarse a las necesidades concretas de la empresa y combinar el flujo con control y análisis, no imponer un diseño rígido. [6]

• Revisa semanalmente los casos abiertos y los reabiertos.
• Corrige primero el diseño del flujo antes de añadir más avisos.
• Amplía el sistema a otro tipo de solicitud solo cuando el piloto sea entendible y sostenible.

Preguntas frecuentes

¿Hace falta un ERP para centralizar solicitudes internas?

No necesariamente. En Cataluña, entre las empresas de menos de diez personas ocupadas con acceso a internet, el uso de ERP fue del 16,0 % en el primer trimestre de 2025. Un flujo de solicitudes puede empezar con una herramienta sencilla que permita formulario, asignación, estados y consulta compartida. La elección debe responder al volumen, la крит

¿Qué diferencia hay entre una solicitud interna y una tarea?

Una solicitud es la entrada de una necesidad, incidencia o petición que todavía debe clasificarse y priorizarse. Una tarea es una acción concreta que alguien ejecuta para atenderla. Una misma solicitud puede generar varias tareas, pero mantener una solicitud como caso principal ayuda a conservar el contexto, el responsable y la confirmación de que.

¿Cómo evitar que el equipo siga usando WhatsApp para pedir cosas?

No se trata de prohibir un canal de golpe, sino de dar una alternativa más sencilla y útil. Comparte una regla clara: las peticiones que requieran seguimiento deben registrarse en el flujo único. Durante el piloto, responde en el chat con un enlace o una indicación breve para registrar el caso. Si muchas personas no lo usan, revisa si el formulario