Identify the decision and the user

Here is a typical work request. We will use it throughout this course as the supplied service-improvement scenario:

"Customers keep complaining about how long refunds take. Can you look at the refund process and put something together before the ops review on 14 March? We need to stay within the current team, so no new hires this year." Priya, Head of Customer Operations

It is tempting to paste this into an AI assistant and ask for a report. You would get something polished in seconds. But a polished answer is not useful if it answers the wrong question. Does Priya want a list of causes? A recommended fix? A one-page note for the review? The AI doesn't know, and neither do you yet.

A common failure in professional work is producing a polished answer before deciding what the requester needs. The fix is simple: clarify the need first, then draft.

In this lesson you will turn a request like Priya's into a short working statement. That is a few lines naming the decision, the user, the scope and the constraints. It becomes the base for every prompt you write later.

You can practise with Priya's refund request or with a real example from your own role. A real example makes the practice more useful, but only if you are allowed to use it.

Permitted here means your organisation, and your client if there is one, allows that material to be shared with an AI tool. Before you paste anything, check two kinds of content:

• Client-confidential records: contracts, client data, internal client documents, pricing.
• Employee information: anything about named people's performance, pay, health or HR matters.

Keep both out unless you have approval. Removing names does not automatically make material safe. Details can still identify a person or a client, so follow your organisation's policy.

Example: you want to use a client's complaint log. It contains customer names and account details, and you have no approval to share it. Use Priya's scenario instead, or describe your own situation in general terms with no client or employee details.

If you are unsure at any point, use the supplied scenario. You lose nothing, because the method is the same.

Every useful work request supports a decision, a choice someone has to make after reading your work. If you can't name it, you can't judge what a good output looks like.

Common decisions include:

• whether to proceed with a change
• which option to pursue
• what to raise with a client

Try to write the decision as one sentence, often starting with whether, which or what.

For Priya's request, a reasonable reading is: "Which change to the refund process, if any, should we pursue within the current team?"

Notice that Priya never said this. She said "look at the refund process and put something together". The decision sentence is your best interpretation, so treat it as a draft to confirm with her. She might instead want to decide whether the problem is serious enough to raise at the review at all. That would need a different output.

Naming the decision early gives you something concrete to check with the requester. It is much easier for Priya to say "yes, that's it" or "no, I mean this" than to describe her need from scratch.

The user is the person who will read your output and act on it. This may be the requester or someone else. Ask three questions:

1. Who reads it?
2. What do they already know?
3. What will they do with it?

The answers change what a good output looks like. A manager approving budget needs the cost, the options and a clear recommendation, kept short. A team member doing the work needs steps, details and who to ask when stuck.

In Priya's case, she knows refund complaints are a problem, so she doesn't need that explained. But her request mentions the ops review. If your output will be shown to other managers there, they may not know the background. Then they are users too, and the output must make sense to them.

You don't know yet whether others will see it. That is something to ask, not to guess. For now, write: "User: Priya (confirmed). Possibly other ops review attendees (to confirm)."

Two more parts complete the picture.

• Scope says what is in and what is out. For example: the refund process is in, but the returns policy is out.
• Constraints are limits on the work, such as time, budget, people or policy.

The rule is strict: write down only what the request or the requester actually states.

Priya stated:

• Scope: the refund process.
• Time constraint: before the ops review on 14 March.
• People constraint: no new hires this year.

She did not state whether the refund page on the website is in scope. She did not mention a budget for new software, or whether she wants one recommendation or several options.

Anything you are guessing about the decision, user, scope or constraints is an assumption. Mark it clearly, for example "[Assumption] Website refund page is out of scope". That way it can be confirmed later rather than quietly built into your work. An unmarked guess tends to become an "agreed requirement" that nobody actually agreed to.

An AI assistant can help you clarify a request, not just answer it. Instead of asking for a finished report, ask it to list what is unclear. This tends to surface gaps earlier.

A prompt you could use:

"Here is a work request from my manager: [paste request]. Don't draft anything yet. List the questions I should answer or ask her before I start. Group them under decision, user, scope and constraints."

For Priya's request, the AI might suggest questions like "Does she want a recommendation or a set of options?" or "Will the output be shared at the ops review?"

You still have to judge the list. Some questions will be useful, some generic, and some may assume things about your organisation that aren't true. Keep the useful ones and answer what you can from the request itself. Turn the rest into questions for the requester or marked assumptions.

Only paste material you are permitted to share, as covered earlier.

Now put it together. A working statement is a short, plain record of what you know and what you are guessing. It uses five lines:

• Decision: one sentence
• User: who reads it, what they know, what they will do
• Scope: what is in and what is out
• Constraints: time, budget, people, policy
• Assumptions to confirm: every guess, clearly marked

For Priya's request:

• Decision: Which change to the refund process, if any, to pursue within the current team. (To confirm)
• User: Priya, who knows the complaints and will decide what to take to the ops review. Possibly other attendees. (To confirm)
• Scope: In: the refund process. Out: not yet stated.
• Constraints: Ready before 14 March. No new hires this year.
• Assumptions to confirm: She wants one recommendation. Website refund page is out of scope. No software budget.

This takes a few minutes and gives you something Priya can check in one reply. In the next lesson, you will summarise the evidence that supports this decision.