Automatizar WhatsApp con stock por variante en e-commerce: cuando el problema no es el bot, es que no ve el dato
“¿Viene en verde?”
La persona de atención ya respondió esa misma pregunta diez veces hoy. Tiene otras 15 conversaciones abiertas, el admin de la tienda en otra pestaña, y va saltando entre WhatsApp, catálogo y stock para confirmar si ese buzo existe justo en ese color, en ese talle, en esa variante. No está atendiendo mal. Está haciendo de puente entre el cliente y un dato que no está donde debería.
Y ahí es donde muchos asistentes fallan. No por torpes, sino porque les piden adivinar.
El bot no está fallando por torpe; está fallando porque le piden adivinar stock
En LATAM, WhatsApp no es un canal accesorio. En Argentina, el uso activo de WhatsApp entre usuarios móviles de internet llegó al 84%, y en Brasil al 93%, según Panoramas. Si el canal principal del negocio es ese, cualquier fricción de catálogo explota ahí primero.
Ahora bien, una cosa es responder “hacemos envíos” o “aceptamos transferencia” y otra muy distinta es contestar “sí, te queda el 42 en blanco”. Lo segundo exige dato vivo. No redacción linda.
Ese es el punto.
Yo no compro la idea de que esto se arregla entrenando mejor el asistente
Yo no compro ese argumento. Un asistente puede sonar más natural, entender mejor la intención, incluso redactar mejor que una persona apurada. Pero si el catálogo que tiene atrás es estático, sigue sin saber si la variante existe hoy.
En WooCommerce, las variaciones son recursos propios, con atributos, precio, stock_quantity y lógica de manage_stock a nivel variación. En Shopify, cada variant representa una combinación de opciones y tiene su propio precio, SKU e inventario. No es una descripción decorativa del producto padre. Es otra cosa.
Parece un problema de copy. No lo es.
En indumentaria y calzado, el catálogo base casi no sirve para responder
En moda y calzado, el producto “base” sirve para mostrar la ficha. Para responder consultas, muchas veces sirve poco. Una prenda con 6 talles, 4 colores y 2 largos ya te da 48 combinaciones posibles. Y cada una puede tener stock distinto.
La documentación de Tiendanube lo dice sin vueltas: las variantes agrupan, por ejemplo, un zapato con distintos talles y colores, y cada variante tiene values, price, sku y stock. Shopify permite hasta 3 opciones por producto y hasta 2.048 variantes por producto. Tiendanube permite hasta 1.000 variantes. O sea: la complejidad no es una rareza, está en el modelo de datos.
Y en clientes reales, lo más buscado no se distribuye parejo. Un análisis operativo de fulfillment de moda muestra que el talle M suele vender entre 2 y 3 veces más que XS o XXXL, y que un diseño con 5 colores y 6 talles ya genera 30 SKUs distintos IMD Fulfilment. La consulta del cliente casi siempre cae justo ahí, en la combinación más caliente.
La jugada moría ahí.
Responder en genérico sobre variantes es una forma prolija de responder mal
Cuando el cliente pregunta “¿tenés la zapatilla en 42 negro?”, responder “sí, tenemos ese modelo” no resuelve nada. Responde otra pregunta. Y peor: da sensación de certeza donde no la hay.
Las discrepancias de inventario tienen consecuencias bastante concretas. NetSuite define el problema como la brecha entre lo registrado y el stock físico real, y lo vincula con stockouts, ventas perdidas y costos operativos. ShipBob agrega algo que pega directo en atención: pedidos mal armados, sobreventa, backorders y clientes que asocian la marca con “unreliability and inaccuracy”.
Pequeño paréntesis: si tu asistente confirma stock sin mirar una fuente confiable, no estás automatizando atención; estás automatizando el pedido de disculpas de mañana.
Para qué mentirte.
El costo no es solo la venta caída: también es el tiempo del equipo quemado en microconsultas
El costo oculto no siempre entra por cancelación. Entra por desgaste. Por minutos partidos en consultas chiquitas que parecen inocentes y te comen el día.
En e-commerce, Remark marca que un tiempo de respuesta promedio favorable suele estar entre 1 y 4 horas. Zendesk pone expectativas todavía más duras según canal y recuerda algo clave: velocidad sin calidad no alcanza. Esta semana, en un cliente de indumentaria, vimos exactamente eso: responder rápido “te averiguo” no baja carga si después alguien tiene que abrir el sistema, buscar la variante y volver a escribir.
Y cuando eso pasa 40, 50 o 60 veces por día, ya no es una anécdota. Es un cuello de botella operativo.
Caso testigo: 60 preguntas por día que no deberían depender de una pestaña abierta
Imaginá una tienda de zapatillas con 15 modelos. Cada modelo viene en 7 talles y 3 colores. Son 315 combinaciones posibles. No es un catálogo enorme, pero ya alcanza para armar un lindo quilombo si todo entra por WhatsApp.
Ahora sumale 60 consultas diarias sobre variantes específicas. “¿Tenés el modelo Runner en 41 azul?” “¿La Urban viene en 38 negra?” “¿La misma pero en blanco?” Sin conexión al catálogo, el flujo suele ser siempre el mismo: entra el mensaje, alguien abre la tienda o el ERP, busca el producto, entra a la variante, confirma stock, vuelve a WhatsApp, responde, y cruza los dedos para que nadie haya vendido esa unidad en el medio.
Si la respuesta tarda, el cliente se enfría. Si la respuesta sale genérica, no sirve. Si la respuesta sale mal, después tenés que explicar por qué no estaba. Y si encima el equipo está con varias conversaciones a la vez, el margen para confundir un talle o un color no es precisamente chico.
Con un asistente conectado al catálogo real, el flujo cambia bastante. El cliente pregunta por una combinación concreta, el asistente consulta la variante exacta, devuelve disponibilidad, precio y alternativa si no hay stock. “En negro 41 no queda. En azul 41 sí, a $X.” O “te queda 1 par en 42 blanco”. No resuelve todo, pero saca del medio una cantidad enorme de ida y vuelta manual.
No es magia. Es estructura.
La solución de verdad empieza por una fuente de verdad
La discusión útil no es “bot sí o bot no”. Es de dónde sale el dato. Si el asistente no consulta una fuente de verdad, inventa o generaliza. Si consulta una fuente de verdad, puede responder con precisión o admitir incertidumbre cuando corresponde.
En Tiendanube, el recurso Product ya incluye variants, y cada variante trae atributos, precio y stock. En Product Variant, además, aparecen values, price, stock_management, stock y SKU. En Shopify y WooCommerce pasa lo mismo con sus propias estructuras.
Dicho más simple: para automatizar WhatsApp con stock por variante en e-commerce, el asistente tiene que leer el catálogo real, no un PDF, no una planilla exportada hace dos semanas, no una base de preguntas frecuentes.
Qué implica técnicamente conectar WooCommerce, Tiendanube o Shopify
Acá es donde conviene bajar un cambio y hablar claro. Conectar un asistente al catálogo con variantes requiere API keys, autenticación, extracción de productos, lectura de atributos, precios y stock, y una estrategia de sincronización.
El mes pasado trabajé con un WooCommerce donde usamos las API keys del cliente para extraer catálogo completo, variaciones y precios. Se puede hacer, pero hay que entender cómo expone los datos la plataforma. En WooCommerce, las variaciones se consultan por producto y cada una trae atributos, precio y stock. Ahí ya aparece una primera complejidad práctica: no siempre tenés todo “eager loaded”; muchas veces hay que recorrer productos y luego sus variaciones.
Parece enchufar una API. No lo es.
En Shopify, además, inventory_quantity puede ser un agregado entre ubicaciones, y para stock por ubicación hay que ir a InventoryLevel. En Tiendanube, podés trabajar con variantes y hasta actualizar colecciones completas de variantes en batch. Son modelos distintos. Si soy honesto, acá es donde más humo veo cuando alguien vende “lo conectamos en cinco minutos”.
Si soy honesto, acá es donde más humo veo
Porque no alcanza con leer una vez el catálogo. Hay que decidir cada cuánto sincronizar, qué hacer si el stock cambió hace segundos, cómo responder si el dato viene incompleto, y qué pasa cuando una plataforma cambia su modelo de inventario.
Tiendanube, por ejemplo, ya documenta el paso de variant.stock a variant.inventory_levels para stock por ubicación. Shopify también aclara que el inventario por variant puede requerir mirar niveles por ubicación y no solo el total agregado Shopify. O sea: el “stock” no siempre es un numerito único y universal.
En ese terreno, herramientas como Atiendia permiten construir ese asistente conectado al catálogo real de la tienda —con variantes, precios por variante y stock— usando las API keys de la plataforma. Pero incluso con una buena herramienta, alguien tiene que definir la lógica: qué se responde, con qué frescura de dato, y cuándo se deriva a mano humana si la certeza no alcanza.
Ese suele ser el momento en que la automatización deja de ser promesa y pasa a ser operación.
No hace falta prometer demasiado: alcanza con dejar de inventar
En catálogos con variantes, automatizar bien no es hablar más lindo. Es responder con el dato correcto o no pasarse de vivo cuando el dato no está.
La propia NN/g lo plantea desde UX: las variaciones de un producto deberían vivir bajo una sola ficha, como atributos seleccionables. Justamente por eso la combinación correcta importa. No alcanza con saber qué producto es; hay que saber cuál variante es.
Si tu WhatsApp hoy depende de que alguien tenga una pestaña abierta para contestar “¿viene en verde?”, el problema no es de voluntad ni de atención. Es de arquitectura. Y eso se puede ordenar, pero solo si dejás de pedirle al asistente que adivine lo que el sistema ya sabe.