Key takeaways
- The biggest red flag in an AI automation vendor is tool-first positioning — they are selling you a platform, not solving your problem.
- Ask for production metrics from live deployments, not pilot results. Pilots succeed because they are controlled; production is where AI systems actually fail.
- A vendor without a governance framework is a vendor selling you liability. Every production AI system needs explainability, auditability, and human oversight design.
- The right engagement starts with a process health check, not a technology recommendation. If they lead with the tool, walk away.
- Evaluate three things before signing: their vertical depth (do they understand your industry?), their production track record (have they shipped and maintained real systems?), and their post-launch model (what happens 6 months after go-live?).
The Market Is Full of People Calling Themselves AI Automation Experts
Since 2023, the number of companies describing themselves as "AI automation agencies" has grown by an order of magnitude. A significant portion of them are developers who learned to use Make or Zapier and added "AI" to their LinkedIn headline. A smaller portion are genuine enterprise software consultancies with production AI deployments and the scar tissue that comes from having systems fail at scale and fixing them.
The difference between these two categories is not always visible in a sales deck. Both will show you impressive workflow diagrams. Both will cite GPT-4 or Claude. Both will promise rapid ROI. This guide gives you the questions, red flags, and evaluation framework to tell them apart before you sign a contract.
The Red Flags That Should End the Conversation
Red Flag 1: Tool-First Positioning
If a vendor leads with the platform — "we are a Make partner," "we specialise in Zapier," "we are a certified n8n agency" — before they understand your business problem, they are selling you a tool, not a solution. A genuine automation consultancy is technology-agnostic: they select the right tool after understanding your requirements, not before. Tool-first vendors optimise for their own margin on the platform relationship, not for your outcome.
Red Flag 2: Only Pilot Results
Pilots succeed because they are controlled. The data is clean, the scope is narrow, the timeline is generous, and the vendor is paying close attention. Production is where AI systems actually reveal their problems: the edge cases, the data quality issues, the integration brittleness, the governance gaps. If a vendor can show you only pilot results and no live production metrics, they have not shipped anything that matters yet.
Red Flag 3: No Governance Framework
Any vendor building AI systems without a governance framework — without addressing explainability, auditability, human oversight design, and data handling — is building you a liability. When the AI system makes an error (and it will), you need to know: who is responsible, what was the audit trail, how was the decision made, and how is it corrected? A vendor who cannot answer these questions before you sign is not equipped to build systems that operate in regulated or high-stakes environments.
Red Flag 4: Offshore Development Shops Rebranded as AI Companies
The combination of offshore development capacity and AI tooling has produced a wave of offshore shops that build workflows cheaply but do not understand the business context, the governance requirements, or the failure modes of AI systems in your specific industry. Cheap to build does not mean cheap to own — the maintenance, debugging, and governance of a poorly designed system costs far more than the initial build.
Red Flag 5: Vague Post-Launch Model
AI systems are not set-and-forget. Models change, APIs change, data quality drifts, business requirements evolve. Ask exactly what the vendor provides after go-live: monitoring, maintenance SLA, model updates, governance reviews. If the answer is "we can support on request," the system will degrade within 6 months without ongoing attention.
The Green Flags That Signal a Serious Partner
- Process-first discovery: They start with a process health check or business requirements analysis before mentioning any technology. The technology recommendation follows the requirements; it does not precede them.
- Vertical depth: They understand your industry's specific constraints — professional liability for legal and accounting, regulatory requirements for financial services, data sovereignty for healthcare. Generic "AI automation" expertise applied to your specific industry without this context is insufficient.
- Production case studies with metrics: Not "we built a workflow for a law firm." Specifically: what was automated, what were the baseline metrics before, what are the metrics now, and how long has it been running. Ask for reference calls.
- Governance by default: They bring up explainability, auditability, human-in-the-loop design, and data handling requirements before you do. If you have to raise these points, the vendor is not senior enough for your needs.
- Named failure modes: A senior practitioner who has built AI systems in production can tell you exactly what has gone wrong in past deployments and how they fixed it. If they cannot name failure modes, they have not shipped enough to know what fails.
- Transparent technology selection: They can articulate why they are recommending a specific platform for your use case, and what the trade-offs are versus alternatives. "We use n8n because it is self-hostable and has native AI agent nodes, which matters for your data sovereignty requirement" is specific. "We use it because it is the best" is not.
The Questions to Ask in Every Discovery Call
| Question | What You Are Testing | A Good Answer Looks Like |
|---|---|---|
| What was the most significant failure in a production AI deployment you have managed, and how did you fix it? | Production experience and intellectual honesty | Specific failure mode, root cause, fix applied, and what changed in their approach as a result |
| How do you handle human oversight requirements for AI systems in regulated industries? | Governance maturity | Specific HITL design patterns, audit logging approach, escalation framework |
| What is your process for selecting automation technology for a new client engagement? | Tool-agnostic vs. tool-first | Requirements-led process with technology selection coming after use case analysis |
| Can you describe a deployment where the first technology choice turned out to be wrong, and what you changed? | Adaptability and production realism | Honest account of a pivot with the reasoning behind it |
| What does your post-launch support model look like for the first 12 months? | Long-term ownership | Specific SLA, monitoring setup, maintenance cadence, and model update process |
| How do you handle our industry's specific compliance requirements? | Vertical depth | Specific knowledge of your regulatory environment without you having to explain it |
How to Evaluate a Proposal Before Signing
A proposal from a serious AI automation firm should contain five components. The absence of any of them is a signal:
- Process analysis: A summary of the specific processes to be automated, the current state (volume, time, error rate), and the expected future state. If the proposal jumps straight to technology, the vendor has not done the analysis.
- Technology rationale: Why these specific tools for this specific use case — including the trade-offs they considered and rejected.
- Governance framework: How human oversight is built in, how errors are handled, how auditability is maintained, and what the data handling model is.
- Success metrics: Specific, measurable outcomes with a baseline and a target — not "improved efficiency" but "document collection time reduced from 4 hours to 45 minutes per engagement."
- Post-launch model: Monitoring, maintenance, model updates, and what triggers a re-engagement. If this section is vague or absent, the vendor's business model depends on you coming back for a rebuild rather than maintaining what they built.
What a Good Engagement Looks Like
The engagement model for a serious AI automation consultancy follows a predictable pattern:
- Discovery (1–2 weeks): Process mapping, stakeholder interviews, data audit, requirements documentation. No technology selected yet.
- Design (1–2 weeks): Architecture proposal, technology selection with rationale, governance framework design, success metrics agreed.
- Build (4–12 weeks depending on scope): Incremental delivery with working automations visible every 2 weeks. No big-bang launches.
- Stabilisation (4 weeks post-go-live): Intensive monitoring, edge case handling, team training. The vendor is highly available.
- Ongoing (12+ months): Monitoring, maintenance, quarterly governance reviews, model updates as AI platforms evolve.
If a vendor proposes skipping discovery or delivering everything at once at the end of a long build, both are signals of misaligned incentives.
Chronexa's engagement model starts with a process health check that produces a prioritised automation roadmap before any technology is selected. You can also explore what this looks like in practice in our use cases for legal, accounting, and financial services clients.
Frequently Asked Questions
How much should AI automation implementation cost?
Scoping varies enormously by complexity, but as a rough benchmark: a single well-defined automation (one process, one integration, clear inputs and outputs) is typically £5,000–£15,000 for design, build, and stabilisation. A multi-process programme covering three or more workflows with AI components is £20,000–£80,000+. Be sceptical of quotes significantly below these ranges for complex AI work — the economics of building good AI systems do not support deep discounting.
Should we hire in-house or use a consultancy?
For a first AI programme, a consultancy is almost always faster and higher-quality than hiring. The learning curve for building production AI systems is steep, and the mistakes made on the way up are expensive. Use a consultancy to build the first system and establish the architecture; use the engagement as a knowledge transfer so your in-house team can maintain and extend it. The worst outcome is hiring a junior developer to build your AI infrastructure from scratch on your timeline.
How do we avoid vendor lock-in?
Two practices: insist on open-source or exportable automation platforms (n8n's open-source core is the gold standard here — you can self-host it regardless of what happens to the vendor), and insist on full documentation and code ownership as a contract deliverable. The workflow code, the prompt library, the integration configurations — all of it should be yours at the end of the engagement, not locked in a proprietary system that only the vendor can access.
What is a realistic timeline to see ROI?
For straightforward, high-volume automations (document collection, billing automation, intake processing), ROI is visible within 60–90 days of go-live. For AI agent deployments with research and drafting components, the quality validation period adds 4–8 weeks before you reduce manual hours with confidence. Full ROI realisation across a multi-process programme is typically 9–18 months.