A useful starting point is one recurring piece of work. Describe what happens now before choosing the technology that might change it.
This is the preparation method Mainstreet uses to keep an AI opportunity tied to an observable job. You can use it yourself, with your team or as a brief for someone helping you.
Start with a trigger and a result
Write a sentence that names what starts the work, who does it and what should come out at the end.
Example: When a customer meeting ends, our account manager turns the notes into follow-ups and updates the CRM.
This is an illustrative workflow, not a claim about a client result. It gives you something concrete to observe: the meeting, the notes, the account manager and the expected follow-through.
Make the handoffs visible
List the main steps in the order they happen. For each step, name the information needed, the system used and the person responsible.
| What to capture | Questions to answer |
|---|---|
| Trigger | What starts the work? |
| Input | Which notes, records, messages or documents are needed? |
| Main steps | What does a person do with that information? |
| Exceptions | What makes a case unusual, incomplete or difficult? |
| Review | Who can check the result before it affects someone? |
| Output | What should exist when the work is complete? |
| Owner | Who is responsible for running it and handling exceptions? |
Keep the map small enough that the people doing the work can correct it. If the steps change substantially each time, identify the stable core before evaluating automation.
Collect examples before writing a specification
Bring together a small set of real examples, including unusual cases. Remove information you are not authorized to share.
Describe an acceptable result for each example. In the meeting workflow, the team might check whether a draft includes the agreed actions, names the right owners and carries unresolved questions forward. Those checks can become the acceptance tests for an implementation.
Check what your existing tools already do
A tested product that handles the workflow end to end may be a Buy. If material configuration, connections or AI-assisted steps remain, the direction may be Build. If the work has little value, lacks a stable core or cannot be reviewed safely, Skip may be the useful decision for now.
Not having researched products is different from having tested them and found a gap. Compare relevant products before commissioning work that they may already handle.
Leave yourself a one-page brief
Use these prompts to put the work in one place:
- The workflow: from trigger to intended result.
- Why it matters: frequency, consequence and the problem with the current process.
- What happens now: people, information, systems and handoffs.
- Real examples: normal cases and exceptions.
- What good looks like: the checks an acceptable result must pass.
- Review and ownership: who approves the output and who runs the workflow.
- What is still unknown: product fit, access, dependencies and implementation effort.
You now have a useful basis for a product test, a team session or an implementation conversation. It is still a starting brief: security, access and feasibility need checking before implementation.
Choose the next useful action
Try the Build, Buy or Skip worksheet with the workflow you have mapped. It will give you a first-pass direction and identify what needs checking.
If you want outside help comparing opportunities, an AI Opportunity Review considers up to three candidate processes and leaves you with decisions and a brief for the first justified action.