Bot para consultas: conecta con lo que ya usas

En tu empresa ya tienes ERP, CRM, plataformas de pagos y la obligación de cumplir con SUNAT. El reto es que esos sistemas no se hablan y, sin una solución adecuada, el bot para responder consultas de clientes termina aislado. Aquí verás paso a paso cómo enlazarlo con lo que ya utilizas, sin sustituir nada.

Con qué se tiene que hablar

Antes de buscar cualquier integración, haz un inventario de los sistemas que forman el núcleo de tu operación:

• ERP (ej. SAP Business One, Microsoft Dynamics) – gestiona inventario, órdenes y contabilidad.
• CRM (HubSpot, Zoho) – almacena datos de clientes y su historial de interacción.
• Plataforma de facturación electrónica – genera y envía comprobantes a SUNAT.
• Pasarela de pagos – Yape, Plin, Niubiz, Izipay.
• Canales de atención – WhatsApp Business, web chat, correo.

Estos sistemas son la base; el bot debe consumir y actualizar la información que ya existe, no crear una nueva base de datos. Identifica los puntos de contacto críticos: número de pedido, estado de pago, fecha de entrega. Cada uno será un endpoint que el bot consultará.

• El síntoma, en una frase. La explicación, en dos.

SUNAT y facturación electrónica

Requisitos obligatorios

1. Certificado digital emitido por la SUNAT para firmar electrónicamente los comprobantes.
2. Formato UBL 2.1 o XML según el tipo de documento (Factura, Boleta, Nota de crédito).
3. Respuesta de aceptación de la SUNAT en menos de 30 segundos; de lo contrario, el proceso debe reintentarse.

Errores típicos

• Desfase de sincronización: el bot envía una factura antes de que el ERP la haya registrado, lo que genera rechazo por número duplicado.
• Campos obligatorios vacíos: la API del ERP no envía el RUC del cliente, y SUNAT devuelve el código 203.
• Límites de velocidad: superar los 20 envíos por minuto produce bloqueo temporal de la cuenta.

Cómo evitarlos

• Implementa una cola de mensajes (por ejemplo, RabbitMQ) que garantice el orden y la velocidad de envío.
• Usa webhooks de la plataforma de facturación para confirmar la aceptación antes de actualizar el estado en el CRM.
• Programa reintentos exponenciales: si la respuesta es error 503, vuelve a intentar en 5 s, 15 s y 45 s.

Cobros y bancos

Yape y Plin

Ambas aplicaciones funcionan con APIs REST que requieren token de acceso y firma HMAC. Los pasos clave son:

1. Registro de la empresa en la consola de desarrolladores y generación del client_id y client_secret.
2. Autenticación mediante OAuth 2.0 – el token tiene vigencia de 1 hora.
3. Endpoint de verificación de transacción que devuelve el número de referencia y el estado (pendiente, aceptado, rechazado).

Niubiz e Izipay

Estas pasarelas son más robustas y permiten captura previa (auth‑capture). El flujo típico:

• Auth: el bot solicita autorización de monto y recibe un authorization_code.
• Capture: 24 h después, si el pedido se confirma, se captura el monto.
• Reversal: si el cliente cancela, se revierte la autorización.

Conexión real

• Mapeo de campos: el número de operación que devuelve la pasarela debe guardarse en el ERP como referencia de pago.
• Confirmación asíncrona: configura un webhook que notifique al bot cuando el pago cambie de pendiente a aceptado; el bot actualiza automáticamente el estado del pedido en el CRM.
• Plazo típico: la integración completa, pruebas incluidas, suele tardar 4 semanas.

Qué pedirle al proveedor

1. Documentación de API: especificaciones OpenAPI/Swagger, ejemplos de request/response y límites de tasa.
2. Entorno de pruebas (sandbox): al menos 30 días de acceso para validar flujos sin afectar datos reales.
3. Política de versionado: el proveedor debe anunciar cambios al menos 30 días antes; si la versión cambia, el contrato de integración debe incluir cláusula de adaptación.
4. Soporte técnico: tiempo de respuesta máximo 2 h en horario laboral para incidencias críticas.
5. Garantía de disponibilidad: SLA ≥ 99.5 % mensual; en caso de caída, se aplican créditos de servicio.

Cuando la otra parte cambia

• Versionado semántico: si la API pasa de 1.4 a 2.0, revisa los breaking changes y actualiza los adaptadores del bot en un sprint de 2 semanas.
• Pruebas de regresión automatizadas: mantén un conjunto de pruebas que simulen los principales escenarios (consulta de estado, generación de factura, verificación de pago).
• Plan de contingencia: si la API se vuelve indisponible, el bot debe responder con un mensaje genérico y registrar la incidencia para su resolución posterior.

Conectar un bot a tus sistemas existentes implica mapear datos, respetar normativas y pactar niveles de servicio claros.

Conclusión

Al terminar este artículo deberías tener claro que conectar un bot para responder consultas de clientes no requiere reemplazar tus plataformas actuales. Identifica los sistemas críticos, respeta los requisitos de SUNAT, usa los webhooks de los bancos y exige documentación y SLA a los proveedores. Con un plan de integración bien definido, el tiempo típico es de 4 a 6 semanas y el bot quedará alineado con tu ERP, CRM y pasarelas de pago, ofreciendo a tus clientes respuestas rápidas y precisas sin crear silos de información.