El módulo de Ventas de MOME: lo que viene después del sí

Hace unos meses lanzamos el nuevo CRM de MOME para que dejara de ser un registro de lo que ya pasó y le dijera al ejecutivo dónde está su próxima venta. Ese trabajo llega hasta un punto preciso: el cliente elige una unidad y decide reservarla. Ahí empieza el embudo de venta, la mitad del proceso donde se reciben los ingresos: cobrar la reserva, aprobar el descuento, emitir la carta de oferta, conseguir la firma y sacar la unidad de circulación.

Pregúntale a un equipo comercial de qué cotización salió una reserva que están cursando y vas a ver lo que pasa: alguien abre una planilla, encuentra la fila con el nombre escrito a mano y empieza a reconstruir. El problema no es que falten datos: es que cada registro nace huérfano. La reserva no sabe de qué cotización salió, la cotización no sabe a qué contacto corresponde, y ninguna sabe qué unidad está tomando.

Casi todo el software comercial tiene dónde anotar esas cosas. Anotarlas no es lo mismo que vincularlas.

El módulo de Ventas administra la venta completa, de la reserva a la entrega. La reserva es la etapa que está disponible hoy, y es de la que trata este artículo. Pero lo que hace que funcione no es el módulo: es que la reserva nace vinculada a su cotización, a su contacto y a su unidad, las mismas que ya viven en el sitio del proyecto, en el agente de IA y en el tablero. No hay que conectarlas, porque nunca estuvieron separadas.

Nadie marca una reserva como pagada

En casi cualquier proceso de venta hay un momento en que alguien abre la reserva y cambia un campo: de «esperando pago» a «pagado». Un campo escrito a mano se puede escribir antes de tiempo, tarde, o nunca. Lo que queda anotado no es lo que pasó: es lo que alguien alcanzó a anotar.

Acá ese campo no existe. Una reserva avanza porque se cargó un comprobante, queda aprobada porque el jefe de ventas revisó con qué precio sale la unidad, y queda confirmada porque volvió el documento firmado. Si el estado no depende de que alguien se acuerde de escribirlo, lo que venga después tampoco depende de nadie.

Cada paso tiene un dueño y una acción

Al modelar el proceso de reserva nos enfocamos en responder dos preguntas para cada paso: ¿de quién es el turno? y ¿cuál es la acción que lo hace avanzar? Una reserva casi nunca deja de avanzar por algo difícil, sino porque nadie tiene claro lo que ya está realizado y el paso siguiente.

El estado representa el último paso alcanzado, y es el panel el que muestra la tarea pendiente: de quién es el turno y el botón que corresponde. Cuando le toca a otro, ese botón sencillamente no está. Lo que se gana no es velocidad en un paso: es que administrar la reserva deje de ser un trabajo.

Acá la IA no conversa: ordena el día

Apenas entras al módulo de Ventas, nuestra IA te recomienda qué reservas revisar antes del cierre del día y por qué: la que venció, la que está por vencer, la que quedó esperando una acción tuya.

Y arriba de todo, una barra de indicadores resume el estado del proyecto: cuántas UF hay en venta, cuántas reservas están vivas, cuántas en riesgo y cuánto demora en promedio una en confirmarse. Un ejecutivo ve las suyas; un jefe de ventas, las de todo el proyecto.

Crear una reserva es confirmar, no redactar

Una reserva nace de una cotización que ya existe: el ejecutivo elige al cliente y su cotización, revisa los números y confirma. Y eso evita una familia entera de errores: la reserva no puede quedar con un precio distinto al cotizado porque no se vuelve a ingresar. Si otro alcanzó a reservar esa unidad un minuto antes, tampoco queda una reserva a medias: no se crea, y se sabe en ese momento.

Las aprobaciones dejan de pedirse por correo

Aprobar un descuento o dar por buena una transferencia casi siempre ocurre fuera de cualquier sistema: un correo al jefe de ventas, un «dale» de vuelta y a seguir. Funciona hasta que hay que responder quién autorizó qué. Por eso el módulo tiene un sistema de solicitudes propio.

El aviso igual llega por correo, pero mandar un correo y quedarse esperando es un acto ciego: no sabes si lo vio ni cuándo lo contesta, y en un proyecto grande compite con otros cincuenta. Acá la solicitud es un estado visible de la venta, y nadie depende de que un correo no se pierda.

No son cuatro herramientas conectadas: es una sola

Una reserva tiene un plazo para pagarse y, si se cumple sin comprobante, vence. Reflejar eso no basta: un estado que cambia solo no sirve de nada si nadie lo ve a tiempo. Por eso la reserva se marca a medida que la fecha se acerca y sube hasta quien puede hacer algo, mientras todavía se puede. Y cuando vence, vencida no es cancelada: la unidad sigue tomada, y darle un plazo nuevo o cancelarla son decisiones de alguien.

Y cuando una reserva se paga, la unidad sale de circulación en todas partes a la vez: deja de cotizarse en el sitio del proyecto, deja de ofrecerse en un WhatsApp a las once de la noche y desaparece del inventario del equipo. No es difícil bajar una unidad del sitio: es difícil acordarse de hacerlo el mismo día, en todos los lugares donde estaba publicada, cada vez.

Nada de eso pasa porque hayamos conectado bien cuatro herramientas. El sitio del proyecto, el agente de IA, el tablero del CRM y Ventas son uno solo, donde la cotización, el contacto y la unidad son una cotización, un contacto y una unidad, no cuatro copias que alguien mantiene parecidas.

La diferencia con «estar integrado» no es teórica. Dos sistemas integrados se sincronizan: hay campos que mapear, un momento en que uno no sabe lo que el otro ya sabe, y alguien que revisa que la sincronización siga funcionando. Acá no hay nada que sincronizar, porque no hay dos lugares, y donde no hay traslado no hay nada que se pueda quedar sin trasladar.

La cadena completa, no una carpeta ordenada

Acá se paga lo del principio. Ninguna reserva es una fila con un nombre escrito a mano: es un registro vinculado a su cotización, a su contacto, a su unidad y a sus documentos, y la cadena se recorre en los dos sentidos. Por eso cada venta tiene una ficha con todo lo que hay que saber: en qué paso va, qué se pagó y con qué respaldo, y una bitácora con cada movimiento y quién lo hizo.

Los documentos los produce la plataforma con los datos reales de la operación, no una persona rellenando una plantilla. Y nada se pisa: cuando llega la carta firmada, la anterior queda marcada como reemplazada, con su fecha.

El embudo de venta muestra el avance de cada reserva

Reservar no saca al cliente del tablero: la tarjeta pasa al embudo de venta, y ahí muestra cuánto lleva avanzado el proceso sin necesidad de abrirla.

Todo esto está disponible hoy para la reserva. Las etapas que siguen, promesa y escritura, van a recibir el mismo tratamiento en los próximos meses.

Lo que en realidad cambia

Un módulo de reservas suena a trámite. Es la diferencia entre un descuento autorizado y uno recordado; entre un plazo que vence solo y uno que alguien tiene que ir a mirar; entre una unidad que deja de ofrecerse en todas partes al mismo tiempo y una que alguien tiene que acordarse de bajar del sitio. Ninguna de esas cosas es difícil por separado; lo difícil siempre fue que ocurrieran todas, el mismo día, cada vez.

Hay una prueba simple y no requiere ver ninguna demo. Toma una reserva que tu equipo esté cursando ahora mismo y pregunta de qué cotización salió, qué unidad tiene tomada y quién autorizó ese descuento. Si la respuesta existe pero solo la puede armar una persona en particular, de memoria, el problema no es tu equipo: es que nadie vinculó nunca esas cosas entre sí.