KINTO llevó un evento recurrente de precompra a venderse con pago real, control de cupos por fecha y sede y conciliación automática; los pagos salieron a producción tres días después del primer commit.
Problema
Había que vender cupos de un evento recurrente por precompra, con pago real y control de cupos por fecha y sede, y que el equipo pudiera editar la página en su constructor visual sin romper nada. El publicador estático anterior no ejecutaba el JavaScript del constructor y obligaba a subir todo a mano.
Señales
- Mercado: No se midió demanda de mercado en este encargo.
- Negocio: Evento recurrente con picos temáticos y cambios de calendario.
- Experiencia de usuario: Compradores desde navegadores dentro de redes sociales fallaban en la pasarela; hacía falta un aviso específico y una página de gracias con la fecha exacta.
- Atención al cliente: Campo de referido, términos por tandas y reservas de terceros.
Cómo lo entendimos
- Iteración sobre incidencias reales: límites de la plataforma de borde, caché del hosting y PDFs de menús que el rastreador no capturaba, todo documentado como lecciones.
Qué construimos y por qué
- Landing de precompra con un servicio de pagos en el borde: orden firmada, checkout embebido de una pasarela local, registro en hoja de cálculo, webhooks con respaldo por consulta y un reconciliador de pagos.
- Publicador con navegador real que reproduce fielmente el constructor visual, con previsualización, redirecciones y descubrimiento automático de menús.
Por qué así: Un webhook puede perderse, así que cada pago tiene respaldo por consulta y un reconciliador; y el publicador usa un navegador real para que lo que se publica sea lo que el equipo vio en el constructor.
Transformación
-
Pagos en producción a los tres días del primer commit; flujo de pagos reforzado con respaldo por consulta.
-
Publicación de manual a un comando, con paridad visual.
-
días del primer commit a pagos en producción: 3 (medido)
Lo que aún no sabemos
- Cupos vendidos y conversión: sin evidencia.
