Este artículo es el complemento práctico: cómo usar IA para revisar el lote de pagos antes de que salga el dinero, sin frenar a cuentas por pagar ni convertir cada viernes en una auditoría.

El problema: el lote de pagos se revisa con prisa

En la mayoría de las empresas, el lote semanal de pagos se arma en el ERP, se exporta al portal bancario y alguien lo autoriza con una revisión rápida. Esa persona ve totales, no patrones. Así se cuelan tres tipos de error que se repiten en casi cualquier operación:

• Pagos duplicados: la misma factura capturada dos veces con una variación mínima (folio con guion, fecha distinta, importe redondeado) o pagada una vez por transferencia y otra por anticipo.
• Cambios de cuenta fraudulentos: un correo que parece del proveedor solicita cambiar la cuenta destino. Es una de las formas de fraude más comunes contra áreas de finanzas y funciona porque el cambio se hace por correo y sin una segunda verificación.
• Importes fuera de patrón: pagos muy por encima del histórico del proveedor, facturas sin recepción registrada o montos que no corresponden a la orden de compra.

Ninguno de estos casos es difícil de detectar si alguien tiene tiempo de mirar cada línea con contexto. El punto es que nadie lo tiene. Ahí es donde un modelo que revise el lote completo y señale solo lo raro aporta valor.

Cómo funciona una revisión de pagos con IA

La idea no es que la IA autorice pagos. Es que el lote llegue al autorizador con las líneas sospechosas ya marcadas y explicadas. El flujo típico tiene cuatro piezas.

1. Detección de duplicados «casi iguales»

Las reglas exactas del ERP solo detectan duplicados idénticos. Un modelo de coincidencia aproximada compara cada línea del lote contra los pagos de los últimos 12 a 18 meses usando varias señales a la vez: UUID del CFDI, RFC emisor, folio normalizado, importe con tolerancia, fecha y concepto. Si dos registros comparten el mismo UUID, es duplicado seguro. Si comparten proveedor, importe casi igual y folios parecidos, se marca para revisión con el pago anterior a la vista.

2. Control de cambios en datos bancarios

Toda cuenta destino que cambió en los últimos 30 a 60 días se marca, sin excepción. La IA añade contexto: quién hizo el cambio en el maestro, si el banco nuevo es distinto del habitual, si la solicitud llegó por correo desde un dominio diferente al registrado y si es el primer pago a esa CLABE. La regla operativa que acompaña al modelo es simple: ningún primer pago a una cuenta nueva sale sin una llamada de confirmación al contacto registrado en el alta, nunca al teléfono que viene en el correo de la solicitud.

3. Anomalías de importe y de flujo

Con el histórico de cada proveedor se calcula un rango esperado de pago. Una factura que supera ese rango, que no tiene entrada de almacén o recepción de servicio, o cuyo importe difiere de la orden de compra más allá de la tolerancia pactada, aparece en la lista con la razón concreta. También se señalan patrones menos obvios: varias facturas justo debajo del límite de autorización, pagos a proveedores sin actividad reciente o anticipos que nunca se amortizaron.

4. Un resumen legible para quien autoriza

El resultado no es un puntaje opaco. Es una lista corta, normalmente entre el 2 % y el 5 % de las líneas, donde cada alerta dice qué se detectó, con qué evidencia y qué se sugiere hacer: retener, confirmar con el proveedor o liberar. El autorizador decide y su decisión queda registrada, lo que además alimenta el modelo para reducir falsos positivos con el tiempo.

Controles que no se negocian

• Separación de funciones: quien modifica datos bancarios en el maestro de proveedores no debe ser quien arma ni quien autoriza el lote.
• Retención, no cancelación: la IA puede sugerir retener una línea; liberar o cancelar siempre es decisión humana y queda en bitácora.
• Datos personales: los datos de contacto y bancarios de proveedores persona física están sujetos a la Ley Federal de Protección de Datos Personales en Posesión de los Particulares. Limita el acceso, define para qué se usan y no los envíes a herramientas sin un acuerdo de tratamiento claro.
• Trazabilidad: cada alerta, decisión y confirmación telefónica debe poder consultarse en una auditoría interna o externa.

Qué medir

• Monto retenido y recuperado: pagos duplicados o indebidos detenidos antes de salir.
• Tasa de alertas útiles: porcentaje de alertas que terminan en una corrección real. Si es muy baja, el modelo está generando ruido y el equipo dejará de leerlo.
• Tiempo de autorización del lote: debe mantenerse o bajar; si la revisión agrega horas, el diseño está mal.
• Cambios bancarios confirmados: porcentaje de primeros pagos a cuenta nueva con confirmación documentada. La meta es 100 %.

Un piloto de cuatro semanas

Semana 1. Extrae 12 a 18 meses de pagos, el maestro de proveedores con su historial de cambios y los CFDI recibidos. Corre la detección en retrospectiva: casi todas las empresas encuentran algún duplicado ya pagado que vale la pena reclamar.

Semana 2. Ajusta tolerancias con el equipo de cuentas por pagar y define la regla de confirmación de cambios bancarios por escrito.

Semana 3. Corre la revisión en paralelo sobre los lotes reales, sin bloquear nada. Compara las alertas con lo que el autorizador habría detectado solo.

Semana 4. Activa la retención sugerida en el flujo de autorización y mide tiempo, alertas útiles y monto detenido.

Del alta al pago, un mismo control

Validar bien al proveedor el primer día reduce el riesgo; revisar cada lote antes de dispersar lo mantiene bajo control todas las semanas. Juntos convierten a cuentas por pagar en un punto de control, no en un trámite. En NextWave ayudamos a empresas en México a diseñar e implementar estos flujos sobre su ERP y su banca actual, con reglas claras y revisión humana donde importa. Si quieres revisar tu proceso de pagos, platiquemos.

La entrada Pagos duplicados y cambios de cuenta sospechosos: cómo revisar con IA el lote de pagos antes de dispersar se publicó primero en Next Wave.

La IA no sustituye el criterio de compras ni de cumplimiento, pero sí puede hacer el trabajo pesado: leer documentos, cruzar datos, consultar fuentes y dejar a las personas solo los casos que de verdad requieren decisión. En este artículo explicamos cómo diseñar un flujo de alta y validación de proveedores con IA que proteja la deducibilidad de tus gastos y no frene a las áreas que necesitan comprar.

Por qué el alta de proveedores es un riesgo fiscal y operativo, no un trámite

El alta es el único momento en que tu empresa tiene control total antes de que exista una relación de pago. Después, cada factura recibida, cada transferencia y cada deducción dependen de que ese registro inicial esté bien. Los riesgos más comunes que vemos en empresas B2B en México son:

• Proveedores en el listado del artículo 69-B del CFF. Si un proveedor es señalado de forma definitiva por emitir comprobantes de operaciones inexistentes, los CFDI que recibiste de él pueden perder efectos fiscales, y te toca demostrar la materialidad de la operación.
• Opinión de cumplimiento negativa. Para ciertos contratos, como los celebrados con el sector público, o simplemente como política interna, la opinión de cumplimiento (artículo 32-D) es un filtro básico que muchas áreas revisan una sola vez y nunca actualizan.
• Datos bancarios no verificados. Una CLABE capturada con error o cambiada por correo es la puerta de entrada más común al fraude de pago a proveedores.
• Servicios especializados sin registro REPSE. Si contratas servicios u obras especializadas, el proveedor debe contar con registro vigente; sin él, se complica la deducción y se abre una contingencia laboral.
• Maestro duplicado o sucio. El mismo proveedor dado de alta tres veces con razones sociales ligeramente distintas rompe cualquier análisis de gasto y facilita pagos duplicados.

Ninguno de estos riesgos es nuevo. Lo que cambia con la IA es que puedes revisarlos todos, en cada alta, sin agregar personal.

El flujo de alta con IA en cinco etapas

Un diseño práctico separa lo que la máquina valida de lo que una persona decide. Estas son las etapas que recomendamos:

1. Captura guiada en lugar de correos

El proveedor recibe un enlace a un formulario o portal donde sube su constancia de situación fiscal, opinión de cumplimiento, comprobante de domicilio, carátula del estado de cuenta y, si aplica, su registro REPSE. La IA lee cada documento al momento y le avisa al proveedor si algo está incompleto, ilegible o vencido, antes de que el expediente llegue a tu equipo.

2. Extracción y cruce de datos

El modelo extrae RFC, razón social, régimen fiscal, código postal fiscal, actividades económicas, banco y CLABE. Después cruza: ¿la razón social de la constancia coincide con la de la carátula bancaria? ¿El código postal coincide con el que usará para facturar CFDI 4.0? ¿La actividad económica registrada es congruente con lo que te va a vender? Una empresa registrada como comercializadora de papelería que pretende facturarte servicios de ingeniería merece una segunda mirada.

3. Consulta de listas y fuentes

El flujo consulta el RFC contra los listados públicos del SAT (artículo 69-B en sus distintas etapas y los listados del artículo 69, como no localizados o con créditos firmes), valida la estructura de la CLABE y, cuando aplica, verifica el registro REPSE. Cada consulta queda registrada con fecha y resultado: esa evidencia es la que te pedirá un auditor.

4. Puntaje de riesgo y ruta de aprobación

Con todo lo anterior, la IA asigna un nivel de riesgo y explica por qué. Un proveedor sin alertas, con documentos vigentes y datos congruentes pasa por la ruta rápida: aprobación del comprador y alta automática en el ERP. Uno con discrepancias va a la cola de cumplimiento con un resumen de qué no cuadra. Uno que aparece en un listado definitivo se bloquea y se notifica al responsable.

5. Alta en el ERP y monitoreo continuo

El registro aprobado se crea en el ERP sin recaptura, con una validación final contra duplicados por RFC y CLABE. Y aquí está la diferencia con el proceso tradicional: la validación no termina en el alta. El flujo vuelve a consultar las listas de manera periódica y antes de cada corrida de pagos, para detectar proveedores que cambian de estatus después de haber sido aprobados.

Dónde decide la IA y dónde decide una persona

La regla que proponemos es sencilla: la IA verifica, compara y resume; las personas aprueban excepciones y asumen el riesgo. En la práctica:

• Automático: lectura de documentos, verificación de vigencia, cruce de datos, consulta de listas, detección de duplicados y cálculo del nivel de riesgo.
• Con revisión humana: discrepancias entre documentos, actividad económica poco congruente con lo que se va a comprar, proveedores de nueva creación con montos altos y cualquier cambio de cuenta bancaria.
• Siempre bloqueado hasta decisión formal: RFC en listado definitivo del 69-B, opinión de cumplimiento negativa cuando la política la exige, o datos bancarios a nombre de un tercero.

Un punto que conviene dejar explícito: los cambios de CLABE nunca deben aprobarse solo por correo, aunque la IA confirme que el formato es válido. El flujo debe exigir una confirmación por un canal independiente, como una llamada al contacto registrado, y dejar evidencia de quién la hizo.

Controles de gobierno y privacidad que no puedes omitir

Un expediente de proveedor contiene datos fiscales, bancarios y, en el caso de personas físicas, datos personales protegidos por la LFPDPPP. Antes de automatizar, define:

• Aviso de privacidad para proveedores que explique qué datos recabas, para qué y con quién los compartes, incluido el proveedor de la herramienta de IA.
• Retención y acceso: quién puede ver la carátula bancaria y por cuánto tiempo se conserva cada documento.
• Bitácora de decisiones: cada aprobación, rechazo o excepción debe quedar ligada a una persona, una fecha y la evidencia que tuvo a la vista.
• Explicabilidad del puntaje: si el sistema marca a un proveedor como de alto riesgo, el revisor debe ver las razones concretas, no solo un número.
• Revisión de falsos positivos: homonimias de razón social o errores de lectura pueden bloquear a proveedores legítimos; mide cuántas alertas resultan infundadas y ajusta las reglas.

KPIs para saber si el flujo funciona

Antes del piloto, mide tu línea base. Después, compara con estos indicadores:

• Tiempo de alta: días desde la solicitud del comprador hasta que el proveedor puede recibir una orden de compra.
• Porcentaje de altas por ruta rápida: cuántas solicitudes se aprueban sin intervención de cumplimiento.
• Expedientes completos al primer envío: indicador directo de qué tan bien guía el portal al proveedor.
• Proveedores con alerta detectada después del alta: cambios de estatus capturados por el monitoreo continuo antes de un pago.
• Duplicados evitados y cambios bancarios verificados por canal independiente.
• Tasa de falsos positivos en las alertas de riesgo.

Piloto de 4 semanas para empezar sin riesgo

Semana 1. Diagnóstico. Revisa las altas de los últimos meses: cuánto tardaron, qué documentos faltaban con más frecuencia y cuántos proveedores activos tienen datos incompletos. Define la política de riesgo con compras, tesorería, fiscal y cumplimiento.

Semana 2. Configuración. Arma el portal de captura, las reglas de cruce y las consultas a listas. Corre el flujo en paralelo sobre altas reales, sin que todavía decida nada.

Semana 3. Operación supervisada. Activa la ruta rápida para una categoría de gasto de bajo riesgo y revisa manualmente cada caso que la IA mandó a excepción. Aprovecha para correr la validación sobre tu maestro actual: es común descubrir proveedores activos con alertas que nadie había revisado.

Semana 4. Medición y decisión. Compara tiempos y alertas contra la línea base, ajusta umbrales y decide si amplías el alcance a todas las categorías y al monitoreo previo a cada corrida de pagos.

Conclusión: un proveedor bien dado de alta es un pago que no vas a tener que defender

La validación de proveedores rara vez aparece en la lista de proyectos de IA más vistosos, pero es de los que protegen directamente la deducibilidad de tu gasto y el efectivo de tu tesorería. Automatizar la lectura, el cruce y el monitoreo libera a tu equipo para lo que sí requiere criterio: decidir qué riesgos acepta la empresa y documentar por qué.

En NextWave AI diseñamos e implementamos flujos de alta y validación de proveedores conectados a tu ERP, con reglas de riesgo, bitácora auditable y revisión humana donde importa. Si quieres revisar tu proceso actual y estimar el impacto de un piloto, escríbenos a contacto@nextWaveAI.AI o llámanos al +52 (33) 3126 6969.

La entrada Alta de proveedores con IA: cómo validar RFC, lista 69-B y datos bancarios antes del primer pago se publicó primero en Next Wave.

Este artículo explica cómo plantear una planeación de plantilla por turno con IA en un CEDIS o almacén: qué datos se necesitan, cómo se traduce el volumen en horas-persona, cómo se toma la decisión diaria y cómo medir si funciona.

El problema real: el volumen llega en olas, la plantilla se fija en bloques

La demanda de trabajo en un almacén no es plana. Cambia por día de la semana, por quincena, por campañas como El Buen Fin, por cortes de transportista y por el ritmo de llegada de proveedores. Sin embargo, la plantilla suele fijarse en bloques rígidos: tantos operadores en el primer turno, tantos en el segundo, y un número de eventuales que se pide con un día de anticipación.

La brecha entre esas dos curvas es donde se pierde dinero. Se nota en tres síntomas que casi cualquier gerente de operaciones reconoce:

• Picos sin cubrir: el surtido se acumula antes del corte de paquetería y se pagan horas extra o se pierden ventanas de embarque.
• Valles con gente ociosa: en horas o días flojos, la productividad por persona cae sin que nadie lo decida conscientemente.
• Mala distribución entre áreas: sobra gente en recibo y falta en empaque, o al revés, porque la asignación se hace por costumbre.

Qué decide el modelo y qué sigue decidiendo el supervisor

Conviene dejar claro desde el inicio el alcance. La IA produce una recomendación de horas-persona por área y franja horaria, con un rango de confianza. El supervisor y el jefe de operaciones deciden la plantilla final, los eventuales que se solicitan y la reasignación entre áreas durante el turno.

Esta separación no es un detalle de forma. En México, cualquier ajuste de jornada, turno o tiempo extra tiene implicaciones laborales (Ley Federal del Trabajo, contrato colectivo si existe, reglas de subcontratación especializada para el personal de agencia). El modelo no debe programar personas individuales ni modificar jornadas; su trabajo es dimensionar la carga para que la decisión humana sea mejor informada.

Paso 1: pronosticar la carga, no solo los pedidos

El primer error común es pronosticar «pedidos por día» y dividir entre un promedio. Un pedido de una línea no pesa lo mismo que uno de cuarenta líneas con producto voluminoso. Lo útil es pronosticar unidades de trabajo por proceso:

• Recibo: tarimas o cajas esperadas según citas de proveedor y órdenes de compra abiertas.
• Acomodo: ubicaciones a llenar derivadas del recibo.
• Surtido: líneas y piezas por pedido, separadas por tipo (pieza suelta, caja completa, tarima).
• Empaque y embarque: bultos, guías y cortes por transportista.
• Devoluciones e inventario cíclico: carga recurrente que suele olvidarse en la planeación.

Para esto, el modelo combina el histórico del WMS y del ERP (pedidos, líneas, recibos, horarios de liberación de olas), el calendario comercial (quincenas, promociones, temporadas), la cartera de pedidos ya capturada y las citas de proveedores confirmadas. A corto plazo, lo que ya está en el sistema pesa más que el histórico; a una o dos semanas, el histórico y el calendario explican la mayor parte.

Paso 2: traducir carga a horas-persona con estándares reales

Una vez que sabes cuántas líneas, cajas o tarimas vienen, necesitas saber cuánto tarda tu operación en procesarlas. Aquí la IA aporta mucho si tienes registros de productividad del WMS o de escáneres: puede estimar el tiempo por unidad según zona, tipo de producto, hora del día y experiencia del operador, en lugar de usar un estándar fijo que nadie ha actualizado en años.

Un ejemplo ilustrativo de la lógica (cifras de ejemplo, no de un cliente real): si para el martes se esperan 6,000 líneas de surtido en pieza suelta, y el estándar observado en esa zona es de 90 líneas por hora-persona, la carga es de unas 67 horas-persona. Con turnos efectivos de 7 horas productivas, eso implica cerca de 10 personas en surtido, más un margen según la incertidumbre del pronóstico. El valor no está en la división, sino en hacerla bien por proceso, por franja horaria y con estándares que reflejen la realidad.

Paso 3: distribuir por franja horaria y respetar los cortes

Saber que necesitas 10 personas en el día no basta. El trabajo tiene horarios duros: la recolección de paquetería a las 17:00, la salida de la ruta foránea a las 20:00, los proveedores que llegan entre 7:00 y 11:00. El modelo debe repartir la carga por franja (por ejemplo, bloques de una o dos horas) considerando cuándo se libera cada ola y cuándo debe estar lista.

El resultado es una curva de necesidad por área y por hora. Al ponerla junto a la plantilla programada aparecen los huecos y excesos con anticipación, y eso habilita decisiones como adelantar la entrada de un grupo, mover dos personas de recibo a empaque después de las 13:00 o pedir eventuales solo para la segunda mitad del turno.

Paso 4: la junta diaria de plantilla

La herramienta funciona cuando se integra a una rutina corta. Una práctica que da buenos resultados es una revisión de 15 minutos al cierre del turno anterior o temprano por la mañana, con tres preguntas:

1. ¿Cuál es la carga esperada mañana por área y franja, y qué tan confiable es? El modelo muestra el rango, no solo un número.
2. ¿Dónde hay brecha contra la plantilla programada? Se señalan las franjas con déficit o exceso por encima de un umbral acordado.
3. ¿Qué palanca movemos? Reasignar entre áreas, solicitar eventuales, adelantar o recorrer olas, negociar una cita de proveedor o, como último recurso, tiempo extra autorizado.

Cada decisión queda registrada junto con la recomendación. Así, al cierre de semana se puede revisar cuándo el equipo siguió la sugerencia, cuándo no y qué pasó en cada caso. Ese registro es lo que permite mejorar el modelo y, sobre todo, ganar la confianza de los supervisores.

Datos mínimos y controles

No necesitas un proyecto de datos de un año para empezar. Lo mínimo suele ser:

• Historial de pedidos y líneas con hora de liberación y de embarque (12 a 24 meses idealmente).
• Registros de productividad por proceso, aunque sean agregados por turno.
• Plantilla programada y real por día (incluyendo eventuales).
• Calendario de promociones, quincenas y cortes de transportista.

En controles, vale la pena definir desde el inicio que los datos de productividad se usan para dimensionar la operación y no para evaluar o sancionar a personas de forma automatizada. Si se manejan datos personales de operadores, aplica la LFPDPPP: aviso de privacidad, finalidad clara y acceso restringido. Explicarlo abiertamente al equipo evita resistencia y lecturas equivocadas del proyecto.

Cómo medir si funciona

Los indicadores deben conectar con costo y servicio, no con la precisión del modelo por sí sola:

• Horas extra como porcentaje de horas totales.
• Productividad por proceso (líneas, cajas o tarimas por hora-persona).
• Cumplimiento de cortes y pedidos embarcados a tiempo.
• Costo laboral por unidad (por línea surtida o por pedido embarcado).
• Error de pronóstico de carga por área, para saber dónde confiar más o menos en la recomendación.
• Tasa de adopción: cuántas recomendaciones se siguieron y con qué resultado.

Un piloto de 6 semanas

Para validar el valor sin comprometer la operación, proponemos un piloto acotado:

• Semanas 1 y 2: extracción de datos del WMS/ERP, línea base de indicadores y estándares de productividad por proceso en un solo CEDIS.
• Semana 3: modelo de carga por área y franja en modo sombra; se compara la recomendación contra lo que realmente pasó, sin cambiar decisiones.
• Semanas 4 a 6: junta diaria de plantilla con la recomendación en uso para una o dos áreas (típicamente surtido y empaque), registro de decisiones y revisión semanal de resultados.

Al final del piloto, la decisión de escalar se toma con datos: cuánto bajó el tiempo extra, cuánto mejoró el cumplimiento de cortes y qué tan confiable resultó el pronóstico en cada área.

Del «más o menos» a una decisión diaria con datos

La planeación de plantilla es una de las decisiones que más se repiten en un CEDIS y una de las que más impacto tienen en costo y servicio. Pasar de la intuición a una recomendación por área y por hora, revisada por el supervisor en una junta corta, es un cambio práctico que se puede probar en semanas.

En NextWave AI ayudamos a operaciones logísticas y de distribución en México a diseñar e implementar este tipo de decisiones asistidas por IA, integradas con su WMS y ERP actuales. Si quieres revisar si tu operación es candidata para un piloto, escríbenos a contacto@nextWaveAI.AI o llámanos al +52 (33) 3126 6969.

La entrada Plantilla por turno con IA en CEDIS: cuántas personas necesitas por área y por hora sin pagar horas extra de más se publicó primero en Next Wave.

Este artículo es el complemento práctico del pronóstico de liquidez: cómo usar IA para decidir a qué cliente contactar hoy, por qué canal y con qué mensaje, de forma que cada hora del equipo de cobranza mueva más efectivo.

Por qué ordenar por antigüedad no basta

Ordenar la cartera por días vencidos parece lógico, pero mezcla situaciones muy distintas. Una factura de 90 días de un cliente en disputa no se resuelve con un recordatorio, y una de 5 días de un cliente que siempre paga a tiempo probablemente llegue sola. Mientras tanto, el saldo grande de un cliente que empezó a retrasarse hace dos meses, y que todavía está «en verde», se queda sin atención hasta que ya es tarde.

La pregunta útil no es «quién debe más tiempo», sino «dónde cambia más el resultado si intervengo hoy».

Qué hace la IA en la cobranza

El enfoque que mejor funciona combina tres piezas sencillas, todas construidas sobre tus propios datos de cuentas por cobrar:

• Probabilidad de pago por factura. Un modelo aprende del historial de cada cliente: días promedio de pago, tendencia reciente, montos, condiciones de crédito, complementos de pago (REP) emitidos, temporada y si hubo notas de crédito o disputas. El resultado es, para cada factura, la probabilidad de cobrarla en los próximos 7, 15 y 30 días.
• Impacto de intervenir. No todas las facturas responden igual a un contacto. El sistema estima cuánto sube la probabilidad de pago si se llama, se escribe o se escala, usando la respuesta histórica a gestiones anteriores.
• Prioridad diaria. Monto por probabilidad por impacto da un valor esperado de cada gestión. La lista del día se ordena por ese valor, no por antigüedad, y se cruza con las semanas donde el pronóstico de 13 semanas muestra un hueco.

Segmentar antes de escribir

Con la prioridad calculada, la cartera se divide en grupos con un tratamiento distinto:

• Pagadores puntuales: recordatorio automático amable antes del vencimiento, sin intervención humana.
• Retraso administrativo: clientes que pagan, pero tarde por procesos internos (orden de compra, recepción, portal de proveedores). Aquí la acción es resolver el trámite: enviar el XML y PDF correctos, confirmar la recepción o dar de alta la factura en el portal.
• Deterioro reciente: clientes que cambiaron su patrón de pago. Requieren llamada de un ejecutivo y, si aplica, aviso al área comercial antes de seguir surtiendo.
• Disputa: facturas con reclamo abierto, faltantes o diferencias de precio. No se cobran; se resuelven primero con operaciones o ventas.

Esta segmentación evita el error más caro de la cobranza: presionar a un buen cliente por una factura que en realidad está atorada en tu propio proceso.

Mensajes sugeridos, decisiones humanas

Un modelo de lenguaje puede redactar el borrador de cada gestión con el contexto correcto: facturas incluidas, folios fiscales, saldo, último contacto y la siguiente acción acordada. El ejecutivo revisa, ajusta el tono y envía. Algunas reglas que conviene fijar desde el inicio:

• El sistema nunca promete descuentos, quitas ni nuevos plazos; esas decisiones tienen un dueño y un límite de autorización.
• Cada mensaje cita las facturas y montos reales del sistema; nada se redacta «de memoria».
• Los datos de contacto y el historial se manejan conforme a la LFPDPPP y a tu aviso de privacidad.
• Las promesas de pago que obtiene el ejecutivo se registran con fecha y monto, y alimentan de vuelta el pronóstico de flujo.

Cómo se conecta con el pronóstico de 13 semanas

La integración es lo que convierte esto en una herramienta de tesorería y no solo de cobranza. Cada semana, la junta de liquidez revisa los huecos proyectados; la lista priorizada muestra cuánto efectivo esperado se puede adelantar en esas semanas y con qué clientes. Las promesas de pago confirmadas actualizan el pronóstico con su propia probabilidad, y las que no se cumplen bajan la confianza del cliente en el modelo. Así, finanzas deja de suponer que «la cobranza va a salir» y empieza a ver de qué facturas depende.

KPIs para saber si funciona

• Días de venta pendientes de cobro (DSO) y su tendencia mensual.
• Porcentaje de cartera vencida a más de 30 y 60 días.
• Efectivo cobrado por hora de gestión del equipo.
• Cumplimiento de promesas de pago.
• Tiempo promedio para resolver facturas en disputa.

Un piloto de cuatro semanas

Semana 1: extraer el historial de facturas, pagos, REP y gestiones de los últimos 18 a 24 meses, y medir la línea base de DSO y cartera vencida.

Semana 2: entrenar la probabilidad de pago, definir segmentos y validar con el equipo de cobranza que la lista priorizada «tiene sentido» con lo que ellos conocen de cada cliente.

Semanas 3 y 4: trabajar con la lista y los borradores sugeridos en una parte de la cartera, comparar contra el método actual y conectar las promesas de pago al pronóstico de flujo.

Conclusión

El pronóstico a 13 semanas te avisa del hueco; la cobranza priorizada con IA es la forma más directa de cerrarlo sin pedir crédito ni sacrificar relaciones con clientes. Con probabilidades por factura, segmentos claros y mensajes revisados por personas, el equipo dedica su tiempo a las gestiones que realmente mueven efectivo.

En NextWave diseñamos e implementamos cobranza priorizada con IA conectada a tu ERP y a tu pronóstico de flujo, empezando con un piloto acotado y medible. Escríbenos a contacto@nextWaveAI.AI o llámanos al +52 (33) 3126 6969 y platiquemos cómo se vería en tu operación.

La entrada Cobranza priorizada con IA: cómo decidir a qué cliente contactar hoy para adelantar efectivo sin desgastar la relación se publicó primero en Next Wave.

El pronóstico de flujo de efectivo a 13 semanas es la herramienta clásica para resolver esto. Lo que cambia con la IA no es el concepto, sino la forma de alimentarlo: en lugar de supuestos genéricos («los clientes pagan a 45 días»), el modelo aprende cómo paga cada cliente, cuándo se liberan realmente los pagos a proveedores y qué tan estacional es la nómina variable. Este artículo explica cómo construirlo paso a paso, qué datos necesitas y cómo usarlo para decidir, no solo para reportar.

Por qué 13 semanas y por qué ahora

Trece semanas equivalen a un trimestre: es un horizonte lo bastante corto para pronosticar con detalle semanal y lo bastante largo para anticipar un hueco de liquidez con tiempo de actuar (negociar plazos, adelantar cobranza, disponer de una línea de crédito en mejores condiciones). En un entorno de tasas altas, con clientes que estiran plazos y proveedores que los acortan, cada semana de anticipación tiene un valor financiero concreto.

El problema del pronóstico tradicional es que se construye «de arriba hacia abajo» con promedios. La IA permite construirlo «de abajo hacia arriba»: factura por factura, orden de compra por orden de compra, con una probabilidad de fecha de cobro o pago para cada partida.

Los datos que necesitas (y que probablemente ya tienes)

No hace falta un proyecto de datos de un año. La mayoría de las fuentes ya existen en el ERP y el banco:

• Cuentas por cobrar abiertas: facturas emitidas con fecha, monto, cliente, condiciones de crédito y moneda.
• Historial de cobranza: al menos 12 a 24 meses de fechas reales de pago por factura, idealmente con los complementos de pago (REP) ligados.
• Cuentas por pagar y órdenes de compra: facturas de proveedores recibidas, OC comprometidas y calendario de pagos acordado.
• Movimientos bancarios: estados de cuenta de todas las cuentas, en pesos y dólares.
• Pipeline de ventas y plan de producción: para estimar facturación futura que todavía no existe.
• Partidas recurrentes: nómina, IMSS e Infonavit, impuestos (ISR, IVA), rentas, servicio de deuda.

La calidad de estos datos importa más que el algoritmo. Si los pagos de clientes no se aplican a la factura correcta, el modelo aprenderá patrones falsos. Por eso conviene empezar revisando la conciliación de cobranza antes de pronosticar.

Cómo funciona el modelo, partida por partida

Cobranza: cuándo va a pagar realmente cada cliente

En lugar de asumir que una factura a 30 días se cobra el día 30, el modelo estima una distribución de días de pago para cada factura usando variables como el historial del cliente, el monto, el mes del año, si la factura tiene evidencia de entrega completa y si hay disputas abiertas. El resultado no es una fecha, sino una probabilidad por semana: por ejemplo, 20% en la semana 4, 55% en la semana 5 y 25% en la semana 6.

Pagos a proveedores: lo comprometido frente a lo negociable

Los pagos se separan en tres grupos: obligatorios (impuestos, nómina, deuda), comprometidos (proveedores críticos con fechas fijas) y flexibles (proveedores con los que existe margen para negociar). Esta clasificación es clave para la etapa de decisión.

Facturación futura: del pipeline al efectivo

Para las semanas 6 a 13, buena parte del cobro proviene de ventas que aún no se facturan. El modelo combina el pipeline ponderado por probabilidad de cierre con el ciclo histórico de pedido a factura y de factura a cobro.

Rango, no punto

Cada semana del pronóstico se presenta con un escenario base y una banda (por ejemplo, percentiles 10 y 90). Un saldo mínimo esperado de 8 millones con una banda inferior de 2 millones exige acciones distintas a un saldo de 8 millones con banda inferior de 6.

De pronóstico a decisión: la junta semanal de liquidez

Un pronóstico que nadie usa es un reporte más. El valor aparece cuando se integra en una rutina semanal de 30 minutos con finanzas, cobranza y compras. Una agenda que funciona:

1. Precisión de la semana pasada: cuánto se desvió el cobro y el pago real frente a lo pronosticado, y por qué.
2. Semanas en riesgo: el sistema marca las semanas donde la banda inferior cae por debajo del saldo mínimo de operación.
3. Palancas sugeridas: para cada hueco, el sistema propone acciones con su efecto estimado: priorizar cobranza de los diez clientes con mayor saldo y probabilidad de pago tardío, recorrer pagos flexibles, adelantar factoraje sobre facturas específicas o disponer de la línea revolvente.
4. Decisión y dueño: cada acción queda asignada a una persona con fecha. La IA propone; tesorería decide.

Este es el punto donde el pronóstico se convierte en decision intelligence: no solo dice qué va a pasar, sino qué conviene hacer y cuánto vale cada opción.

Escenarios que vale la pena modelar

• Cliente principal se retrasa: ¿qué pasa si el cliente que representa el 18% de la cartera paga tres semanas tarde?
• Tipo de cambio: impacto de un movimiento de un peso por dólar en pagos de importación y cobros en dólares.
• Compra anticipada de inventario: efecto de adelantar una compra grande para asegurar precio.
• Cambio en condiciones de crédito: pasar a un grupo de clientes de 60 a 45 días, o aceptar 90 días con un cliente nuevo.

Cada escenario debe poder correrse en minutos, no en días. Ese es uno de los beneficios más visibles frente a la hoja de cálculo manual.

Controles y gobierno

El flujo de efectivo es información sensible. Antes de escalar conviene definir:

• Accesos por rol: quién ve saldos bancarios, quién ve el detalle por cliente y quién solo ve el agregado.
• Trazabilidad: cada cifra del pronóstico debe poder rastrearse a la factura, OC o supuesto que la origina.
• Supuestos editables y registrados: cuando tesorería ajusta manualmente una partida, el ajuste queda documentado con motivo y autor.
• Revisión de desempeño del modelo: si la precisión cae por debajo de un umbral acordado durante dos semanas seguidas, se revisa antes de seguir usándolo para decisiones.

KPIs para saber si está funcionando

• Error de pronóstico por semana (en pesos y como porcentaje), con meta para las semanas 1 a 4 y otra para las semanas 5 a 13.
• Semanas de anticipación con que se detectó cada hueco de liquidez.
• Costo financiero evitado: intereses de líneas dispuestas de emergencia o recargos por pagos tardíos.
• Días de cartera (DSO) y días de proveedores (DPO) antes y después.
• Horas de tesorería dedicadas a armar el pronóstico frente a horas dedicadas a analizarlo.

Piloto de 6 semanas

1. Semanas 1 y 2: conexión a ERP y bancos, limpieza de la aplicación de pagos y construcción del modelo de cobranza con el historial.
2. Semana 3: pronóstico en paralelo con la hoja actual, sin cambiar decisiones.
3. Semanas 4 y 5: comparación de precisión, ajuste de supuestos y primera junta semanal de liquidez con palancas sugeridas.
4. Semana 6: evaluación con finanzas: precisión lograda, decisiones tomadas con el pronóstico y decisión de escalar a todas las unidades de negocio.

Un buen criterio de éxito para el piloto: que el pronóstico a cuatro semanas sea consistentemente más preciso que el método actual y que al menos una decisión de liquidez se haya tomado con base en él.

Conclusión

El pronóstico de flujo de efectivo a 13 semanas con IA no sustituye el criterio del director de finanzas; le da tiempo. Pasar de promedios a probabilidades por factura, presentar rangos en lugar de un solo número y conectar cada hueco con palancas concretas convierte a tesorería de un área que reacciona en una que anticipa.

¿Quieres saber qué tan preciso podría ser tu pronóstico con los datos que ya tienes? En NextWave te ayudamos a diagnosticar tus fuentes, construir el modelo y diseñar la rutina semanal de liquidez. Escríbenos a contacto@nextWaveAI.AI o llámanos al +52 (33) 3126 6969.

La entrada Pronóstico de flujo de efectivo a 13 semanas con IA: cómo anticipar huecos de liquidez y decidir qué palanca mover se publicó primero en Next Wave.

Este artículo es el complemento práctico del plan mensual: cómo usar IA y optimización para convertir ese plan en una secuencia semanal y diaria por línea, con reglas claras, sin quitarle al supervisor la última palabra.

Por qué el plan mensual no basta en el piso

Un plan mensual trabaja con familias de producto y capacidad agregada. El piso trabaja con órdenes, SKU, moldes, herramentales, turnos y personas. Entre ambos hay decisiones que el plan no resuelve:

• Secuencia: el orden de las órdenes define cuántos cambios de formato hay y cuánto tiempo productivo se pierde en limpiezas, ajustes y arranques.
• Restricciones reales: un herramental compartido entre dos líneas, un operador certificado que solo trabaja el primer turno o un curado que no puede interrumpirse.
• Disponibilidad de material: una orden puede ser prioritaria en el plan, pero si la materia prima llega el jueves no sirve programarla el martes.
• Imprevistos: paros, ausencias, pedidos urgentes y rechazos de calidad que obligan a reprogramar a media semana.

Cuando todo esto se resuelve de memoria, el resultado depende de quién esté de turno y casi nunca se puede explicar después por qué se eligió una secuencia y no otra.

Qué hace la IA y qué hace el optimizador

Conviene separar dos piezas que a veces se venden como una sola:

• Modelos de aprendizaje automático para estimar lo que hoy se supone: tiempos reales de ciclo por SKU y línea, duración probable de cada cambio de formato según el producto anterior y el siguiente, y probabilidad de que un proveedor entregue a tiempo, todo a partir del historial del ERP y del MES o de los registros de producción.
• Un motor de optimización o heurísticas de secuenciación que usa esas estimaciones y las restricciones duras para proponer la secuencia: minimizar tiempo de cambios y atrasos contra fecha compromiso, respetando capacidad, turnos y material disponible.
• Un asistente en lenguaje natural opcional, para que el supervisor pregunte «¿qué pasa si la línea 2 para cuatro horas?» y reciba la secuencia alternativa con el impacto explicado.

La IA no decide sola: propone, muestra el porqué y deja que el responsable acepte, ajuste o rechace.

Los datos mínimos para empezar

No hace falta un proyecto de transformación completo. Para un primer piloto basta con:

• Órdenes de producción abiertas con SKU, cantidad, fecha compromiso y prioridad comercial.
• Rutas y líneas posibles por SKU, con tiempo estándar de ciclo.
• Historial de seis a doce meses de producción real: inicio, fin, paros y cambios de formato registrados.
• Calendario de turnos, mantenimiento planeado y disponibilidad de herramentales.
• Existencias y fechas de llegada esperadas de los materiales críticos.

Si los cambios de formato no se registran hoy, ese es el primer ajuste: sin ese dato, el ahorro más grande queda invisible.

Reglas duras y reglas blandas

Una buena programación distingue entre lo que nunca se puede violar y lo que se puede negociar. Las reglas duras incluyen capacidad por turno, material disponible, herramentales compartidos, certificaciones de personal y secuencias obligatorias por inocuidad o alérgenos. Las reglas blandas tienen un costo: atrasar una orden contra su fecha compromiso, agregar un cambio de formato o mover a un operador de línea. El optimizador debe respetar las duras siempre y equilibrar las blandas según pesos que acuerden producción, ventas y calidad, no según la intuición del día.

Reprogramar sin caos

El valor aparece cuando algo falla. En lugar de rehacer la hoja, el sistema recalcula la secuencia desde el estado actual y muestra al supervisor dos o tres alternativas con su impacto: órdenes que se atrasan, cambios de formato adicionales y horas extra estimadas. Para evitar que la planta viva en cambio constante, conviene fijar una ventana congelada, por ejemplo las siguientes ocho o doce horas, que solo se modifica con aprobación explícita.

Controles que no deben faltar

• Aprobación humana: la secuencia se publica a la planta solo cuando el responsable la acepta, y queda registrado quién aprobó y qué cambió.
• Explicación: cada propuesta indica qué restricción la limita y por qué se eligió ese orden.
• Retroalimentación: los tiempos reales vuelven al modelo para que las estimaciones mejoren cada semana.
• Integración controlada: lectura del ERP y escritura de la secuencia aprobada solo en los campos acordados, con bitácora de cada actualización.

KPIs para saber si funciona

• Cumplimiento del programa: porcentaje de órdenes terminadas en el turno o día programado.
• Entregas a tiempo contra fecha compromiso.
• Horas perdidas en cambios de formato por semana.
• Número de reprogramaciones fuera de la ventana congelada.
• Tiempo que el planeador dedica a armar y ajustar el programa.

Un piloto de seis semanas

Semanas 1 y 2: elegir una o dos líneas con muchos cambios de formato, limpiar el historial de producción y medir la línea base.

Semanas 3 y 4: entrenar las estimaciones de ciclo y cambio, configurar reglas duras y blandas, y generar secuencias en paralelo al método actual, sin publicarlas.

Semanas 5 y 6: publicar las secuencias aprobadas por el supervisor, activar la reprogramación con ventana congelada y comparar KPIs contra la línea base.

Conclusión

El S&OP alinea a la empresa en qué producir; la programación con IA asegura que la planta lo produzca en el orden que menos tiempo y margen desperdicia. Con estimaciones aprendidas del historial, reglas explícitas y la aprobación del supervisor, una planta mediana puede reducir cambios de formato, cumplir más fechas y dejar de depender de una sola hoja de cálculo.

En NextWave diseñamos e implementamos programación de producción asistida por IA conectada a tu ERP y registros de planta, empezando con un piloto acotado y medible. Escríbenos a contacto@nextWaveAI.AI o llámanos al +52 (33) 3126 6969 y platiquemos cómo se vería en tu operación.

La entrada Programación de producción con IA: cómo convertir el plan mensual en una secuencia semanal por línea sin perder horas en cambios de formato se publicó primero en Next Wave.

La planeación de ventas y operaciones (S&OP, por sus siglas en inglés) existe precisamente para resolver esto: una junta mensual en la que dirección, comercial, operaciones y finanzas acuerdan un solo plan. El problema es que, en la práctica, la junta se vuelve una revisión de reportes atrasados y discusiones sobre qué número es el correcto. Aquí es donde la IA aporta valor real: no decidiendo por el comité, sino preparando escenarios comparables y señalando, antes de la junta, dónde están los conflictos que hay que resolver.

Por qué el S&OP tradicional se queda en una junta de reportes

Cuando revisamos procesos de S&OP en empresas medianas, los síntomas se repiten:

• Datos que llegan tarde: el cierre de ventas, el inventario y la capacidad se consolidan a mano, y la junta se hace con información de hace dos o tres semanas.
• Un solo escenario: se presenta “el plan” y nadie sabe qué pasa si el cliente principal adelanta su pedido o si un proveedor se retrasa diez días.
• Conflictos invisibles: el plan de ventas excede la capacidad de una línea específica, pero eso solo se descubre cuando planta intenta programarlo.
• Decisiones sin costo explícito: se decide “priorizar al cliente A” sin cuantificar cuánto margen, inventario o servicio se sacrifica en otros clientes.
• Acuerdos sin seguimiento: las decisiones quedan en una minuta y el siguiente mes nadie compara lo acordado contra lo ejecutado.

Ninguno de estos problemas se resuelve con más reuniones. Se resuelve con un proceso que llegue a la junta con el trabajo analítico ya hecho.

Qué hace la IA en un ciclo de S&OP (y qué no)

Conviene separar el trabajo en tres capas, porque cada una necesita un tipo de herramienta distinto:

1. Consolidar y validar datos: extraer del ERP pedidos abiertos, histórico de ventas, inventario, órdenes de compra y capacidad por línea; detectar huecos, duplicados y valores fuera de rango antes de que contaminen el plan.
2. Pronosticar y simular: generar un pronóstico de demanda por familia de producto con su rango de incertidumbre y simular escenarios: demanda base, demanda alta, retraso de proveedor, paro de una línea.
3. Señalar conflictos y proponer opciones: identificar dónde el plan no cabe (capacidad, material, flujo de efectivo) y presentar dos o tres alternativas con su impacto en servicio, margen e inventario.

Lo que la IA no debe hacer es elegir el escenario final. Priorizar clientes, aceptar un riesgo de inventario o autorizar horas extra son decisiones de negocio con dueños claros. El valor está en que esas personas decidan con opciones cuantificadas en lugar de intuiciones contrapuestas.

Los datos mínimos para empezar

No necesitas un data lake para arrancar. Para un primer ciclo bastan estas fuentes, normalmente disponibles en el ERP o en archivos que ya existen:

• Histórico de ventas de 24 a 36 meses por SKU o familia, cliente y mes.
• Pedidos abiertos y cotizaciones con alta probabilidad de cierre.
• Inventario actual por almacén, con antigüedad.
• Capacidad disponible por línea o centro de trabajo, y tiempos estándar por familia.
• Lista de materiales (BOM) de los productos principales y tiempos de entrega de proveedores críticos.
• Costos estándar y margen por familia, para poder traducir cada escenario a dinero.

Si el maestro de productos o la lista de materiales tienen errores, el primer ciclo lo va a evidenciar. Eso no es un fracaso del proyecto: es uno de sus primeros entregables. Es mejor descubrirlo en un tablero que en una promesa incumplida a un cliente.

Cómo se ve un ciclo mensual con IA

Un diseño práctico mantiene el calendario clásico de S&OP, pero cambia lo que ocurre en cada etapa:

• Semana 1, revisión de demanda: el modelo propone el pronóstico por familia con su rango; comercial lo ajusta con información que el sistema no ve (un cliente que va a cambiar de proveedor, una licitación) y cada ajuste queda registrado con su justificación.
• Semana 2, revisión de suministro: el sistema cruza el plan de demanda contra capacidad, inventario y material, y genera una lista de conflictos ordenada por impacto económico: “la línea 3 está al 118% en diciembre”, “faltan 40 toneladas de resina para el escenario alto”.
• Semana 3, preparación de escenarios: para cada conflicto relevante se calculan dos o tres opciones (adelantar producción, tercerizar, priorizar clientes, aceptar un menor nivel de servicio) con su efecto en margen, inventario, flujo y servicio.
• Semana 4, junta ejecutiva: la dirección revisa solo los conflictos que requieren decisión, elige una opción por conflicto y asigna dueño y fecha. El resto del plan se aprueba por excepción.

Con este formato, una junta de tres horas puede convertirse en una de 60 a 90 minutos enfocada en decisiones, no en conciliar cifras.

Escenarios que vale la pena simular desde el primer mes

No todos los escenarios aportan lo mismo. En empresas industriales y distribuidoras en México, estos suelen ser los más útiles:

• Concentración de clientes: ¿qué pasa si los tres clientes principales adelantan o recortan sus pedidos un 20%?
• Riesgo de proveedor: retraso de un insumo importado, con el tiempo adicional de aduana y transporte.
• Temporada: picos de fin de año, regreso a clases o temporada agrícola, según el sector.
• Tipo de cambio: impacto en el costo de material importado y en el margen de los contratos en pesos.
• Capacidad: mantenimiento mayor programado, paro de una línea o incorporación de un turno adicional.

Cada escenario debe expresarse en las mismas cuatro métricas para que sean comparables: nivel de servicio esperado, margen bruto, inventario al cierre del periodo y necesidad de capital de trabajo.

Controles y gobierno: quién decide y cómo se audita

Un S&OP apoyado en IA necesita reglas claras para que el comité confíe en los números:

• Dueño por número: comercial es dueño del plan de demanda, operaciones del plan de suministro y finanzas de la traducción a dinero. El modelo propone; cada dueño firma.
• Ajustes trazables: todo cambio manual al pronóstico se registra con autor, motivo y magnitud, para medir después si los ajustes mejoraron o empeoraron la precisión.
• Supuestos visibles: cada escenario muestra sus supuestos (tiempos de entrega, tipo de cambio, rendimientos) para que nadie discuta resultados sin discutir premisas.
• Versionado del plan: el plan aprobado se congela cada mes y se compara contra la ejecución real en el siguiente ciclo.
• Datos sensibles acotados: márgenes por cliente y condiciones comerciales se muestran solo a quienes deben verlos, con permisos por rol.

KPIs para saber si está funcionando

Mide el antes y el después con indicadores que la dirección ya entiende:

• Precisión del pronóstico por familia (por ejemplo, error porcentual absoluto ponderado) y el valor agregado de los ajustes manuales.
• Nivel de servicio: porcentaje de pedidos entregados completos y a tiempo.
• Días de inventario y porcentaje de inventario sin movimiento en 90 días.
• Costos de urgencia: horas extra no planeadas y fletes expeditados como porcentaje de la venta.
• Cumplimiento del plan: producción real contra plan aprobado por línea.
• Tiempo de preparación: horas-persona invertidas en armar la junta.

Piloto de 8 semanas: cómo empezar sin rediseñar toda la empresa

Recomendamos un piloto acotado a una o dos familias de producto que concentren buena parte de la venta y tengan conflictos de capacidad conocidos:

1. Semanas 1–2: extracción y limpieza de datos, línea base de KPIs y acuerdo de dueños por número.
2. Semanas 3–4: pronóstico con rango de incertidumbre, cruce contra capacidad y material, primera lista de conflictos.
3. Semanas 5–6: construcción de tres escenarios con impacto en servicio, margen, inventario y capital de trabajo; primera junta con el nuevo formato.
4. Semanas 7–8: segundo ciclo, comparación de plan contra ejecución y decisión de escalar a más familias.

El criterio de éxito no es que el modelo “acierte”, sino que la junta tome decisiones más rápido, con costos visibles, y que los costos de urgencia y el inventario sin movimiento empiecen a bajar.

Errores comunes que conviene evitar

• Empezar por el software antes que por los dueños y el calendario del proceso.
• Pronosticar a nivel SKU desde el primer mes, cuando las decisiones se toman por familia.
• Presentar un solo número sin rango; la incertidumbre es información, no un defecto.
• No traducir los escenarios a dinero, lo que deja a finanzas fuera de la conversación.
• Dejar que el modelo “decida” prioridades de clientes sin aprobación comercial.

Conclusión

El S&OP es, en esencia, un proceso de decisión. La IA lo vuelve útil cuando consolida datos a tiempo, simula escenarios comparables y pone sobre la mesa los conflictos con su costo, para que dirección, comercial, operaciones y finanzas decidan sobre un mismo plan. Para una empresa mexicana de manufactura o distribución, eso se traduce en menos urgencias, menos inventario muerto y promesas a clientes que sí se pueden cumplir.

En NextWave diseñamos e implementamos procesos de planeación apoyados en IA, conectados a tu ERP y a los archivos que hoy ya usa tu equipo, empezando con un piloto medible. Escríbenos a contacto@nextWaveAI.AI o llámanos al +52 (33) 3126 6969 y platiquemos cómo se vería en tu operación.

La entrada S&OP con IA: cómo alinear ventas, producción y compras en un solo plan mensual con escenarios se publicó primero en Next Wave.

En este artículo vemos un desglose práctico: cómo usar IA para convertir tickets resueltos en una base de conocimiento viva y en respuestas sugeridas que el agente revisa y envía, sin que el sistema invente políticas, precios o plazos.

El problema: el mismo caso se resuelve desde cero una y otra vez

Cuando no hay una base de conocimiento mantenida, pasan tres cosas:

• Tiempos de respuesta inconsistentes: el agente con experiencia contesta en cinco minutos; el nuevo tarda una hora en el mismo caso.
• Respuestas contradictorias: dos clientes con el mismo problema reciben instrucciones distintas, y eso erosiona la confianza.
• Dependencia de personas clave: cuando alguien se va de vacaciones o deja la empresa, se va con él la mitad del conocimiento operativo.

Las bases de conocimiento tradicionales tampoco resuelven esto por sí solas: alguien tiene que escribir los artículos, y casi nunca hay tiempo. La IA cambia la ecuación porque puede hacer el primer borrador a partir de lo que el equipo ya resolvió.

Paso 1: minar los tickets resueltos

El punto de partida es el historial de tickets cerrados con buena calificación o sin reapertura. Un modelo de lenguaje puede agruparlos por tema (por ejemplo, «error al timbrar CFDI desde el portal», «solicitud de constancia de garantía», «cambio de dirección de entrega») y, para cada grupo, extraer:

• El síntoma o pregunta típica del cliente, con sus variantes de redacción.
• La causa más frecuente y cómo se diagnosticó.
• Los pasos de solución que funcionaron.
• Las excepciones: cuándo la solución estándar no aplica y hay que escalar.

Con eso, el sistema genera un borrador de artículo por tema. La clave es que cada afirmación del borrador cite los tickets de donde salió, para que el responsable pueda verificarla rápido.

Paso 2: un dueño humano por artículo

Ningún artículo se publica sin revisión. Asigna un dueño por familia de temas (producto, facturación, logística, garantías) que apruebe, corrija o descarte los borradores. Esto toma minutos por artículo en lugar de horas, porque el trabajo pesado de redacción ya está hecho. Además, el dueño marca qué datos son sensibles a cambio: precios, plazos, políticas comerciales o condiciones contractuales. Esos campos no se escriben en el texto; se leen en tiempo real del ERP, el CRM o el documento de política vigente.

Paso 3: respuestas sugeridas con fuentes, no respuestas automáticas

Cuando entra un ticket nuevo, el sistema busca los artículos aprobados más relevantes (lo que técnicamente se llama recuperación aumentada, o RAG) y propone una respuesta al agente con tres elementos:

1. El borrador de respuesta en el tono de la empresa, con los datos del cliente ya integrados (número de pedido, producto, fecha).
2. Las fuentes usadas: qué artículos y qué datos del sistema sustentan cada parte.
3. Un nivel de confianza y una alerta cuando no encontró información suficiente.

Si no hay un artículo aprobado que cubra el caso, la regla es simple: el sistema no inventa. Lo indica, sugiere a quién consultar y, cuando el caso se resuelve, lo marca como candidato a nuevo artículo. Así la base crece justo donde había huecos.

Paso 4: cerrar el ciclo con la retroalimentación del agente

Cada vez que un agente edita mucho una sugerencia o la descarta, eso es información valiosa. Registra el motivo en una lista corta (dato desactualizado, artículo incompleto, tono inadecuado, caso distinto) y revísalo cada semana con los dueños de artículos. Los artículos con más correcciones se reescriben primero; los que nadie consulta en tres meses se archivan.

Controles que no deben faltar

• Datos personales: al minar tickets, enmascara nombres, teléfonos, correos y RFC de personas físicas antes de generar artículos, en línea con la LFPDPPP. Los artículos describen casos, no clientes.
• Versiones y vigencia: cada artículo tiene fecha de revisión y caduca si no se valida en un periodo definido.
• Bitácora: guarda qué sugerencia se mostró, qué fuentes usó y qué envió finalmente el agente, para auditoría y para resolver quejas.
• Límites claros: descuentos, notas de crédito o compromisos de entrega fuera de política siempre requieren aprobación humana, aunque la sugerencia los mencione.

Cómo medir si funciona

• Tiempo promedio de primera respuesta y de resolución, antes y después.
• Tasa de aceptación de sugerencias (enviadas sin cambios o con cambios menores).
• Reapertura de tickets y calificación del cliente en casos atendidos con sugerencia.
• Tiempo de rampa de agentes nuevos hasta alcanzar el promedio del equipo.
• Cobertura: porcentaje de tickets entrantes con al menos un artículo aprobado relevante.

Un piloto realista de cuatro semanas

Semana 1: exportar seis a doce meses de tickets cerrados, enmascarar datos personales y elegir dos o tres familias de temas de alto volumen.

Semana 2: generar borradores de artículos con citas y que los dueños los aprueben o corrijan.

Semana 3: activar respuestas sugeridas para un grupo reducido de agentes, sin envío automático, y registrar ediciones y descartes.

Semana 4: comparar KPIs contra la línea base, ajustar artículos con más correcciones y decidir si se extiende a más temas y canales.

Conclusión

El triage pone el ticket en las manos correctas; una base de conocimiento viva le da a esas manos la respuesta correcta. Con IA para redactar a partir de lo que el equipo ya resolvió, dueños humanos que validan y reglas que impiden inventar, una empresa B2B puede responder más rápido, de forma consistente y sin depender de unas cuantas personas clave.

En NextWave diseñamos e implementamos bases de conocimiento y respuestas sugeridas conectadas a tu mesa de ayuda, ERP y CRM, empezando con un piloto acotado y medible. Escríbenos a contacto@nextWaveAI.AI o llámanos al +52 (33) 3126 6969 y platiquemos cómo se vería en tu operación.

La entrada Base de conocimiento de soporte con IA: cómo convertir tickets resueltos en respuestas sugeridas sin inventar políticas se publicó primero en Next Wave.

La IA no resuelve esto contestando sola todos los mensajes. Lo resuelve en un paso anterior y mucho más rentable: entender qué está pidiendo el cliente, qué tan urgente es y a quién le toca, en segundos y de forma consistente. En este artículo explicamos cómo diseñar ese triage para una empresa de manufactura, distribución o servicios en México, qué datos necesita, qué controles poner y cómo medirlo en un piloto de seis semanas.

Por qué el triage manual se rompe cuando creces

Al principio, una persona lee todo y reparte. Funciona hasta que el volumen sube o esa persona se va de vacaciones. Los síntomas típicos son:

• Clasificación inconsistente: el mismo tipo de problema se registra como “queja”, “garantía” u “otro” según quién lo capture, y los reportes dejan de servir.
• Prioridad por volumen de voz: se atiende primero al cliente que más insiste, no al que tiene más en juego.
• Rebotes entre áreas: una duda de facturación llega a logística, un problema de calidad llega a ventas, y cada rebote suma horas.
• Contexto perdido: quien atiende tiene que buscar el pedido, la factura y el historial del cliente en tres sistemas antes de poder responder.
• SLA invisible: nadie sabe cuántos casos están por vencer hasta que el cliente reclama.

Todo esto es un problema de flujo de trabajo, no de buena voluntad. Y es justo el tipo de problema donde la automatización con IA da retorno rápido.

Qué hace exactamente un triage con IA

Un buen diseño separa cuatro decisiones que hoy se toman mezcladas:

1. Intención: ¿qué pide el cliente? Por ejemplo: estatus de pedido, aclaración de factura, solicitud de complemento de pago, reporte de falla, devolución, cotización nueva, cambio de datos fiscales o queja de servicio.
2. Entidades: ¿de qué está hablando? Número de pedido, folio de factura, SKU, lote, sucursal, fecha comprometida. El modelo las extrae del texto, de adjuntos o de fotos.
3. Urgencia e impacto: ¿qué tan grave es? No es lo mismo “¿me reenvían la factura?” que “tenemos la línea detenida por falta de material”.
4. Ruta: ¿quién debe atenderlo y con qué SLA? Mesa de servicio, crédito y cobranza, logística, calidad, ejecutivo de cuenta o un flujo automático.

El modelo de lenguaje es muy bueno en las dos primeras. Las dos últimas deben combinar lo que dice el mensaje con datos duros del negocio: quién es el cliente, cuánto factura, qué contrato tiene, si hay pedidos en tránsito o facturas vencidas. Ahí es donde la mayoría de los proyectos se quedan cortos.

Los datos que necesitas antes de empezar

No hace falta un proyecto de datos de un año. Para un primer triage útil basta con:

• Historial de tickets o correos de los últimos 6 a 12 meses, aunque esté mal clasificado. Sirve para descubrir las intenciones reales y armar un catálogo de 10 a 20 categorías.
• Maestro de clientes con segmento, ejecutivo asignado, nivel de servicio contratado y, si existe, una marca de cuenta estratégica.
• Consulta al ERP por pedido y factura: estatus, fecha promesa, guía de envío, saldo y complementos de pago emitidos.
• Matriz de responsables: qué área atiende cada intención y cuál es su SLA objetivo.

Con eso ya puedes enriquecer cada caso: el sistema no solo dice “es un estatus de pedido”, sino “es el pedido 45821 de un cliente estratégico, salió ayer con la guía X y llega mañana”. Muchas veces esa misma información permite responder sin intervención humana.

Cómo calcular la prioridad sin depender de quién grita más

Recomendamos una calificación de prioridad explícita, entendible para el equipo y ajustable, en lugar de dejar que el modelo “decida” solo. Una fórmula práctica combina:

• Impacto operativo detectado en el mensaje: paro de línea, embarque detenido, error en factura que bloquea el pago.
• Valor del cliente: facturación de los últimos 12 meses o segmento.
• Riesgo comercial: quejas recientes, renovación de contrato próxima, cartera en disputa.
• Tiempo restante de SLA según la intención y el contrato.
• Sentimiento y escalamiento: lenguaje de molestia, menciones de cancelar o copia a directivos.

Cada factor suma puntos con pesos que define el negocio. El modelo aporta la lectura del texto; la regla aporta la decisión. Así, cuando alguien pregunta por qué un caso subió al primer lugar, la respuesta es auditable.

Enrutamiento: reglas primero, modelo después

El error más común es pedirle al modelo que adivine el área responsable. Funciona mejor una arquitectura en capas:

1. Reglas duras: si el remitente es un cliente con ejecutivo dedicado, siempre se le copia; si el mensaje menciona un folio fiscal, entra a facturación; si hay palabras de seguridad o lesión, escala de inmediato a calidad y dirección.
2. Clasificación con confianza: el modelo asigna intención y un nivel de confianza. Arriba del umbral, el caso se enruta solo; abajo, pasa a una bandeja de revisión humana con la sugerencia ya hecha.
3. Respuesta automática acotada: solo para intenciones de bajo riesgo y con datos verificados del ERP (estatus, reenvío de factura o complemento). Todo lo demás se responde con acuse y tiempo estimado.

Este diseño mantiene a las personas donde aportan juicio y elimina el trabajo de lectura, búsqueda y reparto que hoy consume buena parte del día.

Controles para que el triage no se convierta en un riesgo

• Datos personales: enmascara información sensible antes de enviarla al modelo y define qué campos nunca salen de tu entorno, en línea con la Ley Federal de Protección de Datos Personales.
• Bitácora: registra la intención, la confianza, la regla aplicada y quién cambió la decisión. Sin bitácora no hay mejora ni auditoría.
• Revisión de muestras: cada semana, un responsable revisa una muestra aleatoria de casos automatizados y corrige categorías.
• Límites a la respuesta automática: nada de compromisos de precio, crédito, garantía o fechas que el ERP no confirme.
• Salida de emergencia: un clic para que cualquier agente regrese un caso a la cola humana o lo reclasifique.

KPIs para medir si está funcionando

• Tiempo a primera asignación: de horas a minutos es un resultado típico.
• Tasa de rebote: porcentaje de casos reasignados a otra área.
• Precisión de clasificación: medida contra la muestra revisada por personas.
• Cumplimiento de SLA por intención y por segmento de cliente.
• Casos resueltos sin intervención en las intenciones permitidas.
• Horas liberadas del equipo de servicio, convertidas a costo para el caso de negocio.

Levanta la línea base antes de encender nada. Sin ella, el ROI se vuelve una opinión.

Piloto de seis semanas

Semanas 1 y 2: exportar historial, definir el catálogo de intenciones, armar la matriz de responsables y SLA, y medir la línea base.

Semana 3: conectar el buzón principal y el canal de WhatsApp de servicio, con extracción de entidades y consulta al ERP.

Semana 4: operar en modo sombra: el sistema clasifica y prioriza, el equipo trabaja como siempre y se comparan resultados.

Semana 5: activar enrutamiento automático para casos de alta confianza y respuestas automáticas para dos o tres intenciones de bajo riesgo.

Semana 6: medir KPIs contra la línea base, ajustar umbrales y decidir si se extiende a más canales o áreas.

Conclusión

El triage es la parte menos vistosa del servicio al cliente y, a la vez, la que más define la experiencia: si el caso llega a la persona correcta, con contexto y con la prioridad adecuada, casi todo lo demás se resuelve mejor. Con IA para leer y extraer, reglas claras para decidir y controles para auditar, una empresa B2B en México puede dejar de perder SLA por desorden y empezar a atender primero lo que más importa.

En NextWave diseñamos e implementamos flujos de triage conectados a tu ERP, CRM y canales actuales, empezando con un piloto acotado y medible. Escríbenos a contacto@nextWaveAI.AI o llámanos al +52 (33) 3126 6969 y platiquemos cómo se vería en tu operación.

La entrada Triage de tickets B2B con IA: cómo clasificar, priorizar y enrutar solicitudes de clientes sin perder el SLA se publicó primero en Next Wave.

En este artículo aterrizamos un caso de uso concreto: cómo usar IA y reglas de negocio para decidir el destino de cada devolución (lo que en logística se llama disposición) de forma rápida, consistente y medible.

Por qué la disposición de devoluciones se vuelve un hoyo de margen

El problema no es solo el volumen. Es que la información necesaria para decidir bien está repartida en varios lugares:

• El motivo y la evidencia viven en el ticket de servicio, el correo o el WhatsApp del cliente.
• El estado físico lo conoce quien inspecciona la pieza, muchas veces anotado a mano o en una foto sin estructura.
• El costo y el valor de recuperación están en el ERP: costo estándar, precio de lista, precio de saldo, costo de mano de obra de reparación.
• Las condiciones del proveedor (si acepta devolución, en qué plazo, con qué evidencia) están en contratos o en la memoria de compras.
• La demanda para vender esa pieza reacondicionada o como saldo está en el historial de ventas.

Sin juntar esas piezas, la decisión por defecto es la más cómoda, no la más rentable. Y mientras nadie decide, la pieza ocupa espacio, se deprecia y pierde la ventana para reclamarla al proveedor.

Las seis rutas posibles y qué datos necesita cada una

Antes de hablar de IA conviene definir las rutas y sus condiciones mínimas. Un esquema típico para distribuidores y fabricantes:

1. Regreso a inventario vendible: empaque íntegro, sin uso, dentro de la vida útil y con demanda activa.
2. Reacondicionado: falla menor o cosmética, costo de reacondicionamiento claramente por debajo del precio de venta reacondicionado.
3. Reparación para el cliente: producto en garantía donde reparar cuesta menos que reponer.
4. Devolución al proveedor (RTV): falla atribuible a fabricación y proveedor con política vigente de devolución o nota de crédito.
5. Saldo o canal secundario: producto funcional pero no vendible a precio completo (empaque dañado, modelo descontinuado).
6. Refacciones o destrucción: cuando ninguna ruta anterior recupera valor; la destrucción debe quedar documentada para efectos contables y fiscales con tu área contable.

La regla de oro: cada ruta debe tener un valor de recuperación esperado y un costo de ejecución. La mejor ruta es la que maximiza la diferencia, sujeta a restricciones (compromisos con el cliente, contratos, normatividad).

Dónde entra la IA (y dónde no)

La IA no sustituye las reglas; las alimenta y las acelera. Un flujo práctico tiene cuatro capas:

1. Estructurar la inspección

El inspector toma fotos y dicta o escribe una nota breve. Un modelo de lenguaje y visión convierte eso en campos: estado del empaque, signos de uso, componente afectado, tipo de falla, accesorios faltantes. El inspector confirma o corrige en una pantalla sencilla. Esto reduce el tiempo de captura y, sobre todo, deja datos comparables entre turnos y almacenes.

2. Aplicar reglas duras

Antes de cualquier recomendación, reglas determinísticas descartan rutas imposibles: el proveedor no acepta devoluciones después de cierto plazo, el producto tiene caducidad vencida, la categoría no se puede revender por política o por regulación sanitaria. Estas reglas viven en una tabla que operaciones puede mantener, no en el código del modelo.

3. Estimar valor por ruta

Con el historial de la empresa se estima, para cada ruta permitida, cuánto se recupera y cuánto cuesta: precio promedio de venta de reacondicionados de esa familia, tasa de éxito de reparaciones similares, probabilidad de que el proveedor acepte el RTV con la evidencia disponible. Aquí un modelo predictivo sencillo suele bastar; lo importante es que los datos de costo vengan del ERP y no de supuestos.

4. Recomendar con explicación y nivel de confianza

El sistema propone la ruta con mayor valor neto y explica por qué en lenguaje claro: “Reacondicionar: falla cosmética en carcasa, costo estimado bajo frente al precio de reacondicionado de la familia, demanda activa en canal mayoreo”. Si la confianza es baja o el valor del producto supera un umbral, la decisión pasa a un supervisor. Las recomendaciones de alta confianza y bajo valor pueden ejecutarse directamente.

Conexión con el resto de la operación

La disposición solo genera valor si se ejecuta. Por eso el flujo debe disparar acciones en los sistemas existentes:

• Movimiento de inventario a la ubicación correcta (vendible, reacondicionamiento, cuarentena, RTV).
• Orden de trabajo para reparación o reacondicionamiento con el costo estimado como referencia.
• Expediente de devolución al proveedor con fotos, número de lote y fechas, listo para enviar dentro del plazo.
• Alta en el canal de saldos con precio sugerido.
• Registro del motivo y la ruta para que calidad y compras vean patrones por proveedor, lote o SKU.

Si ya trabajas reclamos de garantía con IA, esta capa es el siguiente paso natural: el reclamo define quién paga; la disposición define cuánto valor rescatas de la pieza.

Controles para que no se vuelva una caja negra

• Umbrales de autonomía por valor del producto y por nivel de confianza.
• Muestreo de auditoría: revisar periódicamente una fracción de decisiones automáticas para medir aciertos.
• Bitácora completa: datos de entrada, ruta recomendada, ruta ejecutada y quién aprobó.
• Retroalimentación: si un reacondicionado no se vendió o una reparación falló, ese resultado vuelve al modelo.
• Revisión de reglas con compras y calidad cuando cambian contratos con proveedores.

KPIs que conviene medir desde el primer día

• Días promedio desde la recepción de la devolución hasta su disposición.
• Valor recuperado como porcentaje del costo de las piezas devueltas.
• Porcentaje de piezas enviadas a destrucción o merma.
• Monto aceptado por proveedores vía RTV y reclamos vencidos por plazo.
• Inventario de devoluciones pendientes de decisión (piezas y valor).
• Tasa de acuerdo entre la recomendación del sistema y la decisión del supervisor.

Cómo arrancar en cuatro semanas

Semana 1: elegir una o dos familias de producto con volumen relevante de devoluciones, documentar las rutas permitidas y sus reglas, y levantar los datos de costo y precio de recuperación del ERP.

Semana 2: poner en marcha la captura estructurada de inspección con fotos y nota, y la tabla de reglas duras.

Semana 3: calcular valor neto por ruta con el historial disponible y operar en modo sombra: el sistema recomienda, el equipo decide como siempre y se comparan resultados.

Semana 4: activar autonomía para casos de alta confianza y bajo valor, conectar los movimientos de inventario y medir los KPIs contra la línea base.

Conclusión

Las devoluciones no tienen que ser un costo hundido. Con inspección estructurada, reglas claras y una estimación honesta del valor de cada ruta, la IA convierte una decisión improvisada en un proceso repetible que libera espacio, reduce merma y recupera dinero de proveedores y canales secundarios. En NextWave ayudamos a empresas mexicanas a diseñar e implementar este tipo de flujos conectados a su ERP, empezando por un piloto acotado y medible. Si las devoluciones se te están acumulando en el almacén, platiquemos.

La entrada Devoluciones con IA: cómo decidir si reacondicionar, revender, reparar o destruir cada pieza sin perder margen se publicó primero en Next Wave.