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.

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

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.

Be aware of one real limit. Date fields only match exactly. There is no "in the last 30 days" filter on a date field, so a stored last_order_date cannot by itself produce a "lapsed customers" audience. The workaround — stamping today's date on each order and comparing on the day — is in winning back lapsed customers.

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.