Qué se puede automatizar y qué no
Hay tareas que una persona repite igual todas las semanas: copiar un registro del formulario a una hoja, avisar en un chat que llegó un pedido, crear un borrador de respuesta, recordar una cita. Esas se pueden automatizar. Hay decisiones que dependen del criterio de alguien del negocio: un descuento, una excepción, un cliente molesto. Esas no se deben esconder dentro de un robot.
Devstoremx trabaja el primer grupo con negocios en México, en remoto. El encargo empieza por el flujo escrito en pasos, no por la herramienta de moda. Si al escribirlo aparecen huecos (“y aquí alguien llama”), esos huecos se quedan humanos. Automatizar un proceso confuso solo hace el caos más rápido.
Cuando la conexión ya no cabe en las herramientas que usas y hay que construir un puente, el servicio es integraciones. Conviene no usar los dos nombres para la misma cosa: uno configura, el otro desarrolla.
Ejemplos de flujos que sí vemos
- Un formulario de landing crea el registro, avisa al correo correcto y, si hace falta, anota la campaña de la que vino la persona.
- Un pedido de la tienda dispara un aviso interno y un mensaje al cliente, sin que alguien reenvíe el correo a mano.
- Una fecha de vencimiento genera un recordatorio. El texto lo aprueba el negocio; la automatización solo lo envía a tiempo.
- Una bandeja recibe solicitudes y una clasificación ayuda a separar las que son ventas de las que son soporte, para que las lea una persona. La clasificación no contesta sola en nombre de la empresa, salvo que se haya diseñado y revisado ese texto.
La inteligencia artificial entra en el último tipo de paso: resumir, clasificar, proponer. La persona sigue siendo quien envía lo delicado. Poner un modelo a contestar clientes sin revisión es una forma rápida de prometer cosas que el negocio no ofrece.
Cómo lo dejamos documentado
Una automatización que solo vive en la cuenta personal de quien la armó se pierde cuando esa persona se va. Entregamos el flujo con nombre, con la lista de herramientas que toca y con la cuenta a nombre del negocio. Si una herramienta cobra su propia suscripción, ese costo es del proveedor, no se disfraza de desarrollo.
También se prueba el camino infeliz: un formulario a medias, un correo que rebota, un pedido duplicado. El camino feliz de la demo no es la prueba.
A quién le quita trabajo repetido
Es para un equipo que ya siente la repetición en el cuerpo: la misma copia, el mismo aviso, el mismo olvido. No es para quien espera que un diagrama sustituya una política que todavía no existe. Si no pueden explicar el paso 2, no hay nada que conectar.
Tampoco es un sustituto del mantenimiento del sitio. Que el formulario avise solo no actualiza WordPress ni respalda la tienda. Son trabajos distintos y se pueden contratar juntos, pero se escriben por separado.
Qué llevar a la llamada
El paso a paso como lo hacen hoy, aunque sea feo. Las herramientas que ya pagan. Un ejemplo real de la información que viaja, con datos de prueba, no con datos de un cliente. Y qué error duele más: el retraso, el duplicado o el aviso que nunca sale.
Con eso se puede cotizar un flujo, entregarlo y decidir si el siguiente vale la pena. Sin eso, “automatizar el negocio” es una frase, no un proyecto.
Qué queda fuera a propósito
No automatizamos el criterio comercial. Un descuento, una excepción a un cliente o una queja no deberían dispararse solos porque un conector “puede”. Si el paso requiere leer el tono del mensaje, se queda en una persona y la automatización solo le acerca el contexto: el folio, el pedido, el historial corto.
Tampoco prometemos que la herramienta intermedia sea eterna. Zapier, Make u otra capa pueden cambiar de plan o de límites. Cuando el flujo es crítico y esa capa estorba, se evalúa pasarlo a una integración propia. Esa decisión se toma con el flujo ya funcionando, no el primer día, para no construir un puente antes de saber si el atajo basta.
