Mesa de ayuda y ventas con FINORA CRM

En este tutorial pones en marcha la mesa de ayuda de tu empresa, atiendes tickets de principio a fin (con su plazo de servicio, su escalamiento y su encuesta de satisfacción) y llevas a una interesada nueva desde su primer mensaje hasta el embudo de ventas. Todos los datos son ficticios.

El caso: trabajas en una empresa que vende y da soporte a un sistema de caja y de gestión. Ana Torres es agente del grupo Soporte nivel 1 y también atiende ventas; su supervisora es Gabriela Suárez. Tus clientes y contactos de ejemplo son Carlos Rondón (carlos.rondon@example.com), gerente de compras de Distribuidora Rondón, C.A.; María Fernández y José Pérez, que escribieron por WhatsApp y por la web; y Valeria Ríos (valeria.rios@example.com), una interesada nueva que llegó por el sitio web.

Qué debe estar listo antes (lo hace el administrador una sola vez)

• El paquete FINORA CRM (com.finora.lve.crm) instalado en el servidor.
• Tu usuario con un rol que vea el menú CRM (FINORA) (parte 2.1).
• Los feriados del año cargados en el calendario de la empresa (parte 3.2).
• Para las partes 5 y 11, alguien con permiso para activar programadores de procesos.

Sobre las capturas

Las capturas son de una instalación de prueba con datos ficticios: por eso los resúmenes, terceros y artículos llevan delante el prefijo ACADEMY-CRM. En tu empresa verás tus propios datos sin ese prefijo.

Parte 1. Qué trae FINORA CRM y cómo se organiza el menú

iDempiere ya trae un CRM básico: solicitudes (los tickets), clientes potenciales o leads (contactos interesados que todavía no son clientes), oportunidades de venta con sus etapas, campañas y actividades de contacto. FINORA CRM no crea un segundo sistema: usa esas mismas ventanas y les agrega lo que una mesa de ayuda y un equipo comercial necesitan en el día a día.

Necesidad	Qué usa del sistema base	Qué agrega FINORA CRM
Arrancar con un catálogo listo	Tipos, estados, categorías, grupos, resoluciones, respuestas estándar, etapas de venta	Un paso de Configurar empresa que los crea en español
Plazos de servicio (SLA)	Calendario y días no laborables	Horario hábil, políticas SLA por tipo y prioridad, fechas límite y estado SLA en cada ticket
Escalamiento	Responsable del ticket, supervisor del usuario, avisos	Un monitor programable que escala y avisa
Tickets desde correo, web o WhatsApp	Solicitud, contacto, tercero	Campo Canal y el proceso Crear ticket, también por API
Satisfacción del cliente	Solicitud	Encuesta de 1 a 5 al resolver
Base de conocimiento	Categorías de solicitud	Artículos con la solución, enlazados al ticket que resuelven
Priorizar leads	Cliente potencial, áreas de interés, actividades, oportunidades	Puntaje de 0 a 100 y grado A–D
Previsión de ventas	Oportunidades y etapas	Vista de embudo con monto ponderado por probabilidad
Indicadores de soporte	Solicitudes	Vista de tickets abiertos, vencidos, cumplimiento SLA y satisfacción promedio
Que no se olviden las llamadas	Actividades de contacto	Recordatorios automáticos al comercial

Todo queda reunido en la carpeta CRM (FINORA) del menú, con cuatro submenús:

Submenú	Entradas
Mesa de ayuda	Mis solicitudes, Todas las solicitudes, Crear ticket, Registrar satisfacción, Base de conocimiento
Ventas	Leads (clientes potenciales), Oportunidades de venta, Contactos y actividades, Campañas, Áreas de interés
Configuración	Tipos de solicitud, Categorías y estados de solicitud, Categorías de solicitud, Grupos de solicitud, Resoluciones, Respuestas estándar, Plantillas de correo, Procesador de solicitudes, Etapas de venta, Políticas SLA, Horario hábil, Reglas de puntuación de leads
Análisis	Embudo de ventas, Indicadores de soporte, Monitor de SLA, Puntuar leads, Recordatorio de actividades

Mis solicitudes muestra solo los tickets de los que eres responsable (o de tu rol); Todas las solicitudes, los de toda la empresa. Algunas ventanas abren con un título distinto de su entrada de menú: Leads (clientes potenciales) abre Cliente Potencial, Oportunidades de venta abre Oportunidad de Ventas y Categorías y estados de solicitud abre Estado de Solicitud.

La carpeta CRM (FINORA) con tres de sus cuatro submenús desplegados.

✕

Parte 2. Configurar la mesa de ayuda

2.1 El catálogo inicial

No hace falta crear el catálogo a mano. El proceso Configurar empresa, el mismo que prepara la localización venezolana, tiene tres pasos de CRM que crean todo en español sin duplicar nada si ya existe:

Paso	Qué deja
Catálogo	Categoría de estados Soporte FINORA con Nuevo, En progreso, Esperando cliente (pausa el SLA), Escalado, Resuelto y Cerrado; tipos Incidente, Solicitud de servicio, Consulta (predeterminado) y Reclamo; categorías Facturación, Acceso y usuarios, Inventario, Nómina, Fiscal y Otro; grupos Soporte nivel 1 y Soporte nivel 2; resoluciones Resuelto, Solución temporal, No reproducible, Duplicado y Rechazado; respuestas estándar Acuse de recibo, Solicitud de información y Cierre con solución; etapas de venta Prospecto 10 %, Calificado 25 %, Propuesta 50 %, Negociación 75 %, Ganada 100 % y Perdida 0 %; horario Lunes a viernes 8–17; cuatro políticas SLA; siete reglas de puntuación de leads
Programadores	FVE CRM Monitor de SLA (cada 15 minutos) y FVE CRM Recordatorio de actividades (de lunes a viernes a las 07:30), ambos inactivos
Acceso	Las ventanas del menú CRM para los roles que indiques, y la carpeta CRM (FINORA) en el menú propio de cada rol, si lo tiene

1. Abre Configurar empresa (menú Administración › Configuración) y elige tu Organización.
2. En Roles con acceso LVE escribe los roles que van a usar el CRM, separados por coma: por ejemplo Soporte, Ventas. Los roles automáticos ya tienen acceso; esto es para los roles manuales de tu empresa.
3. Marca Ensayo sin guardar y pulsa OK. El sistema no guarda nada: lista lo que haría, una línea por objeto, con el resultado PLANNED (lo crearía), UNCHANGED (ya existe) o SKIPPED (no aplica, con el motivo).
4. Revisa la lista. Si estás de acuerdo, ejecuta el proceso otra vez sin marcar el ensayo.
5. Una segunda ejecución termina en sin cambios: el proceso es seguro de repetir y nunca reescribe lo que ya adaptaste.

Ensayo sobre un tenant ya configurado: todas las líneas del CRM salen UNCHANGED (ya existen) y no se guarda nada.

✕

2.2 Revisar y ajustar el catálogo

El asistente te da un punto de partida razonable; ajústalo a cómo trabaja tu empresa.

1. Estados. Abre Categorías y estados de solicitud. En la pestaña Categoría de Estado está Soporte FINORA; en la pestaña Estado de Solicitud, sus seis estados. Al abrir un estado ves las casillas que cambian su comportamiento:
   • Predeterminado: el estado con que nace el ticket (Nuevo);
   • Estado Cerrado: el ticket cuenta como resuelto (Resuelto y Cerrado);
   • Cierre Final: ya no se puede reabrir (Cerrado);
   • Pausa el SLA: mientras el ticket está en este estado, el reloj de resolución se detiene (Esperando cliente).
2. Tipos de solicitud. En Tipos de solicitud confirma que los cuatro tipos tienen Soporte FINORA en Condición de Categoría y que solo uno está marcado Predeterminado (Consulta).
3. Supervisores. El escalamiento avisa al supervisor del responsable del ticket: es el campo Supervisor de la ficha de cada usuario (ventana Usuario). En el caso, el supervisor de Ana Torres es Gabriela Suárez. Los grupos de solicitud de iDempiere 13 no tienen supervisor propio.
4. Respuestas estándar. En Respuestas estándar (ventana Respuesta Estándar de Solicitud) revisa el Texto de Respuesta de las tres. Usa variables como @Name@ solo si ya las probaste: un texto con una variable mal escrita le llega así al cliente.

1

El estado Esperando cliente, abierto desde la categoría Soporte FINORA: la casilla Pausa el SLA detiene el reloj de resolución.

1. 1Pausa el SLA

✕

Parte 3. Horario hábil, feriados y políticas SLA

Un SLA (acuerdo de nivel de servicio) es la promesa de cuánto tardas en responder y en resolver. FINORA CRM lo mide en minutos hábiles: solo cuenta el tiempo dentro del horario de atención, sin almuerzo, fines de semana ni feriados.

3.1 El horario hábil

1. Abre Horario hábil y elige Lunes a viernes 8–17. Está marcado Predeterminado.
2. En la pestaña Franjas hay dos filas por Día, de lunes a viernes: Hora de inicio 08:00 y Hora de fin 12:00, y 13:00 a 17:00. La hora de almuerzo no cuenta porque no está en ninguna franja.
3. Si atiendes los sábados en la mañana, agrega una franja para el sábado de 08:00 a 12:00. Una franja tiene que terminar después de empezar: para cubrir hasta la medianoche, usa dos franjas.

Las franjas del horario predeterminado: la hora de almuerzo queda fuera.

✕

3.2 Los feriados

FINORA CRM no tiene un calendario de feriados propio: usa los días no laborables del calendario de la empresa, los mismos que usa el resto del sistema. Regístralos en Año Calendario y Período, pestaña Día no laboral, con los feriados nacionales del año (y los locales de tu organización, si los hay). Un feriado que falte ahí se cuenta como día hábil.

3.3 Las políticas SLA

Abre Políticas SLA. El asistente creó cuatro, todas con el horario Lunes a viernes 8–17:

Política	Prioridad	Primera respuesta	Resolución	Equivale a
SLA Urgente	Urgente	30 min	240 min	medio día hábil
SLA Alta	Alta	60 min	480 min	1 día hábil
SLA Media (predeterminada)	Media	240 min	1.440 min	3 días hábiles
SLA Baja	Baja	480 min	2.880 min	6 días hábiles

Cada política tiene además un porcentaje en riesgo (80 por defecto): cuando el ticket consumió ese porcentaje del plazo, pasa a En riesgo para que alguien actúe antes de incumplir.

Qué política le toca a un ticket. El sistema busca, en este orden, y se queda con la primera que encuentre:

1. la del mismo tipo de solicitud y la misma prioridad;
2. la del mismo tipo sin prioridad;
3. la de la misma prioridad sin tipo;
4. la marcada Predeterminada.

Si no hay ninguna, el ticket queda sin SLA. Las cuatro del asistente no tienen tipo, así que hoy aplican por prioridad a cualquier tipo. Si quieres que un Reclamo urgente se resuelva en 120 minutos, crea una política con tipo Reclamo y prioridad Urgente: gana por ser más específica.

Las cuatro políticas del asistente: minutos hábiles de primera respuesta y de resolución por prioridad.

✕

3.4 Cómo se calcula la fecha límite: un ejemplo

Supón un Incidente de prioridad Alta (60 minutos para la primera respuesta, 480 para la resolución) registrado el viernes 02/10/2026 a las 11:30. El reloj arranca en el momento de la creación.

Tramo	Minutos hábiles	Acumulado
Viernes 11:30–12:00	30	30
Viernes 12:00–13:00 (almuerzo)	0	30
Viernes 13:00–13:30	30	60 → vence la primera respuesta: viernes 13:30
Viernes 13:30–17:00	210	270
Sábado y domingo	0	270
Lunes 05/10 08:00–11:30	210	480 → vence la resolución: lunes 05/10 a las 11:30

El ticket pasa a En riesgo al consumir el 80 % del plazo pendiente: para la primera respuesta, a los 48 minutos (viernes 13:18); para la resolución, a los 384 minutos (lunes 09:54).

Con pausa. El viernes a las 14:00 el agente le pide al cliente una foto de la pantalla y pasa el ticket a Esperando cliente. El cliente responde el lunes a las 08:30 y el agente lo vuelve a En progreso. El tiempo pausado en minutos hábiles es viernes 14:00–17:00 (180) más lunes 08:00–08:30 (30) = 210 minutos. La fecha límite de resolución se corre esos 210 minutos hábiles: desde el lunes 11:30, 30 minutos hasta el almuerzo y 180 desde las 13:00. Nueva fecha límite: lunes 05/10 a las 16:00. La pausa no mueve la primera respuesta: esa ya se cumplió.

Con un feriado. Si el mismo ticket se hubiera abierto el viernes 09/10/2026 a las 11:30, el lunes 12/10 (Día de la Resistencia Indígena) no contaría, siempre que esté cargado como día no laborable. La resolución vencería el martes 13/10 a las 11:30.

Fuera de horario. Un ticket que entra de noche no consume minutos hasta que abre el horario: uno de prioridad Alta registrado a las 23:56 vence su primera respuesta a las 09:00 y su resolución a las 17:00 del día hábil siguiente. Es el caso del ticket de la parte 4.1.

Cambiar el tipo o la prioridad recalcula todo

Si cambias el tipo de solicitud o la prioridad de un ticket, las fechas límite se recalculan desde la creación, no desde el cambio. Subir un ticket de Media a Urgente tres horas después de abierto puede dejarlo incumplido al instante.

stateDiagram-v2
    direction LR
    [*] --> EnPlazo: ticket con política SLA
    [*] --> SinSLA: ninguna política aplica
    EnPlazo --> EnRiesgo: consumió el % en riesgo
    EnRiesgo --> Incumplido: pasó la fecha límite
    EnPlazo --> Cumplido: resuelto a tiempo
    EnRiesgo --> Cumplido: resuelto a tiempo
    Incumplido --> FueraDePlazo: resuelto tarde
    EnPlazo: En plazo
    EnRiesgo: En riesgo
    FueraDePlazo: Resuelto fuera de plazo
    SinSLA: Sin SLA

Parte 4. Registrar y atender un ticket

stateDiagram-v2
    direction LR
    [*] --> Nuevo
    Nuevo --> EnProgreso: el agente responde
    EnProgreso --> Esperando: falta un dato del cliente
    Esperando --> EnProgreso: el cliente responde
    EnProgreso --> Escalado: pasa a nivel 2
    Escalado --> EnProgreso
    EnProgreso --> Resuelto: solución aplicada
    Resuelto --> EnProgreso: el cliente reabre
    Resuelto --> Cerrado: cierre final
    Cerrado --> [*]
    EnProgreso: En progreso
    Esperando: Esperando cliente (pausa SLA)

4.1 Registrar un ticket que llega por teléfono

Carlos Rondón llama a última hora: quiere saber cómo se hace el cierre de caja cuando hubo pagos en divisas. Ana registra el ticket a mano.

1. Abre Mis solicitudes (ventana Solicitud) y pulsa Nuevo.
2. Llena la cabecera:
   • Tipo de Solicitud: Consulta;
   • Categoría: Facturación; Grupo: Soporte nivel 1;
   • Prioridad: Alta;
   • Resumen: Consulta sobre el cierre de caja del día, y en la línea siguiente el detalle;
   • Representante Comercial: Ana Torres, la responsable del ticket;
   • más abajo, Usuario: Carlos Rondón. Si el contacto pertenece a un tercero, llena también Tercero.
3. En el grupo SLA y satisfacción, elige el Canal: Teléfono.
4. Guarda. El ticket recibe su No. del Documento y el estado Nuevo. En SLA y satisfacción aparecen la Política SLA (SLA Alta), Vence primera respuesta, Vence resolución y el Estado SLA En plazo.

123

La cabecera del ticket: tipo, categoría, grupo, prioridad, resumen y responsable.

1. 1Tipo de Solicitud
2. 2Prioridad: junto con el tipo, define la política SLA
3. 3Representante Comercial: el responsable del ticket

✕

El ticket entró a las 23:56, fuera de horario: por eso la primera respuesta vence a las 09:00 y la resolución a las 17:00 del día hábil siguiente (parte 3.4).

1234

El grupo SLA y satisfacción del mismo ticket.

1. 1Canal por el que entró el ticket
2. 2Vence primera respuesta
3. 3Vence resolución
4. 4Estado SLA

✕

4.2 Primera respuesta con una respuesta estándar

1. En el ticket, elige una Respuesta Estandar, por ejemplo Acuse de recibo. Su texto se copia en Resultado; complétalo si hace falta.
2. Cambia el Estado a En progreso y guarda. El texto queda como una nueva línea en la pestaña Actualizaciones, con fecha, hora y autor.
3. En SLA y satisfacción, Primera respuesta tiene la hora en que guardaste. Ese valor no cambia nunca más, aunque luego edites el ticket.

Cuenta como primera respuesta lo que ocurra primero: una actualización escrita por alguien distinto del cliente, o un cambio de estado que saque al ticket de Nuevo. En la captura anterior el ticket todavía no la tiene: Primera respuesta está vacía.

4.3 Esperando al cliente

María Fernández pidió por WhatsApp un usuario para una cajera nueva. Para crearlo, Ana necesita su número de cédula.

1. Elige la respuesta estándar Solicitud de información, ajusta el texto y cambia el Estado a Esperando cliente. Guarda.
2. El reloj de resolución se detiene mientras el ticket siga en ese estado.
3. Cuando María responde, Ana registra la respuesta en Resultado y vuelve el estado a En progreso. Los minutos hábiles que estuvo en pausa se suman en Pausa SLA (min hábiles) y corren la fecha Vence resolución (el cálculo está en la parte 3.4). En este ticket ya van 960 minutos hábiles en pausa, y por eso sigue En plazo aunque se abrió hace días.

1

El ticket de María Fernández en Esperando cliente: su reloj de resolución está detenido.

1. 1Estado Esperando cliente

✕

Precaución

Usa Esperando cliente solo cuando el siguiente paso de verdad depende del cliente. Dejar un ticket ahí para “ganar tiempo” se nota en los indicadores (parte 10) y en la encuesta.

4.4 Resolver con un artículo de la base de conocimiento

José Pérez pidió por la web una copia de la factura 000123. La solución ya está documentada.

1. Abre Base de conocimiento y busca por las Palabras clave, por ejemplo reimprimir. Encuentras Cómo reimprimir una factura fiscal, categoría Facturación, con su Resumen, la Solución paso a paso y la casilla Publicado marcada.
2. Vuelve al ticket. En Resuelto con artículo elige ese artículo. El campo Usos del artículo sube en 1: así sabes qué soluciones se usan más.
3. Elige la respuesta estándar Cierre con solución y pega los pasos del artículo en Resultado.
4. Elige la Resolución Resuelto y cambia el Estado a Resuelto. Guarda.
5. En SLA y satisfacción, Resuelto el tiene la hora de cierre y el Estado SLA queda Cumplido (o Resuelto fuera de plazo, si se pasó). El ticket recibe además su Token de satisfacción (parte 6).

Si no hay artículo para el caso, créalo apenas lo resuelvas: Título con las palabras que usaría el cliente, Resumen de una línea, Solución reproducible, Palabras clave y Categoría. Márcalo Publicado cuando alguien más lo haya revisado.

El artículo que resolvió el ticket: Usos ya cuenta una vez.

✕

12

El ticket de José Pérez resuelto dentro del plazo, con el artículo que lo resolvió.

1. 1Resuelto con artículo
2. 2Estado SLA Cumplido

✕

Parte 5. Escalamiento y monitor SLA

Las fechas límite no avisan solas: lo hace el proceso Monitor de SLA, que recorre los tickets abiertos con SLA, recalcula su estado y envía avisos, los mensajes internos de iDempiere que cada usuario ve en la ventana Aviso y en el contador de la pantalla de inicio.

Cuando el ticket pasa a…	El monitor…
En riesgo	avisa al responsable del ticket (Representante Comercial)
Incumplido	sube el Nivel de escalamiento en 1 y avisa al responsable y a su supervisor (campo Supervisor de la ficha del responsable)

Cada cambio de estado se avisa una sola vez: aunque el monitor corra cada 15 minutos, nadie recibe el mismo aviso dos veces.

Ejemplo. Carlos Rondón reportó por el portal que la conciliación bancaria no le cuadra. El ticket, de prioridad Media, pasó su fecha límite sin resolverse: el monitor lo marcó Incumplido, subió su nivel de escalamiento a 1 y envió el aviso SLA del ticket incumplido: escalado a Ana Torres y a Gabriela Suárez.

12

Un ticket incumplido: el monitor subió su nivel de escalamiento y avisó a la responsable y a su supervisora.

1. 1Estado SLA Incumplido
2. 2Nivel de escalamiento

✕

1. Abre la ventana Agenda (pestaña Agendar Proceso) y busca FVE CRM Monitor de SLA. El asistente lo crea inactivo a propósito: activarlo es una decisión de la empresa.
2. Revisa el Proceso (Monitor de SLA) y la Programación (FVE CRM cada 15 minutos).
3. Marca Activo y guarda. Pide al administrador del servidor que lo arranque (botón Scheduler State).
4. Para probarlo sin esperar, ejecuta Monitor de SLA desde el menú CRM (FINORA) › Análisis (con el parámetro Organización vacío revisa todas): recalcula los tickets abiertos y envía los avisos que correspondan.

12

El programador del monitor, creado inactivo por el asistente.

1. 1Proceso Monitor de SLA
2. 2Programación cada 15 minutos

✕

Escalar a nivel 2 no es lo mismo que el nivel de escalamiento

El Nivel de escalamiento lo sube el monitor cuando se incumple el plazo; es una alerta. Pasar el ticket al grupo Soporte nivel 2 (con el estado Escalado) es una decisión del agente cuando el caso supera su alcance. Puedes hacer lo segundo mucho antes de que ocurra lo primero.

Parte 6. Encuesta de satisfacción

Cuando un ticket pasa a Resuelto, FINORA CRM le asigna un Token de satisfacción único. Ese código es lo que viaja en el enlace de la encuesta que tu canal le envía al cliente (por correo, por el portal o por WhatsApp): el cliente no necesita usuario en el ERP.

1. José abre el enlace y elige una puntuación de 1 a 5, con un comentario opcional: 5, “Rápido y claro, gracias.”
2. El canal registra la respuesta con el proceso Registrar satisfacción, que pide Token de satisfacción, Satisfacción (1-5) y Comentario. Desde el menú CRM (FINORA) › Mesa de ayuda también puedes registrarla a mano, por ejemplo si el cliente respondió por teléfono.
3. En el ticket ves Satisfacción (1-5), Fecha de la encuesta y Comentario de satisfacción, de solo lectura.
4. Cada ticket acepta una sola respuesta: un segundo intento devuelve un error. Si la puntuación es 2 o menos, el supervisor del responsable recibe un aviso para llamar al cliente.

12

La respuesta de José Pérez registrada en el ticket.

1. 1Satisfacción (1-5)
2. 2Comentario de satisfacción

✕

Así registra el canal la respuesta (la autenticación es la misma de la parte 7):

POST https://tu-servidor/api/v1/processes/fve_crm_recordcsat
Authorization: Bearer <token>
Content-Type: application/json

{
  "FVE_CSATToken": "<token de satisfacción del ticket>",
  "FVE_CSATScore": 5,
  "FVE_CSATComment": "Rápido y claro, gracias."
}

Parte 7. Entrada omnicanal: Crear ticket

Los tickets también llegan solos: el formulario web, el portal del cliente o un conector de WhatsApp llaman al proceso Crear ticket por la API REST. Lo configura el equipo técnico una vez; a ti te toca reconocer y atender lo que llega. El mismo proceso está en el menú CRM (FINORA) › Mesa de ayuda, con los campos Correo, Nombre, Teléfono, Asunto y detalle, Canal, Tipo de solicitud, Prioridad y Tercero.

Qué hace el proceso con cada mensaje:

1. Normaliza el correo (minúsculas, sin espacios) y lo valida; si no es válido, devuelve un error.
2. Busca un contacto activo con ese correo. Si lo encuentra (como a Carlos), el ticket queda a su nombre y con su tercero.
3. Si no lo encuentra, crea el contacto como cliente potencial, con el canal como Fuente Cliente Potencial (Correo Electrónico para el correo, Sitio Web para la web) y sin tercero. Así se crearon María Fernández y José Pérez.
4. Crea el ticket con el Canal indicado, el Tipo de solicitud pedido (o el predeterminado, Consulta) y la Prioridad pedida (o Media).
5. Si el mismo correo abrió un ticket con el mismo asunto (la primera línea) en los últimos 10 minutos, devuelve ese en vez de crear un duplicado: el cliente que pulsa Enviar dos veces.

Así llega una consulta desde el formulario web:

POST https://tu-servidor/api/v1/processes/fve_crm_createticket
Authorization: Bearer <token>
Content-Type: application/json

{
  "EMail": "Valeria.Rios@example.com ",
  "Name": "Valeria Ríos",
  "Phone": "+58 424 555 0202",
  "Summary": "Cotización para 3 cajas\nQuisiera una cotización del sistema de caja para tres puntos de venta.",
  "FVE_Channel": "WE",
  "Priority": "5"
}

→ 200 {"isError": false, "summary": "No. del Documento 1000010", "logs": [...]}

• EMail, Summary y FVE_Channel son obligatorios. El correo llega con mayúsculas y un espacio al final, y el proceso lo guarda como valeria.rios@example.com.
• FVE_Channel: EM correo, PH teléfono, WA WhatsApp, WE web, PO portal, WI presencial, OT otro.
• Priority usa los códigos de iDempiere: 1 Urgente, 3 Alta, 5 Media (por defecto), 7 Baja, 9 Menor.
• R_RequestType_ID (opcional) es el ID del tipo de solicitud; sin él se usa el predeterminado.
• El número del ticket va en summary después de No. del Documento (el texto cambia con el idioma de la sesión). Si es un duplicado, el mismo número viene seguido de El mismo ticket ya se abrió en los últimos 10 minutos; se devuelve el existente.
• El <token> se obtiene con el intercambio de dos pasos de La API REST de iDempiere, con un usuario de integración que solo tenga acceso a este proceso. Nunca pongas sus credenciales en el formulario web: la llamada la hace el servidor del formulario.

¿Y el correo?

Para que los correos entren solos sin programar nada, iDempiere trae un Procesador de solicitudes de EMail que se configura con un buzón (lo hace el administrador del sistema). No lo confundas con Procesador de solicitudes, del menú CRM (FINORA) › Configuración, que vigila los plazos y alertas nativos de iDempiere. Un conector propio de correo, el de WhatsApp y el portal del cliente están planificados para una fase siguiente de FINORA CRM; mientras tanto, cualquiera de ellos entra por Crear ticket.

Parte 8. Leads: puntaje, grado y conversión

Un lead es una persona interesada que todavía no es cliente. En iDempiere es un contacto marcado como Cliente Potencial, con su Fuente Cliente Potencial y su Estado Cliente Potencial. FINORA CRM le agrega un Puntaje del lead de 0 a 100 y un Grado del lead de A a D para que el equipo comercial sepa a quién llamar primero.

8.1 Las reglas de puntuación

Las reglas viven en Reglas de puntuación de leads. Cada una tiene un Criterio, un Valor cuando el criterio lo necesita y los Puntos que suma. Las del asistente:

Regla	Criterio	Valor	Puntos
Tiene correo	Tiene correo		10
Tiene teléfono	Tiene teléfono		10
Asociado a tercero	Asociado a tercero		15
Al menos un área de interés	Áreas de interés ≥ valor	1	10
Actividad en los últimos 30 días	Actividades en 30 días ≥ valor	1	15
Tiene oportunidad abierta	Tiene oportunidad abierta		25
Llegó por la web	Origen igual a	WS (Sitio Web)	15

El criterio Origen igual a compara el código de la fuente del lead, no su nombre: Sitio Web es WS. Hay un criterio más, para el cargo del contacto, que no viene configurado. El puntaje es la suma, con tope de 100. El grado sale del puntaje:

Grado	Puntaje	Lectura práctica
A	75 o más	Llámalo hoy
B	50 a 74	Esta semana
C	25 a 49	Nutrir con información
D	menos de 25	Sin datos suficientes

Las siete reglas del asistente.

✕

8.2 Puntuar

1. Ejecuta Puntuar leads desde CRM (FINORA) › Análisis. Sin parámetros recalcula todos los leads con las reglas activas; con el parámetro Lead, solo ese.
2. Abre Leads (clientes potenciales) y busca a Valeria Ríos. Su Puntaje del lead es 35 (correo 10 + teléfono 10 + llegó por la web 15) y su Grado del lead, C.
3. Compárala con Carlos Rondón: correo, teléfono, web, una actividad reciente y una oportunidad abierta suman 75, grado A.

123

El lead de Valeria Ríos: 35 puntos, grado C.

1. 1Fuente Cliente Potencial
2. 2Puntaje del lead
3. 3Grado del lead

✕

8.3 Convertir el lead en tercero

Después de una llamada, Valeria confirma que quiere una propuesta para su empresa.

1. En el lead, escribe el Nombre Tercero (la razón social de su empresa) y guarda.
2. Pulsa Proceso (el engranaje de la barra de herramientas) y elige Convierte Cliente Potencial. En el diálogo:
   • deja marcada Crea Oportunidad;
   • Fecha Esperada Cierre, Descripción y Monto Oportunidad;
   • Etapa Ventas (obligatoria): Prospecto;
   • Moneda y Representante Comercial.
3. Pulsa OK. El sistema crea el tercero, deja a Valeria como su contacto y crea la oportunidad.
4. Completa en Tercero los datos fiscales (RIF, condición IVA) antes de facturarle: la conversión no los conoce.
5. Vuelve a ejecutar Puntuar leads: ahora suma también Asociado a tercero (15) y Tiene oportunidad abierta (25). Puntaje 75, grado A.

El diálogo de conversión. Etapa Ventas es el único campo obligatorio.

✕

Parte 9. Oportunidades y embudo

9.1 Las etapas y su probabilidad

Cada etapa de venta tiene una Probabilidad: qué porcentaje de las oportunidades en esa etapa terminan, en promedio, en venta.

flowchart LR
    P["Prospecto<br/>10 %"] --> C["Calificado<br/>25 %"] --> PR["Propuesta<br/>50 %"] --> N["Negociación<br/>75 %"]
    N --> G["Ganada<br/>100 %"]
    N --> L["Perdida<br/>0 %"]
    PR --> L
    C --> L

Los porcentajes del asistente son un punto de partida. Después de seis meses de datos, compáralos con lo que de verdad cerró tu equipo y ajústalos en Etapas de venta. Las casillas Estado Cerrado y Ganada marcan las etapas finales: Ganada tiene las dos, Perdida solo la primera.

Las seis etapas del asistente con su probabilidad.

✕

9.2 Mover la oportunidad

1. Abre Oportunidades de venta (ventana Oportunidad de Ventas) y elige la de Panadería Ejemplo, C.A.: implantación de nómina, Monto Oportunidad 4.800,00 USD.
2. Cuando envías la propuesta, cambia la Etapa Ventas a Propuesta. La Probabilidad pasa a 50 y el Monto Ponderado a 2.400,00.
3. Revisa Fecha Esperada Cierre y Representante Comercial, y anota en Comentarios qué se envió y cuándo.
4. Cuando se decida, muévela a Ganada o Perdida: una oportunidad olvidada en Negociación infla la previsión.

123

Una oportunidad en Propuesta: el monto ponderado es el 50 % del monto.

1. 1Etapa Ventas
2. 2Probabilidad de la etapa
3. 3Monto Ponderado = monto × probabilidad ÷ 100

✕

9.3 La vista de embudo y la previsión ponderada

Embudo de ventas es una ventana de solo lectura que agrupa las oportunidades abiertas por Etapa de venta, Comercial, Mes de cierre y Moneda, con la cantidad de Oportunidades, el Monto y el Monto ponderado (monto × probabilidad de la etapa ÷ 100).

Las oportunidades abiertas de Ana Torres:

Oportunidad	Etapa	Probabilidad	Cierre	Monto (USD)	Ponderado (USD)
Distribuidora Rondón — migración completa	Negociación	75 %	octubre	12.000,00	9.000,00
Panadería Ejemplo — implantación de nómina	Propuesta	50 %	octubre	4.800,00	2.400,00
Distribuidora Rondón — licencias adicionales	Prospecto	10 %	noviembre	1.500,00	150,00
Total				18.300,00	11.550,00

El total bruto (18.300,00) dice cuánto hay en juego; el ponderado (11.550,00) es la previsión realista. Para octubre, la previsión es 11.400,00 de 16.800,00 en juego. Fíjate en que la oportunidad de 1.500,00 en Prospecto aporta apenas 150,00: por eso se ordena el trabajo por etapa, no solo por monto.

El embudo de Ana Torres por etapa y mes de cierre.

✕

Parte 10. Indicadores de soporte

Indicadores de soporte resume los tickets por Tipo de solicitud y Estado:

Columna	Qué responde
Tickets	¿Cuántos tickets hay en esa combinación?
Abiertos	¿Cuánto trabajo pendiente hay?
Vencidos	¿Cuántos ya pasaron su fecha límite? Empieza por aquí cada mañana
Cumplimiento SLA %	De los tickets resueltos con SLA, ¿qué porcentaje se resolvió dentro de plazo?
Resolución promedio (h)	¿Cuántas horas tardamos en resolver, en promedio?
Satisfacción promedio	¿Qué tan satisfechos quedan los clientes, de 1 a 5?

Una lectura útil: un tipo con cumplimiento alto y satisfacción baja indica que se cierra rápido pero mal (revisa las soluciones y la base de conocimiento); cumplimiento bajo y satisfacción alta indica que el plazo de esa política es poco realista para ese tipo de caso.

Como todas las vistas de FINORA CRM, respeta tu rol: solo ves los tickets de las organizaciones a las que tienes acceso.

Los indicadores de la mesa de ayuda de ejemplo: un ticket vencido para atender primero.

✕

Parte 11. Actividades y recordatorios

Cada llamada, reunión o tarea con un cliente o un lead se registra como actividad. FINORA CRM le recuerda al comercial las que empiezan hoy o ya empezaron sin completarse.

1. Abre el lead en Leads (clientes potenciales) (o el contacto en Contactos y actividades) y ve a la pestaña Actividad. Pulsa Nuevo.
2. Elige el Tipo Actividad (Llamada Telefónica, Correo Electrónico…), escribe la Descripción, la Fecha Inicio (con hora) y el Representante Comercial. Si la actividad es parte de una venta, elige la Oportunidad de Ventas. Guarda.
3. Cada día hábil, el proceso Recordatorio de actividades deja un aviso al representante comercial por cada actividad sin completar que empieza ese día o antes, una vez al día por actividad.
4. Después de la llamada, marca Completo y anota el resultado en Comentarios. La actividad también suma en el puntaje del lead (Actividad en los últimos 30 días).

En la captura, Carlos Rondón tiene dos actividades pendientes a cargo de Ana Torres: la llamada de hoy para presentar la propuesta y un correo con la propuesta revisada que debió salir hace dos días. Ana recibió un aviso por cada una.

Las actividades pendientes de Carlos Rondón.

✕

El recordatorio se programa en Agenda como el monitor SLA (parte 5): el asistente crea FVE CRM Recordatorio de actividades, de lunes a viernes a las 07:30, inactivo.

Video pendiente

Tutorial completo: tickets con SLA hasta la encuesta de satisfacción, y del lead al embudo de ventas (12 minutos)

Si te equivocaste

Situación	Qué hacer
Elegiste mal el tipo o la prioridad del ticket	Corrígelos. Las fechas límite se recalculan desde la creación; revisa el estado SLA después de guardar
Olvidaste pasar el ticket a Esperando cliente	La pausa no es retroactiva. Deja una actualización explicando la espera para que la supervisora la tenga en cuenta
Marcaste Resuelto por error	Vuelve el estado a En progreso: Resuelto el se borra y el SLA sigue corriendo
Entró un ticket duplicado por la API después de los 10 minutos	Ciérralo con la resolución Duplicado y menciona el ticket original en Resultado
El cliente intentó responder la encuesta dos veces	Solo vale la primera respuesta; el segundo intento se rechaza por diseño
Convertiste el lead equivocado	No borres nada que ya tenga documentos. Inactiva el tercero y la oportunidad creados y avisa al administrador
Una oportunidad quedó en una etapa equivocada	Cámbiala: el embudo se recalcula al consultarlo

Resumen

1. Ejecuta Configurar empresa (primero en ensayo) y ajusta estados, supervisores y respuestas estándar.
2. Carga los feriados en el calendario y revisa el horario hábil y las políticas SLA.
3. Registra cada ticket con tipo, prioridad, canal y responsable; responde con respuestas estándar y usa Esperando cliente solo cuando corresponde.
4. Resuelve enlazando el artículo de la base de conocimiento; el token de la encuesta se genera solo.
5. Activa el monitor SLA a conciencia: escala y avisa una sola vez por cambio de estado.
6. Los canales externos crean tickets y leads con Crear ticket.
7. Puntúa los leads, convierte los calificados y mueve las oportunidades por etapa; lee el embudo por su monto ponderado.
8. Revisa cada mañana los vencidos en los indicadores de soporte y tus avisos de actividades.

Fuentes

• Especificación funcional de FINORA CRM: finora-lve/specs/crm/README.md (alcance, reglas de SLA, escalamiento, API, satisfacción, puntuación de leads y vistas; catálogo semilla).
• Decisión de arquitectura: finora-lve/decisions/ADR.md, ADR-LVE-015 (FINORA CRM complementa el CRM nativo).
• Playbook REST: finora-lve/docs/playbooks/lve-20-crm.md (configuración, códigos de canal y prioridad, formato de respuesta de Crear ticket, menú y campos en español).
• Proceso de configuración por tenant: finora-lve/docs/playbooks/lve-01-tenant-setup.md (ensayo e idempotencia).
• Autenticación y llamada a procesos por REST: La API REST de iDempiere.
• Código fuente de iDempiere (solicitudes, clientes potenciales, oportunidades y actividades): idempiere/idempiere en GitHub.
• Capturas: scripts/capturas/crm.mjs, contra una instalación de prueba con datos ficticios (2026-10-01).