Understanding Your Deliverables and Workflows So You Can Build AI Around It
The previous article made the case for building structured AI assistants around recurring work rather than relying on fresh prompts every time. If you read it, you probably came away with a reasonable sense of why that matters. The question that tends to follow is a practical one: right, but what do I actually build one for?
That is what this article is about.
Before you can build something useful, you need to see the shape of your work clearly - what you consistently produce, where the structure already is, and where an AI assistant built around your work would actually make a difference. None of that requires new tools or new skills. It requires a slightly different lens on the work you are already doing.
TL;DR
Most professionals produce more than they realise - not just documents, but any repeatable output their work generates. Seeing those outputs clearly, and understanding the structure underneath them, is the first step to knowing what is worth building an AI assistant around. A simple five-part lens - trigger, inputs, steps, rules, output - makes that structure visible. Combine that with a quick audit of your recent work and your recent AI usage, and the picture tends to become fairly clear.
What "deliverables" actually means
The word deliverable tends to make people think of formal outputs - a report, a proposal, a finished document. Something with a cover page or a send date.
That framing is too narrow to be useful here.
A deliverable, for the purpose of thinking about AI, is any repeatable output your work produces. It does not matter whether it is long or short, polished or rough, client-facing or internal. What matters is that it recurs - the same kind of thing, produced the same way, more than once.
That includes onboarding packs for new clients. Weekly update emails. Research summaries before a call. Responses to a certain type of enquiry. Meeting follow-up notes. Social media posts that follow the same structure each time. The brief you write at the start of every project.
When you start looking at your work through this lens, the list tends to be longer than expected. Most of it has been invisible because it feels routine - not significant enough to think of as a deliverable, even though it takes time and thought each time you do it.
The workflow lens: making the structure visible
Recurring outputs do not arrive fully formed. There is a pattern underneath each one - a sequence of steps, specific inputs, particular rules about what good looks like. Most of the time that pattern lives in your head, not on paper. But it is there.
A simple five-part lens helps make it visible:
- Trigger - what sets the work in motion? A specific event, a request, a date, a signal from somewhere?
- Inputs - what does the work draw on? Information, context, reference material, the work of others?
- Steps - what actually happens, in what order?
- Rules and guardrails - what makes this output good rather than just done? What would make it wrong?
- Output - what does it produce, in what form?
You do not need to complete a formal document for this. The point is to see the structure that already exists in work you already do well. Most of the time, if you slow down and walk through a recurring task with this lens, the pattern becomes clear fairly quickly.
An assistant built around that structure - given the inputs it needs, the steps to follow, and the rules about what good looks like - will produce something more consistent and more useful than one working from a blank prompt. The AI benefits from the same clarity anyone would benefit from if they were stepping in to help with your work.
Where to look
There are two useful places to audit.
The first is your recent work. Look back at what you have produced over the last few weeks. What appeared more than once? Not identical outputs - recurring types. If you wrote five different follow-up emails after five different calls, those are five instances of the same workflow. If you produced three client summaries, the same logic applies. The repetition is the signal.
The second is your recent AI usage. What have you kept asking AI to help with? If you notice the same kind of task appearing repeatedly in your conversations, that pattern is telling you something. You already know that task could benefit from AI support. You are just not yet working with a consistent structure around it.
Both audits tend to surface the same handful of tasks. When the same thing comes up in both, that is a reasonable place to focus.
Separating one-off tasks from repeatable workflows
Not everything that recurs is worth building a structured assistant around. Before you spend time on it, it is worth asking a few questions.
Does it happen regularly enough to be worth structuring? A task that comes up twice a year probably does not justify the same investment as one that comes up twice a week.
Does it have reasonably clear inputs and a reasonably clear output? If the answer varies significantly depending on context, or the definition of done shifts each time, the structure is harder to define - and harder to build around.
Is it low-risk enough to test? Some work is better kept close, at least initially. Anything where an off-note output could damage a client relationship or cause a real problem is worth treating carefully. That does not mean avoiding it - it means starting with a version that keeps a human in the loop to evaluate the output before it goes anywhere.
The workflows worth building around tend to share a few qualities: they recur, they have defined inputs and outputs, the structure is stable even when the content varies, and the main reason they are being done manually is that no one has set them up to run any other way yet.
What this makes possible
The previous article was about why structured assistants matter - how AI becomes far more useful when you stop asking it fresh questions and start building consistent support around the work that keeps recurring.
This article is the practical step before that: seeing what in your work is actually ready for that treatment.
You cannot build something useful around a vague task. You can build something genuinely useful around a task where you know the trigger, the inputs, the steps, the guardrails, and what the output should look like. That structure already exists in the work you do well. The audit is just a way of making it explicit.
Once you can see the shape of a workflow clearly, you have something real to build around. That is where the next part of this starts.
If you want to work through this for your own business - identify which workflows are worth structuring and what building an assistant around them would look like in practice - I am happy to talk it through.
