Cómo escalamos el Smart POS de Openpay en LATAM

Ficha Técnica

• Rol: Lead Product Designer (Estrategia de diseño, arquitectura y criterio de localización. Investigación y ejecución en conjunto con el equipo de producto).
• Tiempo: 2022 a 2024.
• Plataforma: Smart POS (Android 6).
• Resultado: Lanzamiento regional estabilizado en producción, con tracción comercial inicial encaminada a la meta del primer trimestre.

Reemplazar la rigidez de terceros con control total Openpay, parte del ecosistema de BBVA, necesitaba cerrar su oferta de pagos. Ya tenían pasarela web y mPOS, pero su terminal inteligente dependía de un proveedor externo de marca blanca. Este contrato los volvía lentos y rígidos. El negocio requería una solución propia y flexible para captar al segmento desatendido de las empresas medianas. El reto que enfrentamos fue construir desde cero una plataforma global que funcionara en un sistema operativo hermético y anticuado por cuestiones de seguridad bancaria, rindiendo cuentas directamente al nivel directivo.

El sesgo del equipo frente a la realidad local La tesis que definí para el proyecto fue aislar lo global estandarizable y descubrir exactamente dónde el producto tenía que romperse para adaptarse. Como equipo, llegamos con sesgos de diseño que nuestra investigación de campo en Perú y Colombia se encargó de desmentir. Estas validaciones dictaron las decisiones de arquitectura que tomé:

• El flujo de propinas no es universal. Asumíamos que un solo componente versátil resolvería el cobro de propinas para toda la región. El research nos demostró lo contrario. En México el usuario piensa en porcentajes, pero en Perú y Colombia operan con montos fijos en moneda local. Descarté la pantalla única y diseñé flujos paralelos por país, sumando una opción limpia para las industrias donde la propina no aplica.
• El cierre de turno es el corazón de la contabilidad. Al principio creíamos que podíamos relegar los cierres de turno por debajo del flujo de cobro. Las entrevistas nos revelaron que, para negocios como restaurantes, este paso es crítico para su control de personal. Modifiqué la arquitectura de información para subirlo en la jerarquía visual de la interfaz.
• El ticket físico no es negociable. Pensábamos forzar comprobantes 100% digitales para ahorrar papel y modernizar la experiencia. La realidad contable nos frenó de golpe. En países como Perú, el ticket físico impreso es una obligación fiscal por cada transacción. Respeté la fricción local y mantuve la impresión física como un paso clave, sacrificando el ideal digital por la viabilidad operativa del negocio.

Un sistema de diseño que absorbe la tropicalización Con el núcleo validado por el equipo, construí un sistema de diseño móvil pensado como motor de escalabilidad. Al resolver la base global mediante patrones claros, el equipo tuvo margen para enfocarse exclusivamente en las regulaciones de cada país. Esto bajó drásticamente el tiempo de salida al mercado. Cuando mi participación concluyó, la arquitectura que dejé permitió que el equipo desplegara Argentina y México como tropicalizaciones directas de esta base.

Estabilidad operativa y tracción en el mercado Construimos y lanzamos un MVP con módulos de cobro con tarjeta, enlaces de pago, cobros con QR, preautorizaciones y devoluciones. Tras los retos técnicos naturales de salir a un ambiente real, el sistema se estabilizó en su primera semana de producción. La estrategia de captación en sucursales físicas y canales digitales funcionó de inmediato. Durante el primer trimestre, las métricas iban encaminadas a la meta. Aunque no me quedé el tiempo suficiente para validar el resultado final de ese año, la tracción inicial era exactamente la esperada para esa etapa de adopción.

La red de seguridad en economías emergentes Desplegar este sistema nos demostró el altísimo nivel de adopción de billeteras electrónicas en mercados emergentes. Atender a estos sectores base aporta valor real a los comercios mientras genera utilidades para el negocio. Al final, en un producto regional, la estandarización te da la velocidad para operar a escala, pero la validación con el usuario es la única red de seguridad que impide que los sesgos del equipo destruyan la confianza local.