El cliente escribe para saber si has recibido el pedido. Después llama para preguntar si ya está en producción. Cuando el equipo busca una respuesta, el estado está en una hoja de cálculo, la fecha prometida la tiene un proveedor y la última actualización quedó en la conversación de otra persona.

Para reducir estas llamadas, no empieces por un portal. Primero descubre qué información falta y si el estado interno es fiable. Después elige el camino más pequeño que cierre la brecha: confirmación, aviso proactivo, página de estado, portal de clientes o ayuda humana. Si el negocio necesita responsabilidad continua sobre el software de la operación, esa persona debe hacerse cargo del flujo y de la información, además de la pantalla que ve el cliente.

Diagrama que muestra confirmación, avisos, estado y ayuda humana en un flujo de pedidos.

Respuesta breve

  • Averigua si el cliente no sabe si el pedido existe, en qué etapa está o qué ha cambiado.
  • Define una fuente del estado, los eventos que actualizan el pedido y quién responde cuando cambia la fecha.
  • Usa mensajes para una duda concreta, una página o portal para consultas repetidas y una persona para las excepciones.
  • Mide contactos sobre el estado, repeticiones y escalados antes y después del cambio. El silencio no demuestra satisfacción.

¿Por qué llaman los clientes para preguntar por el pedido?

El contacto suele ser una reacción a la falta de información, no una preferencia automática por el teléfono. El cliente quizá no recibió confirmación, está mirando una fecha que ya pasó o no sabe si "en curso" significa esperando material, en producción o listo para enviar.

En 2025, la guía de Shopify "WISMO Ecommerce: Meaning + 5 Strategies" recomienda combinar expectativas claras de entrega, canales de comunicación, seguimiento del pedido, automatización y un proceso capaz de consultar el estado. La lista no convierte todos los negocios en tiendas online. Ayuda a separar dos preguntas: ¿el cliente necesita un aviso o necesita investigar su pedido?

Sigue cinco contactos recientes desde el principio hasta el final y anota qué intentaba averiguar la persona. Clasifica cada contacto así:

  1. Confirmación: el cliente no sabe si el pedido quedó registrado.
  2. Progreso: sabe que el pedido existe, pero no su etapa actual.
  3. Plazo: la fecha prometida no está clara, ya pasó o cambió.
  4. Acción: quiere aprobar, corregir, enviar un documento o cambiar algo.
  5. Excepción: hay un retraso, falta material, la dirección es incorrecta u otro problema requiere criterio.

Esta clasificación evita comprar una solución para el problema equivocado. Un portal no arregla una confirmación que nunca se envía. Un mensaje automático no resuelve una fecha que el equipo no puede calcular.

¿Cuál es el camino más pequeño para cada contacto?

Elige la intervención según la pregunta que se repite y el cambio que el negocio puede mantener. La tabla es un punto de partida, no una promesa de que una herramienta reducirá los contactos por sí sola.

Problema del cliente Empieza por Busca otra solución cuando
"¿Recibieron mi pedido?" Envía una confirmación con identificador, siguiente paso y canal de ayuda. Los pedidos llegan por varios canales y el equipo vuelve a escribir los datos.
"¿En qué etapa está?" Define pocos estados comprensibles y avisa cuando cambie la etapa. El estado nace en sistemas distintos o queda desactualizado.
"¿Cambió la fecha?" Muestra la fecha prometida y avisa cuando ya no sea válida. Nadie tiene autoridad para confirmar una nueva fecha.
"¿Puedo aprobarlo o cambiarlo?" Ofrece una acción clara con plazo y registro de la respuesta. La aprobación depende de documentos, reglas o sistemas desconectados.
"¿Ha ocurrido algo?" Envía la excepción a alguien que pueda decidir y explicar el siguiente paso. El equipo debe preguntar a varias áreas antes de responder.

El error habitual es saltar a la última fila e intentar esconder cada pregunta dentro del autoservicio. El cliente sigue necesitando una respuesta verdadera. Si el negocio no conoce el estado, la interfaz solo hace que la incertidumbre parezca más ordenada.

¿Se puede confiar en el estado del pedido?

Antes de publicar un aviso, decide dónde nace el estado y qué significa cada etapa. El equipo puede consultar varios sistemas, pero el cliente no debería recibir versiones enfrentadas del mismo pedido.

Para cada estado, registra:

  • qué evento inicia la etapa;
  • quién puede cambiar el estado;
  • qué información puede ver el cliente;
  • qué fecha o siguiente paso acompaña la etapa;
  • qué ocurre cuando la etapa se retrasa;
  • cuándo una persona debe hacerse cargo de la conversación.

En 2022, la investigación de APQC, "Optimizing Customer Service", encuestó a 289 participantes y encontró que el 65 % de las organizaciones dijo que había aumentado el tiempo dedicado a responder solicitudes sobre el estado de los pedidos durante los dos años anteriores. El dato describe esa muestra y ese periodo. No mide todos los negocios actuales, pero muestra por qué este trabajo repetitivo necesita una solución operativa, en vez de una instrucción aislada para atención al cliente.

La misma investigación encontró que solo el 17 % de los participantes esperaba que los clientes usaran un portal web de autoservicio para recibir actualizaciones. El resultado es de 2022 y no demuestra que los portales sean menos útiles hoy. Es una advertencia contra suponer que todo cliente quiere abrir una página y buscar una respuesta. Muchas veces, una confirmación o un aviso a tiempo es más sencillo.

Si ventas, operaciones y finanzas mantienen versiones distintas, consulta el diagnóstico de los sistemas de empresa que no se conectan. El problema del estado puede ser la consecuencia visible de datos y responsabilidades que ya se separaron.

¿Cuándo basta con un mensaje?

Los mensajes funcionan cuando la pregunta tiene pocos eventos previsibles. El cliente no necesita iniciar sesión para saber que se recibió el pedido, que empezó la producción o que el envío salió. El mensaje debe contener la información necesaria para la siguiente decisión, sin limitarse a decir "tu pedido se ha actualizado".

Antes de automatizar, comprueba:

  1. ¿Ocurrió realmente el evento o alguien cambió un campo para vaciar una cola?
  2. ¿El mensaje incluye fecha, siguiente paso y un canal para las excepciones?
  3. ¿El cliente puede responder sin iniciar otra conversación en otro sitio?
  4. ¿El equipo puede corregir un mensaje enviado con el estado equivocado?

Incluye la fecha que el equipo puede cumplir. Evita prometer "tiempo real" si alguien revisa los datos una vez al día. Un mensaje tarde o falso puede generar más contactos que el silencio, porque el cliente empieza a cuestionar el aviso y el pedido al mismo tiempo.

Los mensajes tampoco sustituyen el trabajo de entrega. Shopify señala que la confirmación, el seguimiento y más de un canal de comunicación ayudan a responder preguntas sobre el estado, pero los retrasos y fallos de servicio aún necesitan una respuesta operativa. El aviso cierra una brecha de información. No cierra una brecha de ejecución.

¿Cuándo conviene una página de estado o un portal?

Una página de estado ayuda cuando los clientes necesitan consultar el mismo pedido más de una vez y la información cambia por etapas que se pueden explicar. Un portal tiene más sentido cuando también necesitan ver documentos, aprobar algo, seguir varios pedidos o responder dentro de su propio espacio.

Usa esta distinción:

  • Mensaje: el negocio sabe cuándo ha cambiado algo y quiere avisar al cliente.
  • Página de estado: el cliente necesita consultar una etapa sencilla.
  • Portal: el cliente necesita consultar información, actuar y encontrar historial o documentos.
  • Ayuda humana: el caso implica una excepción, negociación o información que todavía no se puede confirmar.

Primero comprueba si el software que ya paga la empresa incluye un portal, notificaciones o seguimiento que no está activado. Si la necesidad es normal y el producto encaja con el flujo actual, configurarlo suele ser menos arriesgado que crear otro sistema. Si el portal debe unir datos de ventas, producción, inventario, finanzas y logística sin una fuente compartida, el problema es mayor que una pantalla de consulta.

La guía para decidir si una empresa debe comprar otro sistema ayuda a tomar esta decisión sin empezar por un catálogo. Describe primero el flujo, las copias y el responsable. Después elige la herramienta.

¿Cómo proteger al cliente y al negocio?

Un portal debe mostrar los datos a la persona correcta. Eso requiere más que una URL bonita y un campo para escribir un número de pedido. Enumera qué datos pueden aparecer, cómo se confirma la identidad del cliente, qué acciones se permiten y cómo se revoca el acceso cuando termina la relación.

La guía de la Federal Trade Commission sobre ciberseguridad para pequeñas empresas recomienda inventariar el software, los datos y los servicios que usa un negocio, limitar el acceso a lo necesario, usar autenticación multifactor cuando corresponda, proteger los datos en tránsito y en reposo y definir expectativas de seguridad en los contratos con proveedores. Para una página de estado, conviértelo en preguntas concretas:

  • ¿Cada cliente puede ver solo sus pedidos?
  • ¿Se puede revocar el acceso o un enlace compartido?
  • ¿Sabe la empresa dónde se guardan los datos?
  • ¿La empresa controla una cuenta o solo el proveedor?
  • ¿Qué ocurre con los datos cuando termina el contrato?
  • ¿Quién investiga un estado incorrecto o un acceso no autorizado?

No conviertas esta lista en una razón para retrasar una confirmación sencilla. Sirve para aumentar el cuidado cuando la solución pasa de un mensaje sin datos sensibles a un portal con documentos, importes, direcciones o acciones de aprobación.

¿Cómo saber si las llamadas realmente disminuyeron?

Registra el problema antes de cambiar el proceso. Durante un periodo que el equipo pueda comparar después, cuenta los contactos cuyo motivo principal fue confirmación, progreso, plazo, cambio o excepción. Separa llamadas, mensajes y correos. Anota también si la respuesta ya estaba disponible o si alguien tuvo que reconstruir la historia del pedido.

Después del cambio, compara el mismo tipo de periodo operativo. Observa:

  • contactos sobre el estado por pedido;
  • pedidos sin confirmación;
  • contactos repetidos del mismo cliente sobre el mismo evento;
  • tiempo hasta la primera respuesta;
  • excepciones enviadas a una persona;
  • correcciones del estado enviadas después de un error.

Una caída de las llamadas puede significar que los clientes abandonaron, cambiaron de canal o empezaron a esperar más. Combina la medida con quejas, cancelaciones, respuestas a los mensajes y entregas dentro de la fecha prometida. Sin esas señales, registra el cambio como hipótesis, no como resultado demostrado.

¿Quién es responsable cuando cambia el estado?

El sistema no debe ser el dueño del proceso. Nombra a una persona o función que sepa quién actualiza el estado, quién corrige una fecha, quién responde a una excepción y quién aprueba los cambios en la comunicación con clientes. Esa responsabilidad puede quedarse en la empresa o estar en manos de un socio, pero no debe depender de la memoria de una sola persona.

La guía sobre quién mantiene el software después del lanzamiento cubre cuentas, datos, mantenimiento y transición. En un flujo de pedidos, el responsable también necesita el historial de decisiones, los criterios de estado, los mensajes enviados y el camino para apagar o sustituir la solución.

Si el negocio necesita a alguien que arregle el flujo completo, no pidas solo "un portal". Describe qué preguntan los clientes, dónde comienza la respuesta, qué acciones están permitidas y quién se hace cargo cuando la regla no encaja. Así la decisión de comprar, configurar o crear empieza con el trabajo real.

Preguntas frecuentes

¿Un portal de clientes elimina las llamadas sobre pedidos?

No. Un portal ayuda cuando los clientes necesitan consultar o actuar sobre información que cambia, pero no arregla un estado ausente, tardío o incorrecto. Empieza por definir la fuente de datos y los eventos. Mantén a una persona disponible para retrasos, negociaciones, correcciones y casos que la regla no puede explicar.

¿Es mejor enviar mensajes o crear una página de estado?

Depende de la pregunta. Envía mensajes cuando los eventos previsibles necesiten un aviso. Usa una página cuando los clientes consulten el mismo pedido repetidamente. Si también necesitan aprobar, editar, descargar documentos o ver historial, considera un portal. En todos los casos, la información debe ser verdadera y tener un responsable.

¿Cuándo merece la pena crear un portal a medida?

Considera software a medida cuando los clientes deban consultar o ejecutar un flujo específico que dependa de varios sistemas y ninguna herramienta existente pueda representarlo de forma segura. Antes, busca funciones de portal y notificaciones en lo que ya usa la empresa. El coste de mantener la solución forma parte de la decisión.

¿Cómo reducir contactos sin alejar a los clientes que quieren hablar con una persona?

No escondas el teléfono ni obligues al cliente a buscar cuando existe una excepción. Pon la información sencilla en el canal correcto y facilita la ayuda. La automatización debe quitar consultas repetitivas de la cola, no impedir que una persona vea un retraso, un error, un cambio o una negociación.

Conclusión

Los clientes llaman por el estado del pedido cuando la información falta, llega tarde, está fragmentada o resulta difícil de entender. La solución empieza por el flujo, no por el portal. Define la fuente del estado, los eventos que cambian la etapa, la fecha que el equipo puede prometer y la persona que se hace cargo de una excepción.

Después elige el camino más pequeño: confirmación, aviso proactivo, página de estado, portal o ayuda humana. Mide los contactos y sus consecuencias junto con el cambio. Un negocio puede seguir usando el teléfono, una hoja de cálculo o varios sistemas durante un tiempo. Lo que no puede continuar es obligar al cliente y al equipo a reconstruir la misma respuesta cada vez que alguien pregunta.

Nota de producción

Samuel Fajreldines es el responsable editorial de este artículo. La investigación usó documentación pública de Shopify, APQC y la Federal Trade Commission, además de conversaciones públicas de operadores. La asistencia de IA ayudó con la descubrimiento, la comparación de fuentes, el primer borrador, la traducción, la imagen y la revisión de consistencia. No hubo una prueba con clientes, un benchmark privado ni un caso inventado.

Fuentes consultadas