De perseguir pagos a un sistema que cobra solo

El contexto

Cobrar dependía de perseguir a alguien

Habitanto administra condominios: la cuota mensual (la "expensa"), el seguro, cuotas extraordinarias, consumo de gas. Cuando llegué, cobrar todo eso era, en la práctica, trabajo manual del administrador: identificar quién debía, contactarlo, explicarle cómo pagar, y volver a intentarlo si no respondía.

Del lado del residente el problema era el espejo: pagar significaba entrar a resolver un cargo a la vez, sin una vista clara de cuánto debía en total ni una forma simple de ponerse al día. Dos personas resolviendo el mismo problema de dinero, cada una a ciegas de lo que hacía la otra.

Pieza 01 · El proceso

Antes de una sola pantalla final, mapeamos cada camino

Un flujo de pagos no es una pantalla, es un árbol de decisiones: ¿la suscripción ya está activa o no? ¿el pago es de contado o diferido? ¿tiene tarjetas guardadas o necesita agregar una? ¿el pago se aprueba o se rechaza? Antes de diseñar la versión final, documentamos cada escenario completo, pantalla por pantalla, para no descubrir un caso sin resolver a mitad de la implementación.

Estas capturas están maquetadas sobre la versión de la app que la compañía ya tenía en producción, no sobre el diseño nuevo. Ahí resolvimos la lógica de cada flujo de pago antes de trasladarla al rediseño que ves en el resto de este caso.

Pieza 02 · El checkout

De un cargo a la vez, a un solo pago

Construimos una pasarela de pago propia, Habipay, con tarjetas guardadas y el costo del medio de pago siempre visible como línea aparte, nunca escondido dentro del total. Pero el cambio real estuvo antes del checkout: en vez de pagar la cuota, el seguro y una extraordinaria por separado, el residente ahora los marca con checkboxes y los paga todos juntos, en una sola transacción.

No era solo una mejora de conveniencia. Cada pago separado era una oportunidad más de que el residente abandonara antes de terminar, y una llamada más que el administrador tenía que hacer si algo quedaba sin pagar. Consolidar el checkout reducía fricción de los dos lados a la vez.

Pieza 03 · Más allá de la expensa

Si ya paga el condominio desde el celular, ¿por qué no también el agua?

Ampliamos qué significaba "pagar" dentro de Habitanto. Construimos un marketplace de servicios del hogar dentro de la misma app (agua, luz, gas, TV, internet y telefonía) donde el residente busca su proveedor, revisa el detalle de la factura y paga con las mismas tarjetas que ya tenía guardadas para la expensa.

El mismo patrón de checkout consolidado se repite aquí: recibos con estado (aprobado, rechazado), alertas antes del vencimiento de un servicio, historial descargable y compartible. Una sola relación de pago, en vez de una app para el condominio y media docena de apps de servicios sueltas.

Pieza 04 · Pago automático

Conseguir que la gente dejara de pagar a mano

El pago automático resolvía el problema de raíz: si la cuota se cobra sola cada mes, nadie tiene que perseguir a nadie. El reto era la activación: nadie prende un interruptor solo porque existe. Y no todos los edificios ofrecían el mismo incentivo: en algunos, el residente asumía la comisión del medio de pago y activar el automático le daba una tarifa preferencial más baja (4,50% → 4,05%); en otros, el edificio absorbía esa comisión y el incentivo eran millas acumulables por cada pago. Diseñé los dos caminos, con su propio mensaje, probando varias versiones de copy en los banners junto con marketing.

La regla que no podía romper

Explicar un "no", en vez de solo mostrarlo

La tarifa preferencial venía con una permanencia mínima de 12 meses: una regla del negocio, no una decisión de diseño. En vez de simplemente bloquear el botón de desactivar, diseñé una pantalla que explica por qué no se puede todavía, cuántos pagos lleva la persona, y la fecha exacta en la que sí podrá hacerlo.

Un botón bloqueado sin explicación se siente como una trampa. Una fecha concreta y el progreso hasta ahí ("llevas 1 de 12 pagos") convierte la misma restricción en información que la persona puede usar: sabe exactamente qué esperar y cuándo.

Pieza 05 · El otro lado

Resolver la mitad del residente no resolvía la del administrador

Todo lo anterior resuelve cómo paga el residente. Pero el administrador seguía necesitando saber quién debe y cómo cobrarle sin perseguirlo uno por uno. Diseñé un dashboard de morosidad que muestra, de un vistazo, cuántas unidades están en mora y el promedio de días que tardan en pagar. Desde ahí, un botón envía un link de pago directo a cada unidad morosa, con un mensaje bilingüe (español/inglés) generado automáticamente.

Y para lo que se paga por fuera de la app (transferencia bancaria, efectivo), diseñé un registro manual donde el administrador concilia el pago contra las cuentas específicas que cubre, con su número de comprobante. El mismo patrón de "seleccionar qué cuentas cubre este pago" que ya existía del lado del residente, ahora del lado de quien cobra.

Pieza 06 · Más allá de los pagos

El sistema de pagos vivía dentro de dos apps enteras

Habipay y la cobranza fueron el proyecto más profundo, pero el encargo completo fue rediseñar la app del residente y la app del administrador de punta a punta: reservar áreas comunes, un marketplace de anuncios entre vecinos, invitar visitas con QR, y el resto de las herramientas de gestión del administrador, siempre con el mismo criterio: menos pasos manuales, más claridad de estado en cada pantalla.

Fuera de esta página

• App Guardia Una tercera app, para el personal de seguridad: gestión de tareas con prioridad, registro de paquetes y reporte de emergencias o novedades en portería.
• Panel Web La versión de escritorio para el administrador (cobranza, reportes financieros y gestión de novedades), para el trabajo que se hace mejor desde una computadora que desde el celular.
• Sitio web Rediseño del sitio institucional de Habitanto.