Cuando cada proyecto cobra distinto: el costo operativo de no estandarizar la cobranza.

Proyecto Norte manda recordatorios cinco días antes del vencimiento. Proyecto Centro los manda el mismo día. En uno, comercial autoriza prórrogas; en otro, cobranza decide si escala; en un tercero, finanzas descubre el acuerdo cuando intenta conciliar. Todos pertenecen a la misma desarrolladora, pero cada equipo opera con reglas distintas.

Esa variación suele justificarse como flexibilidad: cada desarrollo tiene productos, compradores y ritmos propios. El problema aparece cuando también cambian, sin una razón de negocio, las referencias de pago, los responsables, los formatos de estado de cuenta, la forma de registrar excepciones y hasta la definición de un saldo vencido.

La tesis es simple: una desarrolladora puede adaptar su cobranza por proyecto sin inventar una operación nueva para cada uno. Estandarizar no significa tratar igual todos los casos. Significa decidir qué debe ser común, qué puede variar y quién autoriza cada excepción.

La variación que parece local termina costando en toda la empresa

Cuando cada proyecto cobra a su manera, el costo no se queda en el equipo que da seguimiento. Se reparte entre comercial, finanzas, operaciones y dirección.

La cartera deja de ser comparable

Si un proyecto considera vencido un pago al día siguiente y otro espera una semana; si uno registra promesas de pago y otro solo notas libres; si cada reporte usa categorías diferentes, sumar la cartera no produce una visión confiable.

Dirección puede ver una cifra consolidada, pero no necesariamente puede responder:

• ¿Qué parte del atraso es reciente y cuál requiere escalamiento?
• ¿Qué proyecto recupera mejor después del primer recordatorio?
• ¿Dónde hay más prórrogas, pagos parciales o acuerdos fuera del calendario?
• ¿Qué saldo está realmente vencido y cuál tiene una excepción autorizada?
• ¿Qué flujo esperado tiene evidencia suficiente para incluirse en la proyección?

Sin definiciones comunes, comparar proyectos equivale a comparar etiquetas, no operaciones.

Cada movimiento de personal obliga a reaprender el proceso

Una persona que cambia de proyecto no solo aprende nuevos compradores y unidades. También aprende otra hoja de cálculo, otro orden de seguimiento, otro formato de mensaje, otras reglas de escalamiento y otra forma de entregar información a finanzas.

El conocimiento se vuelve local y frágil. Si la persona que “sabe cómo se cobra aquí” se ausenta, el equipo reconstruye el proceso desde chats, archivos y memoria. La capacitación se alarga porque no existe un estándar que sirva como punto de partida.

Las excepciones pierden trazabilidad

Los casos especiales son inevitables: una prórroga, un pago parcial, una bonificación, una fecha modificada o una penalización en revisión. Lo riesgoso no es tener excepciones, sino administrarlas con criterios distintos y sin un registro común.

Cuando una excepción vive solo en WhatsApp, el siguiente recordatorio puede contradecir el acuerdo. Finanzas puede aplicar el pago con otra interpretación. El estado de cuenta puede mostrar un saldo que comercial ya prometió ajustar. El comprador termina coordinando a la desarrolladora al reenviar conversaciones entre áreas.

La experiencia del comprador depende del proyecto que le tocó

Dos compradores de la misma desarrolladora pueden recibir información muy distinta. Uno tiene una referencia clara, calendario actualizado y confirmación de pago. Otro debe preguntar cuánto debe, a qué cuenta depositar y si su comprobante fue recibido.

La inconsistencia no solo genera más mensajes. También dificulta establecer expectativas: cuándo se confirma un pago, qué documento recibe el comprador, por qué canal se atiende una aclaración y cuánto tarda una corrección.

Qué sí conviene estandarizar

Un estándar útil no empieza por imponer la misma plantilla de Excel. Empieza por definir un lenguaje operativo común.

1. Estados y fechas

Todos los proyectos deberían compartir definiciones mínimas para conceptos como:

• Pago próximo a vencer.
• Pago vencido.
• Pago parcial.
• Promesa de pago.
• Excepción en revisión.
• Excepción autorizada.
• Pago recibido pendiente de identificar.
• Pago identificado pendiente de aplicar.
• Pago aplicado y conciliado.

También conviene definir qué fecha dispara cada estado. Un depósito recibido no necesariamente equivale a un pago conciliado; distinguirlos evita que cobranza cierre casos antes de que finanzas pueda confirmarlos.

2. Datos obligatorios por comprador, unidad y pago

El estándar debe precisar qué información necesita la operación para seguir un caso sin depender de quien lo conoce de memoria. Como mínimo:

• Proyecto, unidad y comprador.
• Esquema de pago vigente.
• Concepto, monto y fecha de cada obligación.
• Referencia o identificador para el pago.
• Estado actual y fecha del último cambio.
• Comprobante, cuando aplique.
• Responsable del siguiente paso.
• Excepción, autorización y vigencia.
• Historial de comunicaciones relevantes.

El canal puede variar. Los campos indispensables no deberían hacerlo.

3. Secuencia de seguimiento

No todos los compradores requieren el mismo mensaje, pero la operación sí necesita una secuencia base: cuándo se recuerda, cuándo se confirma, cuándo interviene una persona y cuándo se escala.

Por ejemplo:

1. Recordatorio preventivo antes del vencimiento.
2. Confirmación el día de pago.
3. Seguimiento si no hay pago o respuesta.
4. Clasificación de la causa del atraso.
5. Asignación de responsable y fecha compromiso.
6. Escalamiento según monto, antigüedad o riesgo.
7. Cierre cuando el pago queda aplicado y conciliado.

Cada proyecto puede ajustar tiempos o mensajes por tipo de producto. La lógica y los estados deben permanecer comparables.

4. Responsables y niveles de autorización

Para cada evento debe existir un dueño claro. Cobranza puede dar seguimiento; finanzas puede validar aplicación y conciliación; comercial puede aportar contexto; dirección puede autorizar determinadas excepciones.

La pregunta práctica no es solo “¿quién atiende al comprador?”, sino:

• ¿Quién puede mover una fecha?
• ¿Quién autoriza una prórroga o condonación?
• ¿Quién cambia el esquema de pago?
• ¿Quién confirma que un depósito quedó aplicado?
• ¿Quién resuelve una diferencia entre contrato, promesa comercial y operación?
• ¿Quién cierra el caso y deja evidencia?

Si dos áreas pueden decidir lo mismo sin una jerarquía definida, la excepción no tiene dueño.

5. Reportes y métricas

Una vista consolidada requiere reglas iguales para contar. Conviene acordar al menos:

• Saldo por vencer en 7, 15 y 30 días.
• Cartera vencida por rango de antigüedad.
• Monto con promesa de pago vigente.
• Pagos recibidos pendientes de identificar o aplicar.
• Excepciones abiertas y días sin resolución.
• Tiempo entre recepción, aplicación y conciliación.
• Recuperación después de cada etapa de seguimiento.

No hace falta empezar con un tablero complejo. Una métrica definida igual en todos los proyectos vale más que diez reportes que no pueden compararse.

Qué puede variar sin romper el estándar

Estandarizar no significa ignorar diferencias reales. Puede tener sentido variar:

• El calendario según el contrato y el esquema de pago.
• El tono de los mensajes según el segmento.
• Los días de anticipación según el tipo de obligación.
• Los niveles de escalamiento según monto o riesgo.
• Las cuentas bancarias y referencias por proyecto.
• Los documentos requeridos en ciertos productos.
• Las personas responsables según la estructura del equipo.

La regla es que cada variación debe tener un motivo, un responsable y una forma común de registrarse. Si una diferencia no puede explicarse más allá de “siempre se ha hecho así”, probablemente es deuda operativa.

Un marco para construir el estándar mínimo

No conviene rediseñar todos los proyectos al mismo tiempo. Es más útil construir una base común y probarla en la operación.

Paso 1: mapear las diferencias actuales

Tomen dos o tres proyectos y sigan el recorrido de un pago desde el calendario hasta la conciliación. Registren herramientas, responsables, estados, mensajes, autorizaciones y reportes.

El objetivo no es documentar el proceso ideal, sino observar el real.

Paso 2: clasificar cada diferencia

Para cada variación, pregunten:

• ¿La exige el contrato o el producto?
• ¿Mejora el control o la experiencia del comprador?
• ¿Existe porque el equipo usa otra herramienta?
• ¿Es una preferencia personal?
• ¿Compensa una falla de información en otra parte del proceso?

Esto separa la flexibilidad necesaria de la improvisación acumulada.

Paso 3: definir el núcleo no negociable

Elijan los estados, datos, autorizaciones, evidencias y métricas que serán comunes. Mantengan el núcleo pequeño: debe permitir que cualquier persona entienda un caso y que dirección compare proyectos sin reconstruir cada reporte.

Paso 4: crear reglas explícitas para excepciones

Una excepción debe indicar qué cambió, por qué, quién la autorizó, desde cuándo aplica y cuándo debe revisarse. Si no tiene esos elementos, es una nota; no una regla operativa.

Paso 5: medir adopción y resultado

Durante cuatro semanas, revisen una muestra de casos y calculen:

• Porcentaje con responsable y siguiente acción.
• Porcentaje de pagos identificados y aplicados sin intervención manual extraordinaria.
• Excepciones sin autorización o fecha de revisión.
• Tiempo para consolidar el reporte de todos los proyectos.
• Diferencias encontradas entre cobranza, finanzas y estado de cuenta.

Estos indicadores son operativos, no benchmarks externos. Sirven para comparar la desarrolladora contra su propio punto de partida.

Checklist para saber si la cobranza ya es comparable

• ¿Todos usan la misma definición de vencido, promesa de pago y conciliado?
• ¿Cada pago puede seguirse desde la obligación hasta su aplicación?
• ¿Las excepciones tienen autorización, vigencia y evidencia?
• ¿Existe un responsable visible para el siguiente paso?
• ¿Un integrante puede cambiar de proyecto sin reaprender toda la operación?
• ¿Dirección puede comparar cartera y recuperación con las mismas reglas?
• ¿El comprador recibe una experiencia consistente aunque cambie de desarrollo?
• ¿Las diferencias entre proyectos responden a una necesidad documentada?

Si varias respuestas son “no”, el problema no es falta de esfuerzo del equipo. Es que la desarrolladora está sosteniendo múltiples sistemas de cobranza bajo una sola marca.

El objetivo del estándar no es eliminar el criterio humano. Es reservarlo para decisiones que de verdad necesitan criterio: negociar una excepción, atender un caso sensible o priorizar un riesgo. Todo lo demás debería seguir reglas visibles, trazables y comparables.

Una buena revisión puede empezar con una pregunta concreta: si mañana dirección pidiera mover a una persona de cobranza entre proyectos y consolidar la cartera en una hora, ¿qué diferencias impedirían hacerlo? Esa lista es el primer borrador del estándar que hace falta.