De entregar a mano a entregar en 0,72 segundos

Conectamos WordPress, Stripe y un asistente en Telegram para que la tienda de EZ Visa Consultant cobre, verifique y entregue sin que nadie tenga que estar pendiente.

Cómo viaja una compra por el sistema

Dos recorridos. El de la tarjeta no toca a nadie del equipo; el otro se resuelve con un botón.

Recorrido de un pago con tarjeta: el comprador compra en la tienda de WordPress, Stripe confirma el pago, el sistema verifica que el aviso venga de verdad de Stripe, envía un correo con los archivos y el código de acceso, y la entrega queda completa en 0,72 segundos sin intervención de ninguna persona.

Con tarjetaCon otro método

1. 01Compra en la tienda
2. 02Pago confirmado
3. 03Verificación automática
4. 04Correo con archivos y código
5. 05Entregado

0,00s

Del pago a los archivos en la bandeja del comprador. Sin que nadie del equipo haga nada.

El punto de partida

EZ Visa Consultant es una consultoría que, además de su servicio principal, vende material digital desde su propio sitio en WordPress. El sitio existía. El cobro con tarjeta existía. Los archivos existían. Lo que no existía era nada que los uniera.

Cada venta terminaba en algo que alguien tenía que atender a mano: entrar, comprobar, buscar el archivo, escribir el correo. Y cuando el comprador pagaba por una aplicación de pagos entre personas, algo frecuente en su público, el trabajo se duplicaba. Llegaba una captura del pago por mensaje, había que revisarla cuando se pudiera, y recién entonces enviar los materiales.

Ese modelo funciona con tres ventas al mes y se rompe con treinta. Peor todavía: mientras nadie esté mirando, no hay ventas. El negocio solo podía vender a las horas en que alguien estuviera disponible para despachar.

La tienda tampoco estaba montada para crecer. Cada producto nuevo significaba repetir el mismo trabajo manual desde cero.

Las piezas que conectamos

No hubo que cambiar de plataforma ni reconstruir el sitio. Todo se apoya en herramientas que el negocio ya tenía o que reconoce sin necesidad de explicación.

WordPress es la tienda. Ahí viven el catálogo, las páginas de producto y la página de confirmación de compra. Sigue siendo suyo y sigue funcionando como siempre, con la diferencia de que ahora es el principio de un proceso y no el final.

Stripe es la caja registradora. Cobra con tarjeta y, en el instante en que un pago se confirma, avisa al motor de automatización. Ese aviso es el disparador de todo lo demás.

Un asistente en Telegram es el puesto de mando. Cuando alguien paga por fuera de la tarjeta, el comprobante llega al chat del equipo con los datos de la compra ya ordenados y dos botones. Aprobar o rechazar. No hay panel que aprender, no hay sesión que iniciar, no hay aplicación nueva que instalar. Es el mismo Telegram que ya usaban.

El motor de automatización es lo que no se ve, y es el trabajo real: escucha a Stripe, valida, decide, redacta y envía. Vive en infraestructura nuestra, monitoreado, y es lo único que el equipo no tiene que administrar.

El correo transaccional cierra el círculo, con la identidad visual del negocio y no con la de una herramienta genérica.

El resultado

Cuando alguien paga con tarjeta, no pasa nada

Ese es el resultado: no pasa nada. Nadie recibe una notificación que atender, nadie busca un archivo, nadie escribe un correo. El comprador paga en el sitio y sus archivos aparecen en su bandeja con un código de acceso propio, junto con los materiales de bonificación.

Medido de extremo a extremo: 0,72 segundos. El objetivo acordado era que no pasara de 60.

Cuando alguien paga por otra vía, es un botón

El comprador sube su comprobante en el sitio, en un formulario con la identidad del negocio. El equipo recibe en Telegram la compra ordenada y el comprobante, y decide con el pulgar.

Si aprueba, se dispara exactamente la misma entrega automática. Si rechaza, el comprador recibe un aviso claro de que el pago no pudo verificarse. En los dos casos el equipo recibe de vuelta una confirmación con el resultado, el producto y el código emitido, así que sabe no solo que la decisión se registró, sino que el correo efectivamente salió.

Este flujo era, en la conversación original, el que más tiempo consumía. Hoy es un toque desde el móvil.

Los números

Otras cifras del sistema:

• 5 archivos se entregan en cada compra: el producto adquirido más los materiales de bonificación.
• 58,6 MB pesa el paquete más grande del catálogo. Medimos la descarga a 23,6 MB/s, unos 190 Mbps, lo que da 2,6 segundos completos. Verificamos que el servidor no fuera el cuello de botella antes de sugerir cualquier cambio.
• 14 días de retención automática de los comprobantes en el motor. La copia permanente vive en el chat de Telegram del equipo. Se documentó explícitamente en lugar de dejarlo como una suposición.

Lo que el sistema garantiza

Un flujo que funciona cuando todo va bien no es un entregable. Esto es lo que el equipo tiene resuelto sin tener que pensarlo:

Nadie puede regalarse un producto. El punto de entrada de los pagos está protegido por partida doble, incluida la verificación criptográfica de que el aviso viene de verdad de Stripe y no de alguien que adivinó la dirección. Lo probamos falsificando un pago: no entrega nada.

El formulario de comprobantes no es una puerta abierta. Solo acepta cuatro tipos de archivo, con tope de tamaño, límite de envíos por persona y por minuto, y un freno adicional en el borde de la red. Quien se pase queda detenido antes de llegar al Telegram del equipo y, deliberadamente, sin enterarse de que lo frenaron.

Las alertas distinguen el ruido del problema. El sistema avisa cuando una entrega falla de verdad, pero no cuando rechaza algo que se supone que debe rechazar. Si alguien intenta abusar del formulario, la bandeja no se inunda. Todo queda registrado igual.

La entrega no depende de que los textos coincidan. En una compra de prueba, el nombre del producto llegó desde Stripe con un guion tipográfico distinto al del catálogo. Un sistema que buscara coincidencia por texto habría fallado en silencio. El nuestro identifica el producto por su identificador y no se enteró del problema.

El correo se ve bien incluso donde el correo se ve mal. Las plantillas llevan tres capas de protección contra el modo oscuro, porque cada aplicación de correo lo implementa distinto. Documentamos con honestidad el caso concreto en el que la protección no alcanza, en vez de prometer que funciona en todas partes.

Cómo se trabajó

• Discovery por teléfono para entender el negocio antes de proponer nada.
• Prototipo funcional antes de que el cliente pusiera un peso, para que viera el resultado en vez de imaginárselo.
• Alcance cerrado y escrito. Lo que no estaba dentro se cotizó aparte, sin excepciones y sin fricción.
• Copia de seguridad completa antes de tocar el sitio.
• Siete semanas de calendario, con el grueso del trabajo concentrado en un puñado de sesiones.

Lo que el equipo ya no hace

No revisa correos para saber si vendió. No busca archivos. No responde "ya te lo mando". No pierde una venta por estar ocupado, dormido o de viaje.

Aprueba un pago con el pulgar, cuando le llega, desde donde esté. El resto ya está hecho.

Cómo se midieron estas cifras

Los 0,72 segundos y las demás cifras salen de la validación de extremo a extremo del sistema, con eventos firmados por los servidores de Stripe y usando el checkout real de la tienda. No son estimaciones ni promesas de folleto: son mediciones sobre el sistema que quedó instalado.

¿Vendes algo digital y todavía lo entregas a mano? Eso se automatiza, y normalmente cuesta menos de lo que estás perdiendo en tiempo.