JY ← Todos los proyectos Rent Index Engine
Nester2026

Rent Index Engine

Un flujo que recalcula y aplica automáticamente las actualizaciones de renta según el índice de precios de cada contrato, y sustituye un proceso manual que los gestores de propiedades tenían que repetir a mano cada mes.

RolProduct Designer & Product Manager
FechaFebrero 2026
Equipo1 Designer/PM · equipo de desarrollo en el handoff
01 — Contexto

Con lo que lidian de verdad los gestores de propiedades cada año

Nester es una plataforma de gestión de alquileres para propietarios, agencias e inquilinos: contratos, facturación y comunicación, todo en un mismo lugar. Casi todas las líneas de renta recurrente están vinculadas a un índice de precios —normalmente el IPC de España—, que se actualiza una vez al año en una fecha distinta para cada contrato.

Hasta entonces, cada actualización era manual: recordar la fecha, buscar el nuevo valor, hacer el cálculo y editar la línea a mano. Entre 5 y 8 minutos por contrato. En una cartera de 5.000 inmuebles, eso sumaba unas 38 horas de trabajo al mes —un día y medio para cada persona de un equipo de 3—, con un coste estimado de 5.900 € al mes en horas de trabajo.

Los account managers lo señalaban como una de las quejas principales, y el equipo comercial escuchaba la misma pregunta de casi cada nuevo lead: ¿esto puede ser automático? Estaba en el backlog como prioridad alta desde 2024: todos coincidían en que importaba, pero nadie tenía un plan.

Account Management Hub: cómo se manifestaba la demanda de esta funcionalidad antes de que tuviera un sistema donde vivir
5.000inmuebles en la cartera
38 h/mesde trabajo manual al mes: unos 5 días completos de una persona
5.900 €/mescoste estimado de hacerlo a mano
02 — Reto

Por qué un recordatorio no era la respuesta

Un recordatorio que ya existía y nunca se construyó

Por fin se priorizó en septiembre de 2025, para el Q1 de 2026. Pero el primer intento venía de 2024: Tasks, una propuesta más amplia de gestión de tareas —no específica de índices— que incluía un recordatorio para las actualizaciones de índice y permitía a los gestores vincularlo. Tasks nunca se construyó: se quedó en el icebox.

Cómo se manifestaba la demanda de esta funcionalidad antes de que tuviera un sistema donde vivir

Dos problemas, no uno

Ni siquiera ese recordatorio lo habría resuelto: solo avisa, no calcula ni toca la línea de facturación. Así que el brief cambió: no recordarle a alguien que haga el trabajo, sino hacer que ocurra automáticamente, e involucrar a una persona solo cuando de verdad haga falta su criterio.

03 — Enfoque

Diseñar una actualización que funcione sola

Entender la operación, no el parche

Antes de diseñar nada, observé cómo lo resolvían realmente los gestores. Se repetían tres cosas: el propio trabajo manual, revisar las fechas de los contratos solo para saber si algo vencía, y avisar a los inquilinos con suficiente antelación: al menos un mes, no el día anterior.

Extender lo que ya funcionaba

Nester ya tenía un motor de facturación recurrente: los contratos generan facturas automáticamente, con su propio calendario, sin que nadie las cree a mano. La actualización del índice era un problema con la misma forma, así que, en lugar de un sistema aparte, extendimos esa misma línea recurrente y añadimos el índice como una propiedad más.

El verdadero beneficio fue una vista nueva, “Actualización masiva”, donde una vez por semana el gestor podía ver todas las actualizaciones próximas y resolverlas en un par de clics: días de trabajo manual convertidos en unos minutos.

Acertar con la lista de índices

Quedaba por decidir qué índices soportar. El equipo daba por hecho que con IPC e IRAV bastaba; en lugar de diseñar sobre esa suposición, lo probamos directamente con clientes de España y México, incluido Vivia, nuestro mayor cliente, a quien preguntamos qué usaba realmente además de esos dos.

Así apareció el IGC —usado como tope legal en 2022–2023— y un caso que no habíamos previsto: inmuebles no residenciales con un porcentaje fijo. México sumó un índice propio de su mercado. El selector salió con cinco opciones en lugar de dos: IPC, IRAV, IGC, INPC y manual/fijo. Dejamos el tope mínimo/máximo fuera de la v1 para no retrasar el lanzamiento; el equipo técnico dejó preparados los campos en la base de datos.

El camino descartado habría duplicado fechas, cálculos y notificaciones en un sistema aparte, desconectado de lo que el negocio ya sabía de cada contrato. El que lanzamos añade el índice como una propiedad más de la línea de facturación recurrente existente y reutiliza el mismo motor de principio a fin.
04 — Solución

Qué se construyó, de la pantalla al backend

Cómo se configura una línea

Cada línea se configura una sola vez, al crear el contrato: si es actualizable, con qué frecuencia (de mensual a anual) y cuál de los cinco índices aplica.

Un campo resultó más importante de lo esperado: “fecha de próxima actualización”, que le indica al sistema cuándo volver a revisar una línea. Fue clave al migrar contratos antiguos: sin él, el sistema habría asumido que todos los contratos tenían que actualizarse desde cero —desde la firma, a veces años atrás— y habría marcado al instante cientos de contratos ya gestionados como vencidos. Configurar bien este campo permitió que cada contrato retomara desde su próxima fecha real, en lugar de reiniciar todo su historial.

A partir de ahí, el sistema sigue la fecha por sí solo: el gestor solo confirma el porcentaje cuando toca (más sobre esto en la Reflexión) y, una vez confirmado, se aplica y se notifica automáticamente.

Vista de facturación recurrente.

Una vista pensada para supervisar

Creamos una vista “Actualización” con cuatro pestañas: Pendientes, En proceso (que avisa si la notificación al inquilino quedó desactualizada tras una edición posterior), Completadas e Ignoradas. Las filas se pueden editar en bloque desde un único modal: definir el porcentaje, elegir si notificar a los inquilinos y aplicarlo a toda la selección.

Vista y proceso de actualización masiva

Dos puntos de contacto más: integración con el calendario (pedida por account management) y dos emails mensuales opcionales, uno para el gestor y otro para el inquilino. El dashboard de inicio incorporó una nueva tarjeta de “Actualizaciones pendientes” en lugar de la antigua de “Inmuebles/Propietarios”.

Vista de calendario con las próximas actualizaciones y tarjeta de actualizaciones pendientes
Recordatorio mensual para el gestor y recordatorio para el inquilino

Hecho para durar, sobre un stack que no lo estaba

Proceso: presenté el enfoque, escribí el PRD completo (49 páginas, con Google AI Studio), hice sesiones de preguntas y respuestas con los desarrolladores y después un test interno de 4 días que hice yo misma, contrato por contrato, registrando cada incidencia.

05 — Impacto

890 actualizaciones y creciendo cada mes

Lanzado el 23 de febrero de 2026. El uso creció de forma sostenida, sin un pico seguido de estancamiento: 36 → 115 → 185 → 250 actualizaciones de abril a julio, una bajada a 207 en agosto (por las vacaciones) y 97 en lo que va de septiembre. Hoy hay 85 pendientes y 1 ignorada. Incluso el pico de julio queda por debajo de las 285–456 actualizaciones mensuales que acabaría necesitando la cartera completa: la opción es voluntaria, así que es un sistema que todavía está creciendo hacia su escala total, no un despliegue terminado.

7.238 líneaslíneas recurrentes con un índice configurado hoy
890 actualizacionesaplicadas automáticamente desde el lanzamiento, sin volver a introducir datos a mano
25 clientesnuevos clientes captados desde el lanzamiento de la funcionalidad
~8%de los clientes que se habían ido justamente por no tenerla volvieron
Datos extraídos directamente de la base de datos de producción.
06 — Reflexión y próximos pasos

Lo próximo que impulsaría

Tanto la opción de actualización como el email mensual son opcionales y vienen desactivados por defecto: la decisión correcta para lanzar con seguridad, pero significa que muchas líneas que podrían usarlo aún no lo tienen activado, simplemente porque nadie ha entrado a hacerlo.

El siguiente paso no es una funcionalidad más grande, sino una más pequeña: activarla por defecto en las líneas que cumplen los requisitos, en lugar de depender de que alguien se acuerde. Una automatización que todavía necesita activación manual está hecha solo a medias.

El paso más grande: conectar directamente con el organismo oficial que publica cada índice, para que Nester sugiera el porcentaje en lugar de que el gestor lo busque a mano. No era viable dentro de los plazos de este proyecto, pero es el siguiente paso natural.

Siguiente proyecto · Nester · 2024

Design System

→Ver case study