Write down one complete task
Take a task that someone performs repeatedly: handling an enquiry, assigning field work or preparing a report. Record what starts it, which information the person needs, what they do in each tool and what counts as finished. Include the handoff to the next person.
For example, an enquiry might arrive by email, become a row in a spreadsheet and then become a task in a CRM. The complaint may be “we need a new CRM,” but the actual gap could be a missing connection between the inbox and the existing system.
Find the part that costs attention
Ask the person doing the task to show where they copy information, wait for an answer or check whether a previous step succeeded. Look at a normal case and an exception. A workflow that looks simple on a whiteboard can be difficult because the same customer has three records or because the necessary approval arrives outside the system.
Write the problem in terms of behavior: “the coordinator cannot tell which updates reached the office” is more useful than “the dashboard needs AI.” It gives you something specific to improve and test.
Compare three ways forward
- Configure the existing tool. Check whether a different form, view, permission or workflow rule solves the problem with the data already available.
- Connect the existing tools. If each application serves its users well, a focused integration may remove the repeated work between them.
- Build a custom experience. Consider this when the task needs a different data model, interface or sequence that the existing tools cannot reasonably support.
Compare the whole operating cost, including subscriptions, migration, maintenance and the time the team spends managing exceptions. The smallest build is not necessarily the smallest commitment if it depends on an unreliable source.
Define a first release you can evaluate
Choose one user role and one end-to-end workflow. State which inputs are allowed, what output is expected and how the user sees a failure. If AI prepares part of the result, decide who reviews it and how they can check it against source information.
A first release might accept one request format and prepare a task for approval. It need not automatically process every attachment or write to every connected system. Boundaries make the proposal clearer and help you test whether the approach is useful.
Agree the checks before implementation
Collect representative inputs and the outcomes the team expects. Include a duplicate, an incomplete request and an unavailable connected tool. Define how a person recovers from each case. These checks belong beside the screens and feature list in the scope.
For a custom CRM, that might mean testing the same customer record under different roles. For workflow automation, it might mean proving that a retry does not create a duplicate task. For an AI report generator, it means checking figures against the agreed source.
Bring the constraints into the conversation
Share your current tools, access restrictions, deadline and an approximate budget if you have one. Mention who can approve changes and who will maintain the result. Those details help distinguish a useful first release from work that depends on decisions nobody has made yet.
You do not need a polished requirements document to begin. A short description and a walk-through of the current task are a useful starting point.
Discuss your workflow with 0shot →