Cómo organizar la ficha de un contrato en Rentaloop

Una ficha = un contrato: partes, índice, cobros, documentos y liquidaciones. No un cliente suelto.

Organizar la ficha de un contrato en Rentaloop es tratar a la locación como el objeto: partes, inmueble, índice, cobros, documentos y liquidaciones en un solo lugar. No es un “cliente” suelto de CRM. Un inquilino con dos deptos son dos fichas. Un edificio con diez alquileres, diez fichas. El índice mal puesto se paga en el aviso. El PDF lejos de los cobros se paga en el egreso. La ficha es el libro diario de esa locación.

Núcleo: lo que si está mal, el resto es teatro

Partes (locador, locatario, garantes), inmueble, plazos, canon vigente, índice y frecuencia. Eso nace del borrador de la IA o de tu tipeo. Revisalo. La guía de calidad está en revisar el borrador. Un segundo locatario comido no existe el día de la mora. Un segundo locatario comido por el extractor no existe el día de la mora ni en la intimación.

El inmueble no es un renglón: es lo que se entrega y se rinde. Dirección, unidad, notas de PH. Datos de la ficha del inmueble es el recorte. Dos unidades en un solo contrato se pueden pactar; administrar se vuelve opaco. Casi siempre, una ficha por inmueble.

Movimientos: cobros, aumentos, estados

Cada período deja cobro, recibo, tal vez punitorios y expensas. Cada ajuste deja historial. La ficha es esa línea de tiempo. No un contacto con “notas de seguimiento”. Si el mismo locatario tiene otra unidad, el saldo no se comparte. Imputá. Varios contratos del mismo inquilino.

El asistente pregunta sobre esta ficha y las de la agencia, no sobre un “cliente”. “¿Cuánto debe Mitre 123?” es una pregunta de contrato. “¿Cómo está Juan?” no es un estado que Rentaloop venda. Oficio de administración, no de CRM. “¿Cómo está Juan?” no es un estado que el producto venda: el oficio es la locación, no el CRM.

  • Partes e inmueble correctos.
  • Índice y ancla de ajuste.
  • Historial de cobros del período.
  • Historial de aumentos aplicados.
  • Documentos de ingreso y contrato en el visor.

Papeles y cierre: la ficha no se tira

PDF, inventario, actas. Guardar inventario y PDF. Al egreso o rescisión, la ficha queda inactiva: fechas, saldos, depósito. No se formatea. El historial de cobros no se borra porque el contrato cerró. Eso diferencia un sistema de una carpeta que se archiva en el sótano digital.

Liquidaciones del dueño de esta unidad viven ligadas a lo cobrado acá. Si el titular tiene otras propiedades, el paquete se arma en la rendición, no fusionando fichas. Varios inmuebles. El paquete del dueño se arma en la rendición; no fusionando fichas de unidades distintas.

Cómo Rentaloop piensa la ficha frente a un CRM

En Rentaloop la carga, los aumentos, los cobros y las liquidaciones cuelgan del contrato. El CRM cuelga del contacto. Por eso el CRM no calcula el ICL. Organizar mal la ficha —un cliente, muchos deptos mezclados— es usar Rentaloop como si fuera CRM y perder el índice.

Usuarios del equipo ven la misma ficha. No hay “la versión de Laura”. Invitaciones: equipo. El dueño y el inquilino no tienen login. Reciben PDFs. El dueño y el inquilino no tienen login: reciben PDFs. El equipo ve la misma ficha, no “la versión de Laura”.

  1. Un contrato, una ficha.
  2. Operación mensual adentro, no en un Excel al costado.
  3. Documentos en el visor.
  4. Cierre sin borrado.
  5. Sin ficha-cliente que mezcle saldos.

Qué no es una ficha de Rentaloop

No es una ficha de captación. No es un aviso. No es un expediente de consorcio. No es un legajo laboral. No es un ticket de mesa de ayuda. Si tu equipo la usa para “tareas de venta”, se va a llenar de ruido y el ICL se va a perder.

No hay campos de scoring mágico. No hay un semáforo de “buen inquilino” vendido por el producto. Los informes de solvencia, si los pediste, se adjuntan. El software no los opina. Los informes de solvencia, si los pediste, se adjuntan; el software no los opina ni los puntúa.

Higiene: cuándo partir, cuándo cerrar, cuándo no fusionar

Partí fichas si hay dos unidades. Cerrá si hay egreso. No fusionés “porque es el mismo apellido”. Un edificio se maneja como muchas locaciones: edificio con varios alquileres. El dueño se liquida agrupado; el contrato se opera separado. El dueño se liquida agrupado; el contrato se opera separado, aunque el edificio sea el mismo.

Si la IA creó un duplicado, descartá el borrador de más. Dos fichas del mismo PDF son el germen del doble cobro. La higiene es semanal, no anual. Dos fichas del mismo PDF son el germen del doble cobro; la higiene es semanal, no anual.

Para seguir leyendo

Estos artículos cierran el tema y evitan que el lector se vaya a un resultado genérico:

Preguntas frecuentes

Preguntas frecuentes

  • Dos fichas. Comparten persona, no saldo. Un pago no cubre las dos a menos que lo imputes. El recibo y la mora son por contrato. El recibo y la mora son por contrato; un pago no cubre las dos unidades salvo imputación.

  • En los datos del contrato y en los PDFs de garantía. Si la IA no lo leyó, cargalo. Un fiador que no está en la ficha no está el día de la intimación. Si la IA no lo leyó, cargalo: un fiador ausente de la ficha no está el día de la intimación.

  • Sí. El historial de cobros no se borra porque el contrato cerró. Inactivo no es borrado. Vas a necesitar el expediente. Inactivo no es borrado: vas a necesitar el expediente si el depósito o los daños se discuten.

  • Del contrato. Ese es el diseño. Un CRM al revés. Si organizás por “cliente”, los índices y los saldos se pisan. Si organizás por “cliente”, los índices y los saldos se pisan: el diseño es del contrato.

  • Si el papel es un solo instrumento, es un debate. Operar se vuelve opaco. Casi siempre conviene un contrato —y una ficha— por inmueble. Operar dos inmuebles en una sola ficha se vuelve opaco el mes que uno paga y el otro no.

¿Todavía llevás tus alquileres en Excel?

Tratá cada locación como una ficha: partes, índice, cobros y papeles. El ciclo vive ahí; no en un contacto suelto.