Cómo usar el scorecard
Puntúa el operating model que funciona hoy, no el roadmap. Si un control depende de una persona concreta, no lo consideres plenamente maduro. Si dudas entre dos respuestas, usa la menor: el objetivo es exponer fricción operativa.
El total es una señal direccional. Los cinco dimension scores son igualmente importantes porque un promedio alto puede ocultar una debilidad crítica.
Architecture mide coupling
La pregunta central es cuánto dependen canales y business systems de provider-specific behavior. Un diagrama limpio todavía puede esconder coupling fuerte.
La mejor señal es change isolation: añadir provider, payment method o canal no debería obligar a reescribir business logic no relacionado.
Execution incluye incertidumbre
Successful payment es fácil. La madurez aparece cuando una respuesta se pierde, el provider se degrada o no se sabe si ocurrió el financial effect. Preservar unknown state y recuperar de forma segura es clave.
Routing también debe considerar policy, context, health y realized outcome, no solo precio.
Reconciliation es financial control
Provider approval no prueba settlement, fees, payout ni accounting outcome. Se necesitan stable identities entre attempts, provider records, settlement evidence e internal finance records.
Automation solo crea valor cuando exceptions siguen siendo explicables, con reason, owner, age y closure evidence.
Visibility debe producir acción
Dashboard útil conecta technical signals con business y financial identities, permitiendo identificar transacciones afectadas y recovery action.
Management reporting debe permitir comparar providers, canales, costs, exceptions y settlement outcomes.
Scalability es el coste del próximo cambio
Scalable estate no significa soportar todo de antemano. Significa que el siguiente market, canal o provider no obliga a cambios desproporcionados en checkout, finance, reporting y support.
Provider concentration puede ser razonable si es conocida, justificada y suficientemente reversible.
Interpreta scores bajos como señales de operating model
Un score bajo no exige reemplazar todos los components. Muchas veces el problema está en coordination: fragmented states, manual reconciliation, exception ownership débil o visibility inconsistente.
Cambiar PSP sin cambiar el operating model puede reproducir el mismo problema.
Usa el resultado para elegir la siguiente investigación
Architecture y Scalability bajos apuntan a coupling; Execution a state y recovery; Reconciliation a financial chain; Visibility a telemetry y decision support.
El scorecard es vendor-neutral para crear lenguaje común entre product, engineering, finance y operations.
No uses el score como una decisión de inversión aislada. Combina las dimensiones más débiles con incidents reales, manual workload, provider concentration y planes de expansión. Esa lectura ayuda a separar problemas de process, architecture y provider, y a elegir la mejora de control más pequeña que produzca un resultado operativo verificable.
Puntúa el operating model actual.
Usa score total y debilidades por dimensión.
Trata reconciliation, recovery y reversibility como controles de primer nivel.
No añadas complexity antes de poder controlarla.