Si vendo con BigCommerce, puedo bajar buena parte del soporte repetido si preparo bien el bot desde el día uno. En muchas tiendas, las consultas WISMO explican entre 35% y 55% de los tickets, y un bot puede absorber hasta 80% de las preguntas rutinarias cuando tiene datos, reglas y desvío humano bien armados.
Yo lo resumiría así:
La idea no es que el bot responda todo. La idea es que resuelva lo repetido, en segundos, sin exponer datos de más ni meterse en casos de plata, fraude o reclamos fuera de política.
Puntos que yo tendría sí o sí en cuenta:
Una vista rápida de qué conviene activar primero:
| Flujo | Lo que yo habilitaría al inicio | Cuándo lo frenaría |
|---|---|---|
| FAQ | Políticas aprobadas y respuestas fijas | Si la pregunta queda fuera de la base |
| Estado de pedido | Consulta por orden + email | Si no encuentra el pedido |
| Seguimiento |
| Carrier, tracking y ETA |
| Si el tracking no muestra movimiento |
| Cambios / cancelaciones | Solo pedidos no despachados | Si ya salió o hay un caso raro |
| Devoluciones | Solo dentro del plazo y sin exclusiones | Si está fuera de política |
| Intercambios | Solo si hay stock y regla clara | Si falta stock o cambia el precio |
En pocas palabras: si armo bien datos, contenido, guardrails y handoff, puedo dar soporte 24/7 sin hacer que el cliente repita todo dos veces. Con eso claro, ya tiene sentido entrar al setup fino del bot en BigCommerce.
Cómo configurar un chatbot en BigCommerce para soporte 24/7
Antes de configurar el bot, resolvé tres frentes: accesos, datos y contenido. Si uno falla, el bot puede contestar mal o, peor, quedarse sin respuesta.
Necesitás permisos de propietario de la tienda o de administrador total para instalar el widget desde Storefront → Script Manager. Si querés que consulte pedidos en tiempo real, creá un cliente de API dedicado con acceso de lectura sobre pedidos, envíos y reintegros.
Si además va a hacer cambios, conviene usar otro cliente de API, separado del anterior, con permisos mínimos y reglas de elegibilidad bien cerradas. Las credenciales tienen que quedar guardadas en la plataforma del bot, nunca en el storefront.
Con eso listo, el bot ya puede leer datos reales. El paso siguiente es decidir qué información va a devolver.
Si el contenido está mal armado, el bot lo va a reflejar. Por eso, conviene reescribir cada política en pares de pregunta y respuesta cortos, pensados desde el lado del cliente. Cubrí temas como envíos, pagos, cuotas, devoluciones, cambios, cancelaciones y exclusiones por categoría, siempre con respuestas breves y lenguaje simple.
También marcá los casos donde el texto tiene que salir exacto, como el derecho de arrepentimiento o las garantías legales. En esos temas, el bot debería usar una plantilla fija en vez de generar una respuesta nueva.
Sumá además ejemplos negativos. O sea: preguntas que el bot no tiene que contestar desde la política, como asesoramiento legal o acuerdos comerciales especiales. Eso ayuda a forzar la derivación a una persona cuando corresponde. El bot no aprende por arte de magia: responde según reglas de envío, cambio, devolución y cancelación que vos ya dejaste definidas.
Con el contenido cerrado, recién ahí tiene sentido ajustar formato y tono para Argentina.
Configurá ARS, dd/mm/yyyy y America/Argentina/Buenos_Aires. Mostrá los precios como $ 12.499,00 y las fechas como 13/09/2026. Vale la pena probar un pedido real del 03/07/2026 para chequear que no mezcle formatos.
En el tono, usá español con referencias locales naturales, como:
Además, definí desde el arranque si el bot va a hablar de "vos" o de "usted". En Argentina, la mayoría de las marcas B2C usa "vos". Lo importante es sostener esa elección en todos los flujos y también en las respuestas enlatadas.
Con los accesos y el contenido ya listos, toca instalar el widget y probarlo con datos reales. En BigCommerce, el camino más común es Storefront → Script Manager → Create a Script. Poné un nombre claro, dejá Location = Footer, Pages = All pages y pegá el snippet en Script contents.
Guardás, y listo: el widget queda activo en todo el sitio. Eso permite dar soporte de punta a punta, desde la home hasta el checkout.
Después, probalo en serio. Hacelo en incógnito, en escritorio y en celular. Fijate que el ícono cargue rápido, que no tape el botón de compra y que el texto esté en español. Si tu tienda usa un banner de consentimiento de cookies, marcá el script como Functional o Essential para evitar que se bloquee solo.
Una vez que el widget ya está visible, el bot tiene que leer datos reales. El flujo debería funcionar así: el cliente ingresa su número de pedido y el email que usó al comprar, y el bot valida esa combinación contra la API de BigCommerce.
Si no coincide, bloqueá la consulta y derivala a soporte humano. Si coincide, mostrá solo estos datos:
Nunca tiene que exponer la dirección completa ni datos de pago. Y los estados de BigCommerce, como Shipped (2), Awaiting Shipment (9) o Cancelled (5), conviene traducirlos en el momento a frases simples, como "Tu pedido está en preparación" o "Tu pedido fue cancelado". El cliente no tiene por qué ver códigos técnicos.
Con la lectura de pedidos ya resuelta, seguí con los flujos de FAQ, cambios y devoluciones.
Si atendés en más de un canal, conviene centralizar los datos desde el arranque. Si también operás por WhatsApp o Instagram, usá BigCommerce como fuente única para sincronizar productos, pedidos, stock, descuentos y políticas en todos los canales.
Burbuxa puede hacer esa sincronización en tiempo real.
Con la integración ya hecha, armá primero los flujos de automatización que te van a sacar más peso de encima. Entre el 60% y el 80% de los tickets de soporte en e-commerce repiten los mismos patrones: estado de pedido, envíos, devoluciones y FAQ. Si el bot puede leer los datos correctos, buena parte de eso se automatiza sin vueltas.
La idea es simple: primero resolvé lo repetido. Después sí, avanzá sobre los casos que de verdad mueven el volumen de tickets.
Las FAQ son un gran punto de arranque porque el riesgo es bajo y el impacto es alto. Acá el bot no improvisa: devuelve respuestas ya aprobadas sobre tiempos de entrega, medios de pago, zonas de cobertura y ventanas de cambio o devolución. Cada respuesta tiene que salir de una entrada puntual de la base de conocimiento que preparaste antes.
Dejá un solo ejemplo por bloque y en formato local:
"En CABA y GBA, los envíos demoran entre 2 y 4 días hábiles."
Cuando ya tenés resuelta la parte de políticas, el siguiente flujo que más mueve la aguja es el estado de pedido.
El flujo de estado de pedido, o WISMO, suele explicar entre el 30% y el 40% del volumen de soporte. Por eso conviene automatizarlo apenas el bot tenga acceso a los datos del pedido.
El flujo puede pedir número de pedido y email, consultar BigCommerce y responder algo como "Tu pedido está en preparación y sale mañana". Si además existe número de seguimiento, sumá el link directo al carrier - Andreani, OCA, Correo Argentino - junto con la ventana estimada de entrega.
Una vez que informa el estado, el bot solo debería actuar por su cuenta cuando la política lo permita.
Estos flujos piden más cuidado porque tocan datos del pedido o temas de plata. Antes de hacer nada, el bot tiene que revisar el estado del pedido. En cambios de dirección o cancelaciones, solo puede avanzar si el pedido todavía no fue despachado. Si ya salió, explica qué pasó y deriva al equipo humano con el contexto completo.
En devoluciones e intercambios, el bot compara la fecha de entrega con el plazo de la política - por ejemplo, 30 días desde la entrega - y chequea si el producto entra en alguna excepción, como ropa interior, electrónicos abiertos o productos de higiene. Si el caso aplica, puede dejar la solicitud casi lista y dar las instrucciones de envío. Si no aplica o hay algo raro, escala sin cortar la conversación.
Resumilo así:
| Flujo | Datos del cliente | Datos de BigCommerce | Escalá cuando |
|---|---|---|---|
| FAQ y políticas | Solo la pregunta | Base de conocimiento / políticas | Pregunta fuera de la KB o respuesta no útil |
| Estado de pedido | N° de pedido + email | Estado, fecha, fulfillment | Pedido no encontrado o demorado sin actualización |
| Seguimiento | N° de pedido + email | Carrier, link de tracking, ETA | Link roto o paquete sin movimiento |
| Cambios / cancelaciones | N° de pedido + nuevo dato | Estado de fulfillment | Pedido ya despachado o cambio complejo |
| Devoluciones | N° de pedido + motivo | Fecha de entrega, plazo de política | Fuera de plazo o producto con excepción |
| Intercambios | N° de pedido + SKU deseado | Stock en tiempo real, política | Sin stock disponible o diferencia de precio |
Con estos flujos ya listos, el paso que sigue es marcar límites duros y definir cuándo derivar a una persona sin perder el contexto.
Después de definir los flujos, falta una parte que pesa mucho: los límites de acción y la derivación a una persona. Con los flujos ya armados, definí hasta dónde llega la autonomía del bot y en qué momento tiene que escalar. Ahí está el riesgo de verdad.
El bot puede hacerse cargo de tareas de bajo riesgo, como FAQ, estado de pedido, tracking y devoluciones simples. Pero no debería meterse con cambios de pago, reembolsos por encima del tope fijado ni decisiones sobre fraude o disputas de facturación. Esos casos tienen que pasar sí o sí a una persona.
Para ordenar la zona gris, usá umbrales de confianza. Si la confianza supera el 85%, el bot responde. Si queda entre 60% y 84%, responde, pero también ofrece derivación. Si baja de 60%, escala de inmediato. Y si falló dos veces seguidas, en el siguiente intento deriva sin insistir.
También conviene dejar activos desde el arranque los disparadores de escalada que más problemas suelen traer. Entre ellos:
Cuando el bot cruza un límite, la derivación no puede llegar vacía. Tiene que pasar con contexto completo. Cada caso debería llegar al agente con la transcripción entera de la charla, la identidad del cliente y el canal de origen, el pedido, su estado, la intención detectada, los artículos de la base de conocimiento que ya se consultaron y el motivo de la escalada, como un reembolso por encima del tope o un pedido explícito de hablar con una persona.
Eso evita el clásico ida y vuelta de “pasame de nuevo tu número de pedido” o “contame otra vez qué pasó”. Y se nota enseguida: el agente arranca desde donde quedó el cliente, no desde cero.
Antes de abrir el bot al tráfico, validá esto:
| Área | Qué verificar |
|---|---|
| Integración | Pedidos, clientes, inventario, descuentos y políticas sincronizados |
| Contenido | Todas las respuestas de FAQ y políticas revisadas y aprobadas (envíos, cambios, devoluciones, medios de pago) |
| Alcance inicial | Solo flujos de bajo riesgo habilitados al lanzar: FAQ, estado de pedido, seguimiento y devoluciones simples |
| Localización | es-AR, ARS, fechas y horarios locales, unidades métricas |
| Guardrails | Umbrales de confianza configurados, disparadores de escalada activos y tope de reembolso definido |
| Derivación | Derivación probada con contexto completo; agentes confirmaron que reciben la información correcta |
| Pruebas | Escenarios de borde testeados internamente, incluyendo clientes frustrados y casos fuera de política |
| Métricas | Tasa de resolución automática, tasa de escalada y CSAT definidos para monitorear desde el día uno |
Al salir, mantené el alcance corto: primero FAQ, estado de pedido, seguimiento y devoluciones simples. Después, con guardrails, handoff y métricas ya validados, recién ahí sumá casos más sensibles.
La configuración lleva muy poco tiempo: la mayoría de las tiendas termina el proceso en menos de 10 minutos.
El flujo se resume en tres pasos: conectás tu tienda, aprobás el tono de voz de tu marca y probás todo en un entorno controlado antes de salir al público. Después, el sistema importa catálogo, pedidos y clientes para empezar a funcionar en minutos.
Para responder con precisión y resolver consultas por su cuenta, Burbuxa necesita acceso en tiempo real a los datos clave de tu tienda.
Hablamos de información como:
Cuando toda esa información está unificada, el bot puede saber a quién está atendiendo y qué pedido está consultando.
¿El resultado? Respuestas pertinentes, al día y en línea con cómo funciona tu operación.
Conviene pasar el caso a una persona cuando aparece algo fuera de lo común, delicado o que pide un criterio que va más allá de lo automático. Por ejemplo, frente a quejas complejas, reclamos puntuales o cuando el cliente necesita una atención más personal.
La derivación se hace sin vueltas: se comparte el historial de la charla, los datos del cliente y los detalles del pedido, así la persona no tiene que repetir lo mismo otra vez.
