Los contracargos parecían fraude. El procesador iba a cortar el servicio. El checkout era el problema real.
Una marca de ecommerce DTC iba camino a una prohibición de procesador. Los contracargos llegaron al 8%, y el aviso vino del equipo de riesgo del procesador, que nunca explica dónde está el límite exacto. Encontré la causa real en una página de upsell confusa, la rediseñé, y seguí la tasa de contracargos cada semana desde el día que salió el arreglo.
La situación
El aviso vino del equipo de riesgo del procesador. Los contracargos habían llegado al 8%, suficiente para poner la cuenta en aviso de cancelación. Los procesadores y bancos no publican sus umbrales y no explican su razonamiento. Recibes un mensaje que dice que la cuenta está bajo revisión, y te quedas adivinando cuánto margen queda realmente antes de que corten la cuenta.
Esa incertidumbre es el punto. Un aviso así está pensado para tratarse como urgente sin importar qué tan cerca del límite creas que realmente estás, porque nadie fuera del procesador lo sabe con certeza. Y para una marca directa al consumidor, perder un procesador no es un inconveniente de papeleo, es una parada en el cobro de pagos, punto, en cada campaña pagada que ya corre y en cada cliente a mitad de checkout cuando se corta el interruptor.
Lo que todos asumieron
El primer instinto dentro de la empresa fue fraude. Contracargos a ese nivel normalmente significan tarjetas robadas, malos actores, o algún patrón de abuso, así que las primeras conversaciones fueron sobre reforzar controles antifraude y agregar fricción para filtrar pedidos malos. Nada de eso habría arreglado algo, porque nada de eso era realmente lo que estaba pasando.
Peor, el arreglo que todos buscaban habría complicado las cosas para los clientes reales que ya estaban confundidos, agregando más pasos y más verificación a un checkout que ya estaba haciendo tropezar a la gente. Resolver el problema equivocado no es neutral. Tiene su propio costo.
Lo que realmente estaba atascado
La causa real era una página de upsell confusa en el flujo de checkout. Hacía fácil, sobre todo para compradores menos hábiles con la tecnología, terminar pidiendo varias unidades cuando querían pedir una. Muchos de esos compradores eran clientes mayores que no leían un selector de cantidad saturado de la misma forma que lo haría un comprador en línea más joven y habituado.
Semanas después, esos mismos clientes veían un cargo en su estado de cuenta que no coincidía con lo que creían haber aceptado. No habían sido estafados. Habían sido confundidos por una página que hacía que comprar en volumen fuera el camino de menor resistencia. Pero del lado del banco, un cliente disputando un cargo que no reconoce se ve idéntico ya sea la causa fraude o confusión de checkout. La tasa de contracargos no podía distinguir la diferencia. Solo mirar la página real podía.
Lo encontré leyendo las razones de disputa que los clientes realmente daban, no solo el número agregado de contracargos, y recorriendo el flujo de checkout yo mismo como lo haría un cliente por primera vez. El patrón estaba ahí una vez que alguien realmente miraba: la misma página, el mismo momento del flujo, la misma historia de un cliente tras otro.
El sistema construido
El arreglo fue un rediseño del paso de upsell en el flujo del pedido, no una nueva pila de detección de fraude ni una reconstrucción completa del checkout que habría tomado semanas en salir y probarse. Una vez identificados la página real y el elemento confuso real, reconstruir cómo el upsell presentaba la cantidad y el precio significaba que el arreglo podía salir rápido y aun así sostenerse. El objetivo no era construir algo impresionante. Era dejar de confundir al cliente en el momento exacto en que estaba por comprar.
Esta es la parte que los fundadores resisten. Un pico de contracargos se siente como que necesita una respuesta grande: proveedores nuevos, herramientas nuevas, un proyecto con nombre y presupuesto. A veces sí. Aquí hacía falta que alguien mirara la página real que ve un cliente de verdad y rediseñara la pantalla específica que lo estaba induciendo a error. Más grande no siempre es más correcto.
Lo que cambió
Seguí la tasa de contracargos cada semana, empezando el día que salió el arreglo, no al final de alguna ventana arbitraria. Es la única forma de saber rápido si un arreglo realmente funciona en vez de descubrir un mes después que no. Los contracargos bajaron 75% en cuatro semanas. El procesador retiró su advertencia. El tráfico pagado nunca se detuvo, y la marca nunca tuvo que explicarle a sus propios clientes una interrupción del servicio.
A nadie hubo que decirle que dejara de anunciar. Nadie tuvo que migrar a un procesador de respaldo y absorber el golpe que esa migración siempre trae. Las campañas que ya corrían siguieron corriendo, y los clientes que ya estaban en el embudo siguieron convirtiendo, porque el problema se arregló en su origen en vez de gestionarse alrededor.
Qué deben observar los fundadores
- Contracargos altos no siempre significan fraude. Revisa la experiencia de checkout, sobre todo cualquier cosa con upsells o selectores de cantidad, antes de asumir que hay malos actores detrás.
- Los clientes mayores o menos hábiles con la tecnología tropiezan más con flujos de upsell poco claros que cualquier otro grupo, y su confusión aparece río abajo como una disputa, no como una queja que escucharás directamente.
- Los procesadores no te dirán sus umbrales exactos. Trata cualquier aviso de riesgo como urgente, sin importar qué tan cerca creas que realmente estás del límite.
- Sigue la métrica cada semana, empezando el día que sale un arreglo, no solo al final de un período de revisión. La velocidad de retroalimentación es cómo sabes que realmente lo resolviste.
- El arreglo no tiene que igualar el tamaño del problema. Un pico de contracargos puede venir de una sola pantalla confusa. Encuentra la pantalla antes de reconstruir el sistema.