Saving what a customer tells you, and using it later

A contact field is a named piece of information stored against a customer — their order number, their size, the slot they chose — which any later step or message can read back. Fields are what turn a chatbot from something that asks the same question every time into something that remembers.

There is one rule that catches almost everybody, so it goes first: the field has to exist before a flow can write to it. If it does not, the save step does not fail — it silently does nothing, and the variable you read later comes back empty.

Step 1 — Create the field

1. Go to Settings → Contact Attributes.
2. Click Add Field.
3. Give it a short, lowercase name with no spaces — order_number, preferred_size, delivery_slot. This name is what you type inside {{ }} later, so keep it simple.
4. Pick the type: text, number, date, true/false, or a dropdown list.
5. Save, and make sure it is enabled.

Step 2 — Save the answer

There are two ways to write a field, and one of them is a trap for the unwary.

Way	Use it when	Notes
Save reply to on an Ask Customer a Question step	You are storing the answer to the question you just asked	The right choice almost always. No extra step needed.
Update Customer Attribute step	You are storing something you worked out, not something they typed	Value can be dynamic, e.g. an order total from a store event

The trap is adding an Update Customer Attribute step after a question in order to save that question's answer. You do not need it — the question step has a "save reply to" setting that already does exactly that, and doing both is how flows end up with a step that overwrites the value with a blank.

Step 3 — Read it back

Anywhere a message accepts text, {{contact.order_number}} inserts the stored value. So a later message can say:

"Thanks — I've logged a return for order {{contact.order_number}}."

The same variables work in a Google Sheets step's column values, in an external API call's body, and in an internal note for your team.

A worked example

One answer, three uses: the sheet your ops team works from, the note your colleague reads before replying, and the confirmation the customer sees. That is the whole value of storing rather than just reacting.

Fields versus tags versus memory

	Contact field	Tag	Remember Info
Holds	A value ("42", "Medium")	A yes/no label	A temporary value
Visible on the contact	Yes	Yes	No
Usable in audience filters	Yes	Yes	No
Needs setup first	Yes	Yes	No

Rule of thumb: if you will ever want to message everyone who…, use a field or a tag. If it only matters for the next three steps of this conversation, Remember Info is enough.

What fields can and cannot do for targeting

Fields are what unlock value-based audiences: number fields support "greater than" and "less than", text fields support matching, so a loyalty score or a plan name becomes a segment. That is covered in building audiences with segments.

Date fields are the most useful and the most overlooked. They support relative filters, not just exact matches:

Filter	Means	Use it for
within_last_days	In the last N days	Recent buyers
more_than_days_ago	Longer ago than N days	Lapsed customers
anniversary_today	Same day and month, any year	Birthdays
within_next_days / is_in_days	Coming up	Renewals, expiries
is_on / is_before / is_after	An exact date	Campaign cut-offs

So a stored last_order_date combined with more_than_days_ago: 60 genuinely does produce a lapsed-customer audience. The catch is upstream: nothing fills that field for you. An automation has to stamp it on each order, and the audience only ever knows about orders placed after you switched the stamping on. Winning back lapsed customers covers the setup.

Filling fields from outside a chat

Fields do not only come from questions. A Shopify order event carries the order number, total, city and tracking details, and an Update Customer Attribute step can store any of them. Your own software can also push values in by posting an event with your account API key — the one part of this that needs a developer.

Whichever route fills the field, the same rule applies: define it under Settings → Contact Attributes first, or the write is silently discarded.

A short checklist

1. Field created under Settings → Contact Attributes, and enabled.
2. Name is lowercase, no spaces, and matches what you type in {{contact.…}}.
3. Saving a question's answer uses "save reply to", not a separate step.
4. Every message reading the field is downstream of the step that writes it.
5. Tested in the simulator, where an empty variable is immediately obvious.

That fourth point is worth dwelling on. A variable referenced on a branch that runs before the save step will always be empty, and it is easy to build by accident when a flow has several paths. Walking each path in the simulator catches it in seconds — see testing an automation safely.

Choosing a field type

The type you pick decides what you can do with the value later, and changing it afterwards is more disruptive than getting it right first.

Type	Use for	What it unlocks
Text	Order numbers, item names, free answers	Matching in audiences
Number	Quantities, loyalty scores, order totals	Greater-than and less-than filters
Date	Last order date, birthday, renewal date	Relative filters — in the last N days, more than N days ago, anniversary today
True/false	Flags like "wholesale customer"	Simple splits
Dropdown	A fixed set like size or city	Clean segments with no spelling drift

Two notes worth acting on. Store order numbers as text, not number, or a value like 001042 loses its leading zeros. And prefer a dropdown over free text wherever the answer is one of a known set — "Medium", "medium" and "M" are three different segments if you let customers type.

Where saved values can be used

Once a field holds something, it is available almost everywhere:

• In any message, as {{contact.field_name}}.
• In a Google Sheets step, as a column value to write or a value to match on.
• In an external API call, in the body you send.
• In an internal note, so your team sees it at handover.
• In a broadcast audience, as a segment filter.
• In a calculation, as an input to the Work Out a Number step.

That last one matters for anything with money attached. Save the quantity a customer asks for, then calculate the total with the arithmetic step — never let the AI step produce a number a customer is charged.

The lapsed-customer pattern, properly

This is the most useful thing contact fields do, and it takes two pieces.

1. Create a date field called something like last_order_date under Settings → Contact Attributes.
2. Stamp it on every order. A flow triggered by your store's order event with an Update Customer Attribute step writing today's date.
3. Build the audience with that field and a relative filter — more than 60 days ago, say.

Two honest caveats. The audience only knows about orders placed after you switched the stamping on, so it is worth building early even if you will not use it for months. And nothing populates the field retroactively, so your first win-back campaign is limited to customers who have ordered since. The campaign side is in winning back lapsed customers.

Naming conventions that save you later

Lowercase, no spaces, and describe the thing rather than the flow that captured it — order_number rather than returns_step_2. Fields outlive the flows that write them, and a name tied to one automation is confusing the moment a second one uses it.

Delete fields you stopped using

A contact attributes list full of abandoned experiments makes it harder to pick the right field when building a flow, and easy to reference the wrong one. Prune it when you retire a flow.

Define the field first, always.

Why saving answers lowers what you pay

A field is not only a convenience. Collecting an answer once and reusing it means fewer messages, and fewer messages that have to reach a cold chat.

The distinction matters because of how Meta bills. Messages sent inside an open 24-hour customer service window are free — service conversations have been free and unlimited since 1 November 2024 under Meta's pricing documentation — while a template sent to someone who has not written to you recently is charged.

So a flow that re-asks for an order number it already stored is not just irritating; if the customer has gone quiet in between, that re-ask needs an approved template and costs money. Storing it converts a future charged message into a variable you already have.

There is a second saving. Meta caps templates at 250 per WhatsApp Business Account for an unverified business portfolio and up to 6,000 once verified, per its template documentation. One variabled template driven by contact fields replaces the dozen fixed ones you would otherwise create.