Automation · Orders and fulfillment

Store every order closed over WhatsApp in BigQuery

An AI agent writes each WhatsApp order into your BigQuery table, with no free SQL, checking first that it is not already there and with the current timestamp.

Show me this with my own operation See every automation

How do I get the orders I close over WhatsApp into BigQuery without exporting chats by hand?

A Met connected to BigQuery with your project's service account takes the order in the conversation, reads the customer's details from their contact record and, before writing, checks your table so the same order is not stored twice. It shows the customer the order summary and, with their confirmation, inserts one row into the table you defined, with the date and time of the moment. It does not write SQL: it builds the insert from the columns that exist in the table, and if you declared allowed tables it touches no other. Finally it tags the contact and leaves a note. Your data team finds WhatsApp orders in the same warehouse where it already joins sales, with no exported file in between.

What starts it

When the customer writes

It starts when a customer confirms an order in the WhatsApp conversation. There is no trigger to set up: the Met assigned to the line writes the row inside that conversation, after the customer's yes.

Nothing to set up. The Met assigned to that channel picks up the conversation and runs the procedure inside it.

Who runs it

Sales Met that records the order

Sales team

This is not a named, seeded Met. It is the Met that already closes sales on the business's WhatsApp, with BigQuery connected. Its work ends when the order the customer confirmed is in the table exactly once, with its real columns, and the contact is marked in the CRM.

Run by the sales closing Met

Channels: WhatsApp

What you need connected

Google BigQuery Research and analyze
Meteor CRM Sell and serve

6 steps · 7 tools

The procedure, step by step

Each step shows the tool that runs. They belong to the real connector: if one of them stopped existing, this page would not build.

1
Check the connection and the table once

When connecting, the connection test checks that the service account can see each allowed table. Then the table description lists its columns, their type and which ones are required, without reading a single row and with no scanning cost. That list is what the Met uses to build the row: a column that does not exist is rejected before it reaches BigQuery.
- bigquery_probar_conexion Google BigQuery
- bigquery_describir_tabla Google BigQuery
2
Take the customer's details from their record

The name, the phone and the custom fields your team already stores come from the contact record in the Meteor CRM, not from what the Met remembers of the conversation. Anything missing, such as the delivery city, the Met asks once. That way the row carries the same phone your team uses to find the customer later.
- crm_get_contact Meteor CRM
3
Check the table so nothing is stored twice

Before writing, the Met reads the table with column filters, for example the customer's phone and today's date, and asks only for the columns it needs. If a row for the same order is already there, it does not write another. Each read returns up to 1,000 rows and flags a truncated result, and each query stops if it would scan more than 5 GB.
- bigquery_consultar_filas Google BigQuery
4
Confirm the summary and write the row

The Met shows the order summary, with product, quantity, amount and city, and waits for the customer's yes. The insert is rejected unless the confirmation arrives as true. With the yes, it writes one row into the orders table using the columns the description returned, and uses the special current date and time value for the timestamp column; if that column is a date or a datetime, it is computed in the time zone you choose. The response says how many rows were inserted.
- bigquery_insertar_filas Google BigQuery
5
Tag the contact and leave the note

With the row written, the Met adds a tag to the contact showing that the order is already in the warehouse, without duplicating it if it was there, and leaves an internal note with the order summary and the table where it landed. Whoever opens the conversation later knows it does not need to be recorded again.
- crm_add_tag Meteor CRM
- crm_add_note Meteor CRM
6
Answer what they ordered last time

When the customer comes back and asks about a previous order, the Met reads the table by their phone, sorts by date in descending order and asks for a single row. It answers only with what came back; if no row came back, it says so instead of making up a product or a date.
- bigquery_consultar_filas Google BigQuery

Before you start

What you need ready

The Met solves none of these for you. If one is missing, the automation stops there.

A Google Cloud service account with its JSON key

You create it in your project's Google Cloud console, add a JSON key and paste the whole file into Connections in Meteor. It is stored encrypted and is never requested or accepted through the chat.
Query and edit permissions on the table, with billing enabled

In Google Cloud IAM the account needs to run queries, read the table and edit it to insert. The free BigQuery sandbox does not allow writes, so the project needs billing enabled. Queries are billed to your project.
An orders table that already exists, with simple columns

You create it in BigQuery with columns such as phone, product, quantity, amount and date. It is worth declaring it as an allowed table when connecting, as project.dataset.table, so the Met cannot touch any other.

The limits

What this automation does NOT solve

Better said here than discovered halfway through the rollout.

It does not create tables or datasets and does not change columns. It writes new rows into a table that already exists; if a column is missing, it has to be added in BigQuery.
It does not correct or delete an order already written. The connector does not update or delete rows: a cancelled order is recorded as a new row or fixed from BigQuery.
It does not sum or group. It returns rows, up to 1,000 per read; monthly sales or average ticket are computed in your analytics tool, not in the conversation.
It does not write nested or repeated columns. It works with single value columns such as text, numbers, dates, booleans or JSON.
It is not a payment gateway or an order system. It records what the customer confirmed in the chat; payment and shipping stay in their own systems.

FAQ

Questions about this automation

No. The connector does not accept SQL: it builds reads and inserts from the table, the columns that exist and the values as typed parameters. That way neither the Met nor a customer typing something odd can read anything other than the named table and columns.

Your Google Cloud project, because they run with your service account. The 5 GB scan cap per query stops a read from sweeping an entire dataset; on a large table, filter by the partition column and request fewer columns.

Only the ones the service account can see and, if you declared allowed tables, only those. If the Met asks for another, the connector refuses and the Met explains it as is, without looking for a workaround.

The Met checks first by phone and date and, if it finds that order, does not write a second row. It is a check the Met makes, not a constraint: BigQuery does not reject repeated rows and neither does the connector. If your table has an order id column, it is worth filtering by it too: that is the safest way to keep the same order from appearing twice.

Keep going