Una suscripción es un mes de calendario pagado de una vez, y vive semanas: cobrar, esperar, empacar, entregar, pedir feedback, ofrecer el mes siguiente. Cada espera es un workflow durable con su propio temporizador, y cada resultado es un hecho escrito. Si el proceso muere en medio, se reanuda donde iba.
Nombres reales de los eventos y de los workflows que los escuchan. Ninguno de estos pasos es una función que corre cada hora preguntando «¿ya?».
Una sola herramienta puede devolver una cifra de suscripción. Calcula el mes, las fechas que su calendario tiene para esa zona, el total que se paga una vez y el envío por entrega. Si la zona no está validada, el envío vuelve como null en vez de inventarse.
La orden se crea con su ventana de pago congelada en el evento. Un proceso durable espera el pago hasta un instante fijo, el mismo que lleva el enlace de cobro, para que no pueda sobrevivir a su propio pedido.
Si el pago no llega, la orden de tarjeta no se cancela: se marca como link vencido y libera el cupo. La misma orden puede recibir un link nuevo, que cancela el temporizador viejo y arma uno fresco.
El pago confirmado se escribe en el sistema de registro, programa exactamente las fechas del mes, avisa a empaque y cierra la atribución del anuncio. Un depósito por transferencia reportado nunca se auto-cancela: es un artefacto de revisión humana y el workflow le pide al revisor que lo mire.
El workflow se duerme hasta el momento calculado al marcar la entrega, respeta la ventana horaria de envío y abre una conversación de feedback con consentimiento. Días de espera, sin proceso vivo ni cron.
Nada se vuelve a cobrar por su cuenta. Un barrido diario busca los meses pagados que terminan pronto y le ofrece el siguiente por WhatsApp, con un enlace de pago único. Quien pidió no recibir recordatorios no lo recibe. Si paga, el mes nuevo arranca con su racha de descuento.
Una queja abre dos workflows en paralelo: uno espera a que el cliente dé suficiente información, otro cuenta el silencio. El primero que se cumple decide si el agente sigue o si entra un humano.
Si Loma cancela una fecha del mes, un feriado o un camión que no sale, el sistema devuelve a la tarjeta la parte exacta de esa entrega con una llave de idempotencia por fecha, la anota en el libro de pagos y avisa a la clienta. Repetir la orden no devuelve dos veces.
Esto suena a detalle y es el bug más caro que tuvimos. El precio de una entrega y el cobro del mes son dos números distintos, y un modelo que solo tiene el primero va a asumir que son el mismo. El nuestro lo hizo: cotizó el precio de una sola entrega como si fuera el cobro completo, y lo confirmó otra vez cuando la clienta preguntó «o sea pago eso y ya, ¿verdad?».
La solución no fue pedirle al modelo que tuviera más cuidado. Fue darle una herramienta que devuelve el total del mes y las fechas exactas que cubre, y prohibirle en el prompt decir cualquier cifra de suscripción sin llamarla. Y el calendario manda: un mes con cinco viernes trae cinco entregas, y uno con un día sin camión trae menos. Multiplicar por cuatro dejó de ser verdad en cuanto el calendario cambió.
Una sola fuente autorizada para cualquier cifra de suscripción
Un solo pago con tarjeta por todas las entregas que el calendario de su zona tiene ese mes, con una línea por fecha. Si se suscribe a mitad de mes compra las fechas que aún se pueden pedir. El descuento de suscripción y el de su racha suman, con un tope. Nada se renueva solo.
Cada fecha guarda su parte del cobro al comprar, para que un redondeo nunca la mueva. Si Loma cancela una fecha, esa parte vuelve a la tarjeta y se le avisa a la clienta. Si la cancela ella, queda como crédito para su próximo pedido, nunca como efectivo.
Usamos mediciones opcionales de Google, Meta y TikTok para mejorar Loma y medir anuncios. Solo se activan si las aceptas; comprar no las requiere. Política de privacidad