Un asistente con IA embebible en cualquier web con un pequeño snippet. Responde solo desde el conocimiento del cliente, capta contactos y —cuando el sistema lo permite— vende de verdad: reserva y cobro con entrega de entrada por QR. Un único motor sirve a todos los clientes por parámetro.
El núcleo conversacional (RAG + derivación a humano) está siempre. La venta es «enchufar una herramienta» que llama al sistema del cliente. El mismo motor, distinto por configuración, no por código.
Contesta dudas usando solo la información curada de cada cliente (RAG). No alucina: si algo no está, lo dice y deriva a una persona.
Cuando hay interés, recoge los datos, deja registro y avisa al instante por Telegram + email. Patrón derivar_a_humano montado.
Contra el ticketing del cliente (Blex vía OCTO) y con pago en Stripe fuera del chat. La entrada llega con su QR por email, automáticamente.
Toda la lógica vive una sola vez en n8n. Cada mensaje entra por la puerta (rate-limit y captcha), el motor carga la config del cliente por su instancia, construye el prompt, recupera conocimiento (RAG) y, si el plan lo incluye, activa las herramientas de venta. Escalar a un cliente nuevo es añadir una fila, no clonar el flujo.
Nombre, persona, idioma, si vende, tabla de conocimiento y backend de venta salen de una fila en chatbot_clientes. El prompt se construye a partir de ella.
buscar_conocimiento siempre; consultar_disponibilidad y preparar_pago solo cuando el cliente vende. El agente decide cuándo usarlas.
Un único despliegue sirve a todas las instancias por parámetro. Hoy vivas la del Teatro Flamenco (vende) y la de la propia arquitectura DSS (solo informa).
La misma base atiende los dos modos; lo transaccional se activa por proyecto según lo que permita el sistema del cliente.
Responde solo desde el conocimiento curado de la instancia, respeta sus guardarraíles y deriva a una persona (Telegram + email) cuando no resuelve o lo piden.
El mismo motor con herramientas de venta activadas por proyecto. Primer caso funcionando: vender entradas de verdad desde el chat contra Blex (vía OCTO), con pago Stripe fuera de la conversación.
Usa nuestro ticketing: transaccional completo listo. Caso ideal.
OCTO casi directo; API propia = conector a medida (desarrollo extra).
Venta sin backend de reservas: pago directo con Stripe.
Venta/reserva asistida: el bot recoge y lo pasa a un humano.
Así ejecuta el motor una compra de principio a fin. Todo el pago queda fuera de la conversación, en una página segura de Stripe; el chat nunca ve datos de tarjeta.
El usuario pide comprar; el agente convierte la fecha a YYYY-MM-DD y llama a consultar_disponibilidad. Muestra pases y tarifas con precio en euros; nunca IDs ni aforo.
Recoge pase, tarifa, cantidad, nombre y email sin repetir lo ya dado. Resume el pedido y pide confirmación explícita antes de cobrar.
preparar_pago valida los datos, crea la reserva (hold ~15 min) y devuelve el enlace de checkout de Stripe. El cobro va siempre a la cuenta del cliente.
Al pagar, un webhook con firma verificada confirma la reserva en OCTO/Blex y dispara la entrega de la entrada con su QR por email. El bot no afirma el pago: llega solo.
Ejemplo ilustrativo del flujo conversacional de compra.
No mete toda la base en cada mensaje: la indexa una vez y recupera los fragmentos pertinentes por búsqueda vectorial. Eso abarata el coste y permite usar modelos eficientes sin perder rigor.
El conocimiento de cada cliente se estructura y se ingesta en su propia tabla vectorial en Supabase (pgvector), aislado del resto.
Embeddings de Gemini; el motor consulta la tabla que indica la config (tabla_conocimiento) y pasa al agente solo los fragmentos top-K.
Se reingesta el conocimiento cuando cambia; el flujo no se toca. Un flujo de ingesta dedicado lo mantiene al día.
El chatbot pasó un bloque de endurecimiento antes del go-live. Los secretos nunca viven en texto plano y el consumo está acotado por diseño.
Tokens OCTO y claves Stripe de cada cliente cifrados en Supabase Vault; el motor descifra en ejecución. La config ya no los contiene.
Por sesión: máx. 20/minuto y 300/día. Si se supera, avisa sin llamar al modelo. Prioriza disponibilidad si la base fallara.
Cloudflare Turnstile activable por cliente. Verifica una vez por sesión; falla-abierto ante caídas para no cortar el servicio.
El pago va siempre a la cuenta de Stripe del cliente. DSS no custodia fondos ni datos de tarjeta.
Cumplimos lo que depende de nosotros y somos transparentes con el tratamiento que hacen los terceros del sistema, que el cliente acepta con la firma. No vendemos un «cumplimiento absoluto»: mostramos qué está cubierto y qué se rige por las condiciones de cada proveedor.
Datos en la UE por defecto (base de datos en París, email en Alemania). Cifrado y secretos en Vault, RLS en la base, panel con login y roles. Pagos fuera del chat en la Stripe del cliente: no custodiamos datos de tarjeta. Minimización de datos.
El cliente es el Responsable y DSS el Encargado (art. 28 RGPD). Con la firma se acepta el DPA, con medidas de seguridad (art. 32), notificación de brechas, supresión al final y asistencia en los derechos de los usuarios.
Lista de subencargados transparente. La parte transaccional (la compra) usa un proveedor que no entrena con los datos. Parte del sistema opera hoy con servicios gratuitos, cuyo tratamiento el cliente acepta; existe una opción de futuro de migrar a proveedores de pago con DPA a coste bajo.
Todo el control de acceso se decide en el servidor (endpoint cb-metricas): el panel solo pinta lo que el endpoint autoriza. Login por enlace mágico (Supabase Auth), CORS restringido al dominio del panel.
El token de sesión se valida contra Supabase; se derivan rol e instancia. A un cliente se le fuerza su instancia aunque manipule la URL. Sin token → 401.
Conversaciones, ventas, idiomas y temas; para admin, también coste de IA y consumo frente al techo del plan.
Publicado en panelchatbot.dssnetwork.es. Pendiente (backlog): gestor de usuarios con contraseña y email corporativo.
Precio cerrado con IA incluida: el cliente no paga consumo de IA. El límite es de conversaciones al mes; el exceso se cubre por tramos.
Informa y capta. Responde con el conocimiento del cliente (RAG), capta leads y avisa al equipo por Telegram o email. No vende.
Hasta 1.500 conversaciones/mes
Vende. Todo lo del Básico y, además, venta y reserva transaccional real: disponibilidad, reserva y cobro con Stripe, con entrega (p. ej. entrada con QR).
Hasta 2.500 conversaciones/mes
Vende, alto volumen. Todo lo de Pro, dimensionado para gran volumen, y con acceso al modelo de grupo multi-sede.
Hasta 6.000 conversaciones/mes
A medida. Volumen alto e integraciones específicas (APIs propias, ticketing no estándar, necesidades particulares).
Volumen a medida
Puesta en marcha gratis con la contratación anual. Integraciones a medida (API propia, otro ticketing): presupuesto aparte.
Si te pasas del límite del plan, se añade por tramos: +500 → 15 € · +1.500 → 35 € · +3.000 → 60 € al mes. Si el exceso es recurrente, subir de plan sale mejor. La IA sigue incluida.
Solo en Business: varias sedes con panel agregado y descuento por sede — −30 % hasta 4 sedes y −50 % desde 5. Alta de sede adicional: 150 €.
El diferencial no es el precio por conversación, sino hecho y mantenido por DSS, venta real y precio cerrado con IA incluida.
Lo informativo corre en un pool de modelos gratuitos vía LiteLLM; solo lo transaccional usa Haiku (con caché). La infraestructura es fija y compartida entre todos los clientes.
Coste de IA típico: Básico ~0 € (100 % gratuito) · Pro ~10-20 € · Business ~20-50 € al mes. El precio lo sostiene el servicio gestionado, no la IA.
Piezas estándar y bien separadas, con una única fuente de verdad por cosa.
n8n autohospedado · n8n.dssnetwork.es. Motor genérico multi-tenant, webhooks y herramientas.
Supabase (Postgres + pgvector): conocimiento por instancia, log, clientes/config, usuarios y rate.
Pool gratuito vía LiteLLM (Groq/Cerebras/Mistral) + Haiku 4.5 de red; embeddings Gemini.
Stripe (checkout, siempre a la cuenta del cliente) · Blex vía el estándar OCTO.
Supabase Vault (secretos), Cloudflare Turnstile (captcha), rate-limit por sesión, CORS restringido.
Git · dss-360/dss-chatbot. Panel en panelchatbot.dssnetwork.es.
No es un chat de preguntas: informa con rigor, capta y cierra ventas contra el sistema del cliente. Un solo motor, precio cerrado con IA incluida, y todo el pago en la cuenta del cliente.