Automatización · Pedidos y despacho

Guardar en BigQuery cada pedido que se cierra por WhatsApp

Un agente de IA escribe en tu tabla de BigQuery cada pedido que confirma por WhatsApp, sin SQL libre, revisando antes si ya está y con la fecha del momento.

Quiero verlo con mi operación Ver todas las automatizaciones

¿Cómo llevo a BigQuery los pedidos que cierro por WhatsApp sin exportar las conversaciones a mano?

Un Met conectado a BigQuery con la cuenta de servicio de tu proyecto toma el pedido en la conversación, lee los datos del cliente en su ficha y, antes de escribir, consulta tu tabla para no registrar dos veces lo mismo. Le muestra al cliente el resumen del pedido y, con su confirmación, inserta una fila en la tabla que definiste, con la fecha y hora del momento. No escribe SQL: arma la inserción con las columnas que existen en la tabla, y si declaraste tablas permitidas no toca ninguna otra. Al final etiqueta el contacto y deja una nota. Tu equipo de datos encuentra los pedidos de WhatsApp en la misma bodega donde ya cruza ventas, sin un archivo exportado de por medio.

Qué la pone en marcha

Cuando el cliente escribe

Empieza cuando un cliente confirma un pedido en la conversación de WhatsApp. No hay un trigger que configurar: el Met asignado a la línea escribe la fila dentro de esa conversación, después del sí del cliente.

No hace falta programar nada: el Met asignado al canal recibe la conversación y ejecuta el procedimiento dentro de ella.

Quién la ejecuta

Met de ventas que registra el pedido

Área de Ventas

No tiene nombre propio sembrado: es el Met que ya cierra ventas en el WhatsApp del negocio, con BigQuery conectado. Su trabajo termina cuando el pedido que el cliente confirmó quedó una sola vez en la tabla, con sus columnas reales, y el contacto quedó marcado en el CRM.

Lo ejecuta el Met de cierre de ventas

Canales: WhatsApp

Qué hay que tener conectado

Google BigQuery Investigar y analizar
CRM de Meteor Vender y atender

6 pasos · 7 herramientas

El procedimiento, paso a paso

Cada paso muestra la herramienta que se ejecuta. Son las del conector real: si una dejara de existir, esta página no compilaría.

1
Verificar la conexión y la tabla una sola vez

Al conectar, la prueba de conexión revisa que la cuenta de servicio vea cada tabla permitida. Después, la descripción de la tabla de pedidos dice qué columnas tiene, de qué tipo son y cuáles son obligatorias, sin leer ninguna fila y sin costo de escaneo. Esa lista es la que usa el Met para armar la fila: una columna que no existe se rechaza antes de llegar a BigQuery.
- bigquery_probar_conexion Google BigQuery
- bigquery_describir_tabla Google BigQuery
2
Tomar los datos del cliente de su ficha

El nombre, el teléfono y los campos propios que tu equipo ya guarda salen de la ficha del contacto en el CRM de Meteor, no de lo que el Met recuerde de la conversación. Lo que falte, como la ciudad de entrega, el Met lo pregunta una vez. Así la fila lleva el mismo teléfono con el que tu equipo encuentra al cliente después.
- crm_get_contact CRM de Meteor
3
Consultar la tabla para no registrar dos veces

Antes de escribir, el Met lee la tabla filtrando por columnas, por ejemplo el teléfono del cliente y la fecha del día, y pide solo las columnas que necesita. Si ya hay una fila con el mismo pedido, no escribe otra. Cada lectura trae hasta 1.000 filas y avisa si el resultado quedó recortado, y cada consulta se detiene si fuera a escanear más de 5 GB.
- bigquery_consultar_filas Google BigQuery
4
Confirmar el resumen y escribir la fila

El Met muestra el resumen del pedido, con producto, cantidad, valor y ciudad, y espera el sí del cliente. La inserción se rechaza si no llega con la confirmación en verdadero. Con el sí, escribe una fila en la tabla de pedidos con las columnas que la descripción devolvió, y usa el valor especial de fecha y hora actual para la columna del momento; si esa columna es de fecha o de fecha y hora, se calcula en la zona horaria que elijas. La respuesta dice cuántas filas quedaron insertadas.
- bigquery_insertar_filas Google BigQuery
5
Marcar el contacto y dejar la nota

Con la fila escrita, el Met agrega al contacto una etiqueta que indica que su pedido ya está en la bodega, sin duplicarla si ya la tenía, y deja una nota interna con el resumen del pedido y la tabla donde quedó. Quien abra la conversación después sabe que no hay que registrarlo otra vez.
- crm_add_tag CRM de Meteor
- crm_add_note CRM de Meteor
6
Contestar qué pidió la última vez

Cuando el cliente vuelve y pregunta por su pedido anterior, el Met lee la tabla con su teléfono, ordena por la fecha de forma descendente y pide una sola fila. Responde solo con lo que volvió; si no volvió ninguna fila, lo dice, en vez de inventar un producto o una fecha.
- bigquery_consultar_filas Google BigQuery

Antes de empezar

Qué necesitas tener listo

Ninguno de estos puntos lo resuelve el Met. Si falta uno, la automatización se detiene ahí.

Cuenta de servicio de Google Cloud con su llave JSON

Se crea en la consola de Google Cloud de tu proyecto, se le agrega una llave en formato JSON y el archivo completo se pega en Conexiones de Meteor. Se guarda cifrado y nunca se pide ni se acepta por el chat.
Permisos de consulta y de edición sobre la tabla, con facturación activa

En IAM de Google Cloud la cuenta necesita ejecutar consultas, leer la tabla y editarla para insertar. El sandbox gratuito de BigQuery no permite escribir, así que el proyecto necesita la facturación activa. Las consultas se facturan en tu proyecto.
Una tabla de pedidos que ya existe, con columnas simples

La creas tú en BigQuery con columnas como teléfono, producto, cantidad, valor y fecha. Conviene declararla como tabla permitida al conectar, en formato proyecto.dataset.tabla, para que el Met no pueda tocar otra.

Los límites

Qué NO resuelve esta automatización

Preferimos decirlo aquí que descubrirlo en la implementación.

No crea tablas ni datasets y no cambia columnas. Escribe filas nuevas en una tabla que ya existe; si falta una columna, hay que agregarla en BigQuery.
No corrige ni borra un pedido ya escrito. El conector no actualiza ni elimina filas: un pedido cancelado se registra como una fila nueva o se corrige desde BigQuery.
No suma ni agrupa. Devuelve filas, hasta 1.000 por lectura; las ventas del mes o el ticket promedio se calculan en tu herramienta de análisis, no en la conversación.
No escribe columnas anidadas o repetidas. Trabaja con columnas de un solo valor, como texto, números, fechas, booleanos o JSON.
No es una pasarela de pago ni un sistema de pedidos. Registra lo que el cliente confirmó en el chat; el cobro y el despacho siguen en sus propios sistemas.

Preguntas frecuentes

Preguntas sobre esta automatización

No. El conector no recibe SQL: arma la lectura y la inserción con la tabla, las columnas que existen y los valores como parámetros con tipo. Así ni el Met ni un cliente que escribe algo raro pueden leer otra cosa que la tabla y las columnas que se nombran.

Tu proyecto de Google Cloud, porque corren con tu cuenta de servicio. El tope de 5 GB escaneados por consulta evita que una lectura recorra un dataset entero; en una tabla grande, filtra por la columna de partición y pide menos columnas.

Solo las que la cuenta de servicio puede ver y, si declaraste tablas permitidas, solo esas. Si el Met pide otra, el conector la rechaza y el Met lo explica tal cual, sin buscar un camino alterno.

El Met consulta antes por teléfono y fecha y, si encuentra ese pedido, no escribe una segunda fila. Es una revisión del Met, no una restricción: BigQuery no rechaza filas repetidas y el conector tampoco. Si tu tabla tiene una columna de identificador de pedido, conviene filtrar también por ella: es la forma más segura de que el mismo pedido no quede dos veces.

Sigue por aquí