Capturing user intent for AI workflows with two questions

Why free text creates bad starts

Free text feels easy. For AI workflows, it often creates a bad starting point.

People type what is in their head: part goal, part context, part urgency, and a few unstated preferences. The system then has to guess what matters most. That is where a lot of workflows go wrong.

A request like "make this into a summary" hides several decisions. Who is it for? A busy manager, a client, or an internal team? Should the output be five bullets, a short paragraph, or a one page note? When those choices stay unstated, the model fills the gaps on its own.

Sometimes the result sounds polished and still misses the job. The model may write a friendly email when the user needed a firm follow-up. It may turn meeting notes into a long report when three action items would have done the job. It may summarize a document correctly and still leave out the deadline, risk, or decision that mattered most.

Format creates the same problem. If the prompt does not say "table," "bullet list," "draft email," or "short report," the model picks a format on its own. That choice changes the result. A casual paragraph and a board update will not include the same details, even when both come from the same source.

You can see it in everyday prompts:

• "Summarize this" can mean shorten it, pull out decisions, or rewrite it for a different audience.
• "Draft an email" can mean polite, direct, urgent, sales focused, or purely informational.
• "Make a report" can mean a quick status update or a document with sections, numbers, and next steps.

Structured intake questions fix this before the workflow starts. They pull the real goal out of messy language early. That is the job in capturing user intent for AI workflows: stop the system from guessing and give it enough direction to get useful output on the first try.

What to ask before the workflow begins

Many AI workflows fail early because they start with one large text box. Two short questions usually work better.

The first question should ask for the result. Not the topic, and not a rough idea. Ask what the person wants to walk away with. "Help me with hiring" is vague. "Create a 5 question interview scorecard for a backend engineer" gives the workflow a clear target.

The second question should ask for the shape of the answer. This matters more than many teams expect. A person may want the same information as a checklist, a short email, a JSON object, or a one page brief. If you skip this, the system may produce something correct and still make extra work.

A simple pair often works well:

• What result do you want?
• What format should the answer use?

That is enough for many cases. People can answer fast, and the workflow gets the two decisions that most often change the output.

Add limits only when they change the result. If length, tone, audience, legal boundaries, or required fields will change what the system produces, ask for them. If they only affect polish, use defaults. Every extra field gives people one more reason to hesitate, skip the form, or dump messy text into the first box.

Short wording matters. People scan forms. They do not study them. Use plain language, keep each question to one line when you can, and avoid stacking examples inside the question itself. If a field needs help, put one brief example under it.

This is easy to test. Compare a workflow that starts with "Describe what you need" against one that asks for the result and format first. The second version usually leads to fewer retries, less cleanup, and better prompt scoping.

If you remember one rule, make it this: ask for the outcome first, the format second, and constraints only when they truly change the job.

When one question is enough and when two help

If the task has one clear path, ask one question and move on. A narrow task does not need a long intake form. If someone wants a meeting summary, a bug report draft, or a clean list of action items, the system often needs only one thing: the goal.

One question works best when the workflow stays fixed after that answer. An internal tool might ask, "What do you need done?" and offer choices such as "summarize notes," "draft reply," or "extract tasks." That single choice gives the AI enough direction to start cleanly.

Add a second question when the same task can lead to very different outputs. This usually happens when audience, format, or level of detail changes the result. A founder may ask for a product update, but the right version for investors will not read like the right version for engineers.

A simple pair covers most cases: first ask what the person is trying to do, then ask who it is for or what format they want. The first answer sets the job. The second shapes the output.

Long forms slow people down. They also make answers worse. If you ask five questions before showing any result, many users will rush through them or dump vague text into the first box just to get past it.

Use answer choices when you can. Choices reduce guesswork and keep wording consistent. They also make routing easier inside the workflow. Instead of handling ten versions of "make this shorter," the system can map "summary" to one path and "email" to another.

A simple test helps. If changing the first answer should send the request down a different workflow, keep that question. If changing the second answer only changes audience, format, or length, keep it as the second question. If a question does not change the output in a clear way, remove it.

How to write the questions

Good intake questions start with the business task. If you begin with model settings, tone, or output style, you ask the user to think like a system designer. Most people cannot do that clearly, and they should not have to.

A founder usually knows whether they need bug triage, a feature spec, or a cost estimate. They do not know which prompt pattern or model setting should handle it. Ask about the task first. Let the workflow deal with the rest.

Vague words cause drift. Words like "better," "urgent," or "detailed" mean different things to different people. Replace them with choices that point to a different output.

For example:

• Instead of "How detailed should this be?" ask "Do you want a 5 bullet summary or a full plan?"
• Instead of "Is this urgent?" ask "Do you need an answer today, this week, or when time allows?"
• Instead of "What kind of help do you need?" ask "Do you need a diagnosis, a draft, or a recommendation?"

Choices beat empty text boxes because they reduce guesswork. They also make intent easier to review later. If you want to improve the flow over time, fixed choices give you something you can measure.

Defaults help more than many teams expect. If most requests need the same format, set that as the default and let the user change it only when needed. Good defaults lower effort and keep the intake short.

Test the wording with someone outside the team. Pick a coworker from sales, support, or operations and watch how they answer without coaching. If they pause, ask what a word means, or choose the wrong option for a normal request, the question needs work.

Be strict about removing questions. Every question should change routing, output shape, or priority. If the answer does not affect what the workflow does next, delete it.

A good test is simple: if two different answers lead to the same result, the question stays out.

A simple setup process

A simple setup beats a clever prompt. If you want better results from AI, start by listing the decisions the workflow must make before it can do useful work. In most cases, that means choices such as goal, audience, format, urgency, or level of detail.

Write those decisions in plain language. Skip technical labels. If someone on your team cannot explain a choice in one short sentence, users will struggle with it too.

Next, decide which choices belong to the user and which ones the system should handle on its own. Users should control the parts that reflect intent. The workflow should keep routine logic in the background. A content workflow may need to ask for the target audience, for example, but it does not need to ask whether it should save the result in the right folder.

A practical first pass looks like this:

1. List every decision that changes the final result.
2. Remove the choices the system can make safely every time.
3. Keep only the decisions users truly need to control.
4. Turn those decisions into one or two short questions.
5. Match each answer to a specific branch, template, or next action.

That last step matters more than it looks. If an answer does not change what happens next, do not ask for it.

Then test the setup with real requests. Pull a small batch from support tickets, Slack messages, sales notes, or forms. Watch where people hesitate, ignore the options, or type long explanations into a short field. Those are signs that the question is too vague or asks for the wrong thing.

Small edits fix a lot. Change "What do you need?" to "Which result do you want?" Replace open text with a short menu when the choices are known. Add a second question only when it changes the next step. If it does not, cut it.

That is usually enough to get a messy workflow under control quickly.

A realistic example

Imagine a support team that gets a steady stream of customer messages. Some ask for refunds, some report bugs, and some cannot get into their accounts. If the team gives an AI tool one large text box and hopes it figures things out, the tool has to guess too much.

A simple intake step fixes that. Before the workflow starts, the form asks two short questions. The first asks for the user's goal: "What do you need help with?" The second asks for the reply format: "How should we respond?"

The first answer can offer a few clear choices such as "Refund," "Bug report," "Account access," and "Something else." The second answer keeps the output usable for the team. It can ask whether the person wants a short customer reply, a troubleshooting message, or an internal summary for a human agent.

Those two answers change the workflow right away. If the user picks "Refund," the AI checks order details, looks for the return window, and drafts a calm reply that explains the next step. If the user picks "Bug report," the AI asks for device, browser, and what happened just before the issue. It can also turn that into a clean ticket for engineering. If the user picks "Account access," the AI shifts toward identity checks, login steps, and account recovery rules.

Reply format matters just as much. A refund request with "short customer reply" produces a concise message the agent can send fast. The same request with "internal summary" gives the team a note with policy checks, risk flags, and what to verify before approving anything.

Now compare that with one free text box. A customer writes, "I got charged, the app froze, and now I can't log in, please fix this today." That message mixes three issues, emotion, and urgency. The AI may focus on the wrong part, ask weak follow-up questions, or draft a reply that feels off.

Structured intake questions do not make the workflow rigid. They give it a clean starting point. That small change improves user input quality, cuts rework for the team, and makes prompt scoping much easier.

Mistakes that derail intent capture

Most failures happen before the model does anything. The intake step looks small, so teams treat it like a formality. Then they ask vague questions, collect random details, and hope the system figures out the rest.

The fastest way to break the flow is to ask something like "What do you need?" It sounds friendly, but it pushes all the work onto the user. People answer with a paragraph, a half formed idea, or three goals at once. The workflow then has to guess what matters.

Another common mistake is asking for data the workflow never uses. If the system only needs a goal and an output format, do not also ask for team size, industry, urgency, or preferred tone unless those fields change what happens next. Extra questions make people slower and less careful.

Tiny helper text causes trouble too. If the workflow has limits, say them in the question itself. Do not hide rules such as word count, supported file types, or unsupported tasks in faint text below the field. Many users will miss it, and the system will start from a bad request.

Internal language is another trap. Users should not need to know your labels, stages, or taxonomy to answer a simple question. If your team says "brief type" and "execution mode," but users think in terms like "blog post" or "draft email," use the words users already know.

Too many answer options can be just as bad as an open text box. A long menu makes people scan, hesitate, and pick the closest thing rather than the right thing.

A cleaner intake follows two rules: ask only for details that change the next step, and use plain words that match how users already describe the task.

If a person can answer in under ten seconds, you are probably close. If they need to decode labels, read footnotes, or skip half the form, the workflow will start with noise instead of intent.

A quick review before launch

A short intake step works only if people can answer it fast and the system can use the answer right away. That is the last check before launch.

If someone pauses for more than ten seconds, the wording is probably too vague, too abstract, or asking for details they do not have yet. Speed matters because slow questions push people back into messy free text.

A good review is simple:

• Time the first answer. If it takes too long, shorten the question or replace open text with clear options.
• Check whether each answer changes what happens next. If the workflow takes the same path either way, remove the question.
• Ask two team members to explain what a sample answer means. If they disagree, the label is too loose.
• Look at the default choice. It should fit the most common case so users can move fast.
• Try a bad input on purpose. The workflow should catch missing intent before it starts the real work.

Labels cause trouble more often than teams expect. Words like "simple," "urgent," or "high quality" sound clear, but people read them differently. Fixed choices work better when they map to a real action, such as "draft," "review," or "final version." Then the system can route work, set effort, or ask one follow-up only when needed.

Defaults matter more than many teams expect. If most requests need the same output format or approval level, make that the default. Users should touch the question only when their case is different.

One last check matters a lot: can the workflow spot a gap before it runs? If the user chooses "customer reply" but never names the customer issue, stop and ask for that detail. Catching the gap early is much cheaper than letting the AI guess and produce the wrong result.

Next steps

Start small. Pick one workflow where people often send vague requests and the system has to guess what they meant. That is usually the best place to improve intent capture because the pain is already obvious.

Draft two short questions for that workflow and test them against real requests from the last few weeks. Keep the wording plain. If a person needs more than a few seconds to answer, the question is too broad.

A practical first pass is simple: ask what outcome the person wants, ask for the one constraint that matters most, compare the answers with the original free text, and note where the system still needs follow-up.

That comparison tells you a lot. If users keep adding side notes like "for our sales team only" or "use last month's data," your questions still miss something practical. Those notes show you where confusion survives.

Do not add more automation yet. Fix the intake first. A weak form sends bad inputs deeper into the workflow, where errors get harder to spot and more annoying to correct.

One small round of testing is usually enough to find the weak spots. You may notice that one question pulls in most of the useful detail while the second question clears up edge cases. Or you may find that both questions are still too abstract and need concrete answer choices.

What to do after the first test

Refine the form, run another batch of real requests, and check the same trouble spots again. Look for fewer clarifying notes, fewer manual corrections, and faster starts. If those numbers do not improve, rewrite the questions instead of stacking more rules on top.

If you want a second opinion, Oleg Sotnikov at oleg.is works with startups and smaller teams on AI first development, workflow design, and Fractional CTO support. A short outside review can save a lot of time when the real problem sits in the intake step, not in the prompt.