Split the Bill | Caso de validación y diseño

Una oportunidad detectada en campo, no un KPI

El equipo de Venta Presente detectó en visitas a comercios que la mayoría de restaurantes activos opera con al menos dos POS simultáneos: uno de Niubiz y uno de la competencia. Cada vez que el comercio elige entre uno u otro al cobrar, se juega volumen para Niubiz.

La hipótesis era directa: si nuestro POS resuelve algo que la competencia no resuelve, el comerciante lo elige por defecto. El cobro dividido era ese “algo” — un dolor cotidiano del giro restaurantes que en Perú nadie había resuelto bien dentro del POS, donde el comerciante perdía tiempo combinando el equipo con calculadoras, papel y negociación verbal.

Mi misión fue convertir esa intuición comercial en una funcionalidad nativa que el comerciante pudiera ejecutar sin salir de la app de cobro.

Desafío

Diseñar una solución nativa en el POS que eliminara la necesidad de herramientas externas, reduciendo el tiempo de cobro y la carga cognitiva del comerciante al dividir una cuenta — sin importar el volumen de transacciones del negocio.

Para ello partí de dos preguntas: ¿Qué factores influyen en cómo un comercio decide dividir una cuenta? y ¿cómo acompañar esa necesidad con una interfaz clara, ágil y sin fricciones, que siga sintiéndose una herramienta de cobro y no de venta?

Enfoque de investigación

Lideré un estudio que combinó investigación cualitativa profunda con validación cuantitativa amplia, en cuatro fases. El reto operativo más grande no fue metodológico, sino de acceso: el comerciante del giro restaurantes vive en su negocio y no se desplaza a una oficina corporativa para un taller.

Para garantizar una muestra diversa combiné cuatro canales de reclutamiento en paralelo: alianza con el equipo Comercial para llegar al parque activo de POS, campañas de mailing segmentadas al giro, network personal y referidos, y referencias internas de otros equipos. Para la fase cuantitativa me apoyé en el área de Métricas, que aportó el know-how de investigación cuantitativa para diseñar y procesar la encuesta.

Las cuatro fases de investigación:

Descubrir · Validación de necesidad (cualitativa): Entrevistas 1 a 1 con 11 comercios del giro bares, restaurantes y hoteles.
Descubrir · Validación de hipótesis (cuantitativa): Encuesta a 7,074 usuarios de los segmentos Restaurantes, Bares y Discotecas, y Hoteles, en alianza con el área de Métricas.
Definir · Talleres de co-creación (in house y en campo):
- Taller in house (6 usuarios).
- Taller en campo, comercio “Tori” (7 usuarios).
Validar · Taller de validación de la solución (in house): 16 usuarios de distintos comercios para elegir entre las versiones diseñadas.

Talleres de co-creación: in-house en Niubiz y en campo con meseros del comercio Tori

Principales hallazgos de los métodos usados

Dolor y JTBD

La mayoría de usuarios experimenta el dolor, rompe con su JTBD.

Frecuencia y work-arounds

Cantidad de veces al mes que aparece el dolor. Work-arounds (manuales) del usuario. Facilidad del proceso (medio alta).

Segmentación

Segmentos económicos y porcentaje del mercado que podría usar la funcionalidad.

Protocolo de atención

Protocolo de atención para cobrar una cuenta dividida (similar en cada segmento económico).

Evaluación de flujos

Validación de flujo vs. expectativas del usuario. Hallazgos preliminares sobre usabilidad y componentes de la interfaz.

Alcance y trade-offs

Balance entre expectativas de usuarios y alcance del equipo de producto.

Flujo UX

Arquitectura de la información en App de cobro. Expectativas para la solución.

Tipos de división

Tipos de división de cuenta: por consumo y por partes iguales. Necesidad de un toma pedidos.

La decisión: no convertir una app de cobro en una app de venta

En los talleres aparecieron dos modelos mentales del usuario: división en partes iguales y división por consumo individual. El segundo requería identificar qué producto consumió cada comensal, lo que abría la puerta a integrar un toma pedidos dentro de la app.

Era tentador — resolver el caso más complejo habría diferenciado aún más al producto. Pero tomé la decisión de cortar el toma pedidos del alcance por dos razones que detecté temprano: desvirtuaba la arquitectura de información de la app, que dejaría de ser una herramienta de cobro para parecer una de venta; y el propio usuario lo descartó — en el taller de campo mencionaron que cargar productos antes de dividir sería un paso extra, no un atajo.

Diseñé entonces dos flujos diferenciados, manteniendo la app dentro de su categoría: una herramienta para cobrar, no para vender.

“Debe ser sencillo como usar una calculadora.” — Comerciante, taller de co-creación

“No debería depender de lo que ingrese el usuario.” — Comerciante, taller de co-creación

1. Split the Bill simple.

2. División de cuenta con un toma pedidos.

Validación de la propuesta

Reducir el riesgo de sesgo

No bastaba con dos opciones y la venia de producto. Llevé ambos flujos a un taller de validación in house con 16 usuarios reales antes de definir el diseño final.

Priorizar ante la tensión

Ante la tensión entre el alcance de producto y las expectativas de usuarios, tomé decisiones de priorización que derivaron en un flujo unificado con menor fricción en el caso más frecuente. Diseñé el happy path y los unhappy paths en Figma.

Preparación para entrega

Preparé el hand-off con desarrollo y el refinamiento en conjunto con producto y sus devs, asegurando trazabilidad entre los flujos diseñados y las historias de usuario.

Taller de validación de la solución con usuarios

Taller in-house de validación con 16 usuarios

Entrega a stakeholders

Hand-off a desarrollo

Realicé el hand-off con los equipos de producto y desarrollo. Conduje una reunión de refinamiento para alinear expectativas y aseguré la trazabilidad entre los flujos diseñados y las HUs.

Oportunidades de mejora

Identifiqué dos mejoras clave: agilizar las reuniones para evitar dilaciones en la toma de decisiones y evitar incluir la co-construcción de HUs dentro del pipeline de diseño.

Seguimiento y QA

Di seguimiento cercano a los avances de desarrollo y, al llegar a QA, validé que se respetara la UX propuesta y los lineamientos de UI, registrando observaciones y acordando ajustes con el equipo.

Gestión de versiones

Propuse contar con acceso a Jira o a un sistema de versionado de documentos para mejorar el control de cambios y la trazabilidad de decisiones a lo largo del proyecto.

Resultados del lanzamiento

Feature lanzada y adoptada por 361 comercios en su primer mes de activación, con 7,630 transacciones procesadas en restaurantes, bares y hoteles del mercado local.

361 de 20,400 comercios activos · 1.77% Comercios usando STB

676 de 53,500 terminales · 1.26% Terminales POS activados

7,630 de 40.6M transacciones · 0.019% Transacciones procesadas

Datos del primer mes desde el lanzamiento de la feature. Adopción en giros restaurantes, bares y hoteles del mercado local.

Lo que decidimos no medir, y lo que cambiaría hoy

El lanzamiento se realizó sin KPIs específicos definidos por Producto. La función del equipo de diseño fue de discovery y entrega; la definición de metas cuantitativas correspondía a Product Owner.

Si rehiciera este proyecto hoy, lo primero que pediría antes de iniciar el discovery sería una sesión de alineamiento con PO para definir tres cosas: qué métrica de negocio movería este producto, qué baseline tenemos, y qué consideramos éxito en el primer mes. No para asumir responsabilidad sobre el resultado, sino para que las decisiones de diseño se tomen sabiendo contra qué se evaluarán. Es el aprendizaje que más valor le da este proyecto a los siguientes.

Split the Bill: cobro dividido en restaurantes para Niubiz