Web
Migrar pedidos de WhatsApp a una plataforma propia
WhatsApp es un buen lugar para hablar con un cliente y un mal archivo de pedidos. El mensaje se mezcla con el saludo, la foto del producto, el “¿todavía tienes?” y el comprobante. Al final del día nadie puede decir con calma cuántos pedidos quedaron abiertos, cuál se entregó y cuál se cobró. Migrar no significa apagar el chat. Significa que la conversación sigue donde la gente ya escribe, y que el pedido vive en una plataforma con estado, responsable y dato que no depende de hacer scroll.
Qué se rompe cuando el pedido es un chat
Se rompe la cola. Dos personas responden el mismo número y cada una cree que la otra anotó el domicilio. Se rompe el stock: se promete un producto que ya salió porque la verdad está en la estantería, no en el hilo. Se rompe el turno: el pedido de la mañana sigue marcado como no leído al lado de un audio nuevo. Se rompe el cierre, porque armar el día es releer conversaciones. Nada de eso es un defecto del teléfono. Es el límite de usar un chat como si fuera un sistema. Mientras el volumen cabe en la memoria de una persona, el límite no duele. Cuando hay más de un turno o más de una sede, duele todos los días.
Qué no hay que migrar el primer día
No hace falta mudarse de un golpe a un ERP. El primer corte útil es el pedido: quién pide, qué pide, a dónde va y en qué estado está. El historial viejo del chat puede quedarse en el teléfono. Copiar miles de mensajes a una base no ordena la operación; ordena un archivo. Tampoco hace falta prohibir WhatsApp a los clientes. Muchos van a seguir escribiendo por ahí. La regla nueva es interna: cuando el pedido se acepta, alguien lo crea en la plataforma. El chat deja de ser la única copia.
Ese panel, con usuarios y datos, es el tipo de trabajo descrito en aplicaciones web en Medellín. La referencia publicada parte de 4.500 € cuando hay lógica de negocio, no cuando solo quieres una página.
Cómo queda el flujo en la plataforma
Un flujo honesto para una PYME cabe en pocos estados: recibido, en preparación, listo y entregado o anulado. Cada estado tiene un responsable. El pedido guarda el detalle que hoy se pierde en el audio: productos, cantidades, dirección y nota. Si hay inventario, descontar al confirmar evita prometer lo que no está. Si todavía no hay inventario, el estado igual sirve: la cocina o la bodega ven una lista, no un teléfono compartido. La oficina puede mirar el día sin pedir que le reenvíen capturas. El cliente puede seguir recibiendo el mensaje por el canal de siempre; lo que cambia es que el local ya no reconstruye el pedido desde ese mensaje.
Qué stack encaja
Para varias personas y una sede que a veces no está en el local, una aplicación web en ASP.NET Core permite entrar con el navegador, sin instalar un programa en cada teléfono. Si el mostrador vive de impresora, lector y red inestable, la caja puede ser Windows Forms y el panel de seguimiento puede ser web: los dos hablan con los mismos datos. Si quien reparte está en la calle, una app Android con .NET MAUI puede llevar la lista del día. No hace falta elegir los tres el primer mes. Hace falta que el pedido tenga un solo lugar. El MVP de 500 € puede ser ese alta mínima, y se descuenta si el proyecto continúa.
Un caso con nombre, de operación real en la web y sin métricas inventadas, es la plataforma de supermercados. Muestra catálogo y pedido en un sitio propio, no un ranking de herramientas de chat.
Cómo hacer el cambio sin parar el día
El cambio se hace en paralelo una semana de verdad, no en un anuncio. Durante esos días el chat sigue abierto y cada pedido aceptado se registra también en la plataforma. El equipo nota qué campo faltaba: la torre, el método de pago, la hora. Esos huecos se corrigen en el alcance, no con un grupo nuevo de WhatsApp. Cuando la lista de la plataforma coincide con lo que salió a la calle, el chat deja de ser la fuente. Quien escribe al cliente puede seguir siendo la misma persona. La diferencia es que mira el pedido en la pantalla y no reconstruye la frase. Treinta días después de la entrega cubren defectos de lo construido, no un segundo rediseño del proceso.
Qué decirle al equipo
El anuncio interno es corto. El cliente puede escribir igual. Nosotros dejamos de contestar “listo” solo en el chat cuando el pedido no está creado. Nadie pierde el teléfono. Se gana una lista que sobrevive al cambio de turno. Si alguien olvida crear el pedido, el fallo es visible: no está en la lista. Eso es más fácil de corregir que un mensaje que se fue hacia arriba. No hace falta un manual largo el primer día. Hace falta un estado y una persona responsable de pasarlo.
Si quieres bajar el pedido del chat a un flujo concreto, se puede contarlo por el contacto. Basta decir quién responde hoy, qué datos no pueden faltar y si el stock ya se controla o todavía no.
Qué alcance pedir primero
Pide el alta del pedido y los estados, no “todo lo que WhatsApp hace”. Los audios, las fotos informales y el saludo pueden quedarse en el chat. Si el primer dolor es la página pública y no la operación, eso es una landing de 1.500 € o un sitio de 2.500 €, y mezclarlo con el panel confunde el hito. Si el dolor es la cola de pedidos, la referencia de aplicación web parte de 4.500 €. El soporte de 150 € al mes, sin permanencia, tiene sentido cuando el panel ya corre el día y quieres a alguien para los fallos, no para seguir anotando en el grupo. El código queda a tu nombre al completar los pagos.
Preguntas cortas
¿Hay que dejar de usar WhatsApp?
No. El chat puede seguir como conversación. Deja de ser el único lugar donde existe el pedido.
¿El MVP de 500 € alcanza para toda la operación?
No. Alcanza para un flujo principal, por ejemplo crear el pedido. La aplicación con usuarios y datos parte de 4.500 €. Los 500 € se descuentan si continúas.
¿Se pueden importar los chats viejos?
No es el objetivo. El historial puede quedarse en el teléfono. Lo que se diseña es el pedido nuevo, con estado y responsable.