Collect WhatsApp service requests with flows and Data tables

A WhatsApp enquiry becomes easier to follow up when the team has both a clear conversation and a structured service record. Use a message flow to ask the customer for the needed details, then a configured Data action to save them for the team.

Start with a modest process: a customer requests a repair estimate, provides a reference or short description, and receives an acknowledgement while a person reviews the request. This is a request-collection journey, not an automatic promise that the repair is accepted or priced.

Define the request before building the flow

Decide what one record means. For this example, one row represents one repair enquiry. A returning customer can have several enquiries, so their name or phone should not be the unique request identifier.

In Data, prepare a table with the fields the process needs:

Choose actual field types and keys in the table editor. Use required values and uniqueness only where they reflect the process. Create a sample record manually and check validation before asking a flow to write the same structure. See the Data tables guide.

Build a short conversation

1. Open Message flows and create a draft with a greeting that identifies your business and explains what it will collect.
2. Ask for a short description using an input node. Save the answer under a clear variable name and configure validation where you have a defined format.
3. Add the other necessary questions one at a time. Avoid asking for details the team will not use at this stage.
4. Connect invalid-input and timeout outcomes to a helpful retry, ending or human handover.
5. Add Save record, select the prepared table, and set Action to Create a new record. Under Fields, use + Add field to map each required field to the intended answer, such as {{vars.request_description}}, or a configured value. The exact keys must match your table schema.
6. Set Store the saved record in to a clear variable such as saved_request if later steps need it. Connect the saved branch to an acknowledgement, then end or hand the conversation to a person according to the process. Connect invalid, rate_limited and failed to appropriate handling too.

Inspect the Data action's controls and required configuration in your builder. Adding questions alone does not save a record. Likewise, a message saying “request received” is not evidence that a write succeeded.

Handle failures explicitly

Decide what happens if the record cannot be saved, a reference is duplicated or the customer sends an answer that fails validation. Give the person a useful next step and keep the conversation available for review. Do not repeatedly create new requests as a way to recover from an uncertain result.

When updating an existing request, find the exact record first. A phone number may match multiple jobs. Ask for or verify the request reference before changing a particular row, and check the resulting history.

For a first version, keep fulfilment and pricing decisions with a person. Add Approvals only when a configured business decision genuinely needs a named reviewer.

Simulate, assign and test the full journey

Simulate the normal answers, invalid input, silence and human handover. Publish when the design is valid, then select the flow for the WhatsApp account in Accounts → Automations.

Use a controlled customer number to complete the live journey. Confirm the conversation follows the intended account default, a record appears with the right values, and the receiving teammate can open it. Test a duplicate reference and inspect what the customer sees when the save does not complete.

A chat override can change which responder runs. Use the account and chat automation guide if this test conversation behaves differently from the account setting.

Finally, agree who checks New requests and records the next action. A saved row makes work visible; a team owner and follow-up routine turn it into a completed customer request.