Step 3: Concrete Recommendations
For each workflow at the top of the priority list, we name a specific tool and explain why. Not "use AI." Not "consider workflow automation." A specific tool, with one-line reasoning and a realistic effort estimate. This is where the audit earns its keep.
What we look for
We pick tools based on four things: your team's technical comfort, your existing stack, your budget for both build and maintenance, and your appetite for risk if the automation breaks. The same workflow can have different right answers for different teams. A workflow that calls for n8n at one company calls for a Zapier zap at another, because one company has a developer who's comfortable in JSON and the other doesn't.
The four tool categories we recommend most often: workflow orchestration platforms (n8n self-hosted, or Zapier/Make if you want managed); a small piece of custom code (a Python script in a scheduled job, a serverless function); a native vendor integration (use the integration the vendor already ships, even if it's slightly less flexible); and an LLM-based agent for unstructured-input workflows. We avoid recommending anything more elaborate unless the workflow specifically demands it.
For each recommendation, we write a one-sentence "why this and not the obvious alternative." That sentence is the most important part. A recommendation without it is just a brand mention.
Common mistakes at this stage
Recommending the trendy tool. LLMs are powerful, but they're not always the right tool. If the input is structured and the rule is deterministic, a 30-line script is cheaper, faster, more reliable, and easier to debug. We use LLMs when the input is genuinely unstructured (emails, free-text tickets, documents) and the output benefits from soft judgment. Otherwise we don't.
Recommending a custom build when the vendor ships an integration. If your CRM and your accounting tool already have a native integration, use it. Custom integrations are an ongoing maintenance cost that almost never gets honestly accounted for in the original ROI math.
Skipping the "what to ask a developer" detail. If a recommendation requires technical judgment you can't reasonably make on your own, we say so explicitly, and we include the specific questions you should ask a developer before committing. This part of the deliverable is sometimes more useful than the recommendation itself.
What this step looks like in practice
Each recommended workflow gets a short write-up — typically half a page — with: the recommended approach in a sentence, the alternative we considered and rejected (also in a sentence), an estimated build time range, a maintenance expectation, and the specific questions to ask a developer if you proceed. Where a tool has a free tier that's likely enough for your volume, we say so; where it doesn't, we name the realistic monthly cost.
Where the recommendation depends on a constraint we couldn't verify (e.g., 'this assumes your support volume stays under 5,000 tickets a month'), we name the constraint explicitly. The point is to make it easy to challenge the recommendation if our assumption is wrong, rather than to hide the assumption inside the math.