When you design a study, the temptation is to turn everything you want to know into a question. Did they use the feature once or do they use it often? Do fees worry them? Do they use another tool? Seven questions later, the conversation feels like a form and the answers keep getting shorter.
In Boom you don't have to ask everything. There are two ways to get data out of a conversation, and they work very differently.
Guiding questions: the agent asks them
Guiding questions are the topics every conversation has to cover. You write them on the initiative, in the order you want them asked, and the agent decides how to phrase them and when to bring them up. Follow-up depth sets how far it explores after the first answer.
Each guiding question also becomes a variable. When the conversation ends, Boom extracts the answer by its type: text if it's open, yes or no, one of the options you listed, or a number on the scale you set. You don't need to repeat it as a variable: its answer is already in the data.
Variables: nobody asks them
A variable is a field Boom fills by reading the conversation after it ends. The agent doesn't know they exist: it doesn't ask for them and doesn't steer the conversation toward them. The person tells their story and Boom notices what they said.
That makes them the right place for four things:
- A classification of the whole conversation. Whether someone tried something once, uses it often, or stopped. Nobody answers that in one message, but by the end it's clear.
- A flag. Whether they mentioned a bug, a competitor, or asked to talk to a person.
- A list in their own words. What they ask for, the bugs they report, other tools they use.
- Something you shouldn't ask. Which costs are on someone's radar is more honest when they name them without being prompted.
An example
A team wants to understand why people try a new feature once and don't come back. The agent asks three guiding questions: what made you try it, how did the first time go, and what brings you back or what stopped you.
The team also defines five variables that are never asked: usage pattern, reasons for not coming back, costs mentioned, features requested, and whether they asked for someone to follow up.
Someone replies: "I tried it once in March, the fees surprised me and I haven't been back." The third question has its answer. And without anyone asking, usage pattern comes back as "Tried once" and costs mentioned as "Fees".
Variables that actually fill
A variable is worth the share of conversations that fill it. In the studies we've run, fields tied to the central question fill almost every time and side-topic fields almost never do. Four rules make the difference:
- Every variable serves the objective. Side topics rarely come up and only add noise to the report.
- The description is the instruction. Boom reads it to decide what to extract. Write it like a brief: what counts, what doesn't, and what to do when the conversation doesn't say.
- Give it an honest way out. Add "Not clear" to single-choice lists so the model abstains instead of guessing.
- Use the same options the agent offers. If a guiding question tells it to suggest options when someone is stuck, use those same options as the variable's values.
What goes in and what comes out
There's a third thing not to confuse: the context you send about each person when you enroll them, such as their segment or plan. That reaches the agent before the conversation starts, so it can adapt. A good pattern is to send the segment in and extract the same dimension out: you'll see where your segment and the person's story disagree.
Where to find it
Variables are set on the initiative's Data step, under What to extract. Results show up in the data view, insights, exports and the API once each conversation closes. Define your variables before you launch.
The full guide covers variable types and more detail.
