Asking well is the work

The problem it solves

The most common complaint after trying an AI tool is that it "gives generic answers". That is usually true, and usually the correct answer to what was asked: with no context, no reader, no format and no limits, generic is the only thing available. So the output gets rewritten by hand, someone decides it is quicker to write it themselves, and the tool is left for trivial jobs while everyone uses it their own way.

Underneath sits a habit the company brought with it. Briefing badly is not a new problem: the same thing happens when you ask a person for something without saying who it is for, by when, how long it should be, and what it must not include. The tool only makes it obvious faster.

And there is a second, more serious problem almost nobody addresses: what gets checked before the output is used, and what information must not leave the company in order to produce it. Without a written standard, a figure the system stated with complete confidence ends up in a proposal, and client data is pasted into an external tool nobody approved. Left as it is, the company drifts to one of two extremes: it bans the tool and use carries on out of sight, or it tolerates use without rules until a mistake in front of a client sets the policy in a hurry.

What it covers

The workshop is hands-on and works from participants' real briefs: a difficult email, a meeting summary, a draft procedure, a job description. The angle is deliberate. This is not about phrasing tricks that change with every version of a tool, but about the professional discipline of briefing and reviewing, which works the same way with any system, and with a person too. Cases are brought in without client data or confidential figures, and that precaution is already the first practice of the standard the session ends up setting.

The first part builds the structure of a professional brief: who the reader is, what context has to be supplied, what format and length are expected, what tone, and what must not appear. Before and after are compared on the same case, which is the only way the difference gets seen rather than explained. Then comes the step almost nobody takes: improving a weak result by iterating on it and naming what went wrong, instead of throwing it away and starting over. Briefs for tasks that recur are written up so they can be used again.

The second part is what separates casual use from professional use. What is always verified before an output is used, with particular attention to data and figures a system can assert with complete confidence and no basis. And what company or client information is never handed to an external system, expressed as a written standard the team can apply without asking each time. Working in pairs, each participant reviews someone else's output against the checklist the group has just built, and the doubtful cases are argued through until the standard on what stays inside reads clearly to someone who was not in the room.

Each participant leaves with their own cases rewritten and the contrast in plain view, a first set of briefs ready for the tasks they repeat, a check they run before trusting any output, and the written standard on what never leaves the company. Of the four, the standard carries the most weight, because it is what has to exist before usage spreads to more people. In ALUD's Technology engine, a written rule on what gets checked and what information stays inside the company comes before any conversation about systems.

What participants learn

• Structure a brief with reader, context, format, tone and limits.
• Improve a weak result by iterating rather than discarding it.
• Verify an output before use, starting with data and figures.
• Apply a written standard on what information never leaves the company.
• Build reusable briefs for the tasks that repeat.

Agenda

1. 01Why a generic result is usually the right answer to a poor brief
2. 02Reader, context, format, tone and limits
3. 03Iterating a result rather than discarding it
4. 04Reusable briefs for repeated tasks
5. 05Verification: what is always checked before use
6. 06Confident assertions with no basis, and how to catch them
7. 07What information is never handed to an external system
8. 08Setting a usage standard the team can apply on its own

What the organization leaves with

• A starting library of reusable briefs from your own work.
• A pre-use verification checklist.
• A written standard on what information never leaves the company.
• Your own cases rewritten, with before and after side by side.