Garantear

Contexto

Conseguir una garantía de alquiler en Argentina es, para la mayoría de las personas, una caja negra. Sabés que la necesitás. No sabés exactamente qué documentación presentar, cuánto tiempo demora, ni en qué estado está tu trámite mientras esperás.

El resultado es una experiencia que mezcla incertidumbre, llamados telefónicos y documentos que van y vienen sin que quede claro quién hace qué.

Garantear quería romper ese modelo con algo 100% digital. El desafío de diseño era doble: construir una interfaz clara para el solicitante y diseñar las comunicaciones operativas que acompañan cada hito del proceso.

Porque de nada sirve una plataforma bien diseñada si los emails que llegan son genéricos, confusos o no dicen qué hacer después.

El problema

El producto no era una sola pantalla ni un solo flujo. Era un sistema con varios actores y múltiples bifurcaciones según el estado del legajo: un cotizador, un portal de documentación, comunicaciones para cada momento clave, un área de riesgos, inmobiliarias, posibles cogarantes y un proceso de cierre.

Los estados posibles de un trámite eran muchos: cotización inicial, pre-aprobado, en revisión, devuelto por riesgos, rechazado, aprobado con o sin cogarante y garantía otorgada. Cada estado generaba una experiencia distinta y requería una comunicación distinta.

El problema real no era la falta de features. Era que cada actor del sistema veía un producto distinto, o no veía nada.

El solicitante no sabía en qué estado estaba su legajo. El área comercial recibía consultas por teléfono. Riesgos necesitaba documentación clara para avanzar. La inmobiliaria necesitaba confianza para seguir con la operación. Y el usuario, en el medio, esperaba una respuesta para poder alquilar.

Diseñar esto sin mapear primero los estados del sistema era imposible.

Approach

Dos principios estructuraron el trabajo.

Primero el estado, después la pantalla. La pregunta “¿qué pantalla diseño?” es prematura si no respondiste antes “¿en qué estado está el usuario, qué sabe, qué necesita saber y cuál es la siguiente acción posible?”. Ese mapa era el diseño real. Las pantallas eran la consecuencia.

Las comunicaciones son producto. En un proceso con alta fricción emocional, el email que llega también es parte de la experiencia. El usuario puede estar a punto de firmar un contrato, esperando una aprobación o recibiendo un rechazo. Diseñar esas comunicaciones como templates genéricos hubiera sido un error de alcance, no de ejecución.

Decisiones clave

El cotizador como punto de entrada

El primer contacto del usuario con el producto no podía ser un formulario de registro. Necesitaba ser una herramienta que le permitiera entender si el servicio le servía antes de comprometerse con nada.

El cotizador cumple esa función: anticipar condiciones, desdramatizar el proceso y habilitar una primera validación antes de la evaluación formal.

La decisión de poner esa herramienta al frente del funnel no era obvia, porque implicaba diferir el registro. Pero era la forma más clara de reducir la fricción real en la entrada al sistema.

Lo que descartamos: empezar por un formulario de datos personales. Es el patrón más común en servicios financieros y uno de los que más fricción genera. Si el usuario todavía no entiende si el servicio le sirve, no tiene sentido pedirle datos.

El portal como mapa del trámite

El portal del solicitante era la capa más importante del producto porque convertía un proceso opaco en una experiencia visible.

El usuario no necesitaba un dashboard lleno de accesos. Necesitaba responder tres preguntas simples: en qué estado está mi trámite, qué falta de mi lado y qué pasa después.

La decisión fue diseñar el portal alrededor del estado del legajo, no alrededor de secciones genéricas. La documentación, la revisión, las devoluciones, la aprobación y los próximos pasos se ordenan según el momento real del trámite.

Esto también ayudaba al equipo operativo. Si el estado estaba claro para el usuario, bajaban las consultas repetidas y cada comunicación podía apoyarse en una lógica ya visible dentro del producto.

Lo que descartamos: un portal administrativo con accesos planos a “documentación”, “mensajes” y “estado”. En este contexto, más navegación no significaba más claridad. Si una persona está esperando una aprobación para poder alquilar, lo más importante no es explorar la plataforma: es entender qué está pasando.

Comunicaciones que acompañan, no que informan

El bloque de trabajo más denso del proyecto fue el sistema de comunicaciones operativas. Cada pieza tenía que sostener el tono de marca en momentos de altísima tensión emocional para el usuario.

La pre-aprobación llega cuando alguien está a punto de firmar un contrato. El rechazo llega cuando tenía la expectativa de que iba a funcionar. La devolución por riesgos llega cuando el proceso se frena y no sabe por cuánto tiempo.

La decisión fue consistente en todos los estados: cada comunicación termina con un próximo paso concreto y un contacto humano identificado por nombre, teléfono y mail. No “el equipo de Garantear”: una persona.

Ese detalle cambia completamente cómo el usuario procesa la información que recibe.

Lo que descartamos: estados genéricos tipo “tu solicitud está en proceso”. Son informativamente válidos y emocionalmente inútiles. Un usuario que recibe ese mensaje sabe lo mismo que antes de recibirlo.

La bifurcación del flujo según cogarante

Cuando el legajo se aprueba, el flujo se divide según si existe o no cogarante. Con cogarante hay un paso adicional de firma electrónica que cambia los próximos pasos para el solicitante y requiere coordinación adicional.

La decisión fue no unificar las comunicaciones de aprobación en una sola pieza genérica con variables. Las experiencias son distintas en lo emocional y en lo operativo, por lo tanto merecen comunicaciones distintas.

La versión con cogarante explica explícitamente el paso de firma electrónica desde el primer mensaje de aprobación, para que el usuario llegue a esa instancia sin sorpresa.

Lo que descartamos: resolver la aprobación como un único estado. “Aprobado” no significa lo mismo en todos los casos. Según la estructura del legajo, puede abrir caminos operativos muy distintos.

El certificado preliminar y la gestión de expectativas

El certificado de aprobación preliminar fue uno de los artefactos más delicados del sistema.

Es un documento que el solicitante puede presentar en una inmobiliaria antes de la emisión formal de la garantía, lo cual tiene un valor práctico enorme. Pero no es la garantía. Confundir esos dos estados era un riesgo real.

La decisión fue incluir en el propio certificado una aclaración explícita: tiene carácter meramente informativo y preliminar, no implica emisión efectiva, y la garantía queda formalmente otorgada solo después del pago, la firma del contrato y el cumplimiento de todos los pasos.

Esa aclaración no es fine print. Es parte del diseño de contenido del documento, ubicada visiblemente y en lenguaje claro.

Lo que descartamos: tratar el certificado como un simple comprobante. En este tipo de producto, un documento mal explicado puede generar expectativas incorrectas, fricción comercial o problemas operativos posteriores.

Solución

El producto final tiene tres capas principales: el sitio comercial con el cotizador como punto de entrada, el portal del solicitante con seguimiento de estados y carga de documentación, y el sistema de comunicaciones transaccionales que cubre cada bifurcación del proceso.

El flujo completo, desde “¿cuánto me cuesta la garantía?” hasta “garantía emitida”, es navegable sin depender de llamados constantes. Cada hito del proceso tiene una comunicación que dice exactamente qué pasó, qué sigue y con quién hablar si algo no cierra.

El portal organiza la experiencia alrededor del estado del legajo. El usuario puede entender si tiene documentación pendiente, si el trámite está en revisión, si hubo una devolución, si fue aprobado, si requiere cogarante o si ya está listo para avanzar hacia la emisión final.

La solución no buscó sumar complejidad visual. Buscó hacer visible un proceso que antes era opaco.

Impacto

El cotizador ayudó a ordenar el punto de entrada al servicio, permitiendo que los usuarios entendieran condiciones generales antes de iniciar un trámite formal.

El portal del solicitante redujo la dependencia de consultas manuales al hacer visible el estado del legajo, la documentación pendiente y los próximos pasos.

El sistema de comunicaciones permitió acompañar cada hito del proceso con mensajes específicos, evitando respuestas genéricas en momentos sensibles como pre-aprobación, devolución por riesgos, rechazo o aprobación final.

La diferenciación entre aprobación con y sin cogarante ayudó a reducir malentendidos en el flujo de firma y preparación documental.

El certificado preliminar permitió darle al solicitante una herramienta útil para avanzar con la inmobiliaria sin confundir ese documento con la garantía formal emitida.

La plataforma pasó de un proceso mayormente opaco y telefónico a una experiencia digital con seguimiento visible, comunicaciones claras y mayor control sobre cada estado del trámite.