Most companies that ask us about implementing AI start the conversation the same way: “We want to deploy an AI agent for customer service / invoicing / HR. Where do we start?”
That’s a good question. The problem usually shows up before anyone gets to answer it, when the next sentence is: “We saw a demo of tool X — maybe we should just deploy that.”
And that’s where most AI automation projects go wrong before they’ve even started.
The tool isn’t the starting point. The process is. Companies that begin by choosing a platform instead of defining a problem end up with a well-configured tool doing the wrong thing — or doing the right thing, but at a cost that no longer makes sense.
Mistake number one: starting with the tool, not the process
The AI tooling market grows faster than most companies’ ability to evaluate it. Make, n8n, LangChain, AutoGen, Microsoft Copilot Studio, custom LLM builds — each has its advocates, and each solves different problems.
None of them will tell you which process is worth automating.
The right sequence looks like this:
- Identify the process with the highest volume of repetitive tasks and a measurable cost
- Assess whether the data is accessible and structured enough to work with
- Define what success looks like and how you’ll measure it
- Only then choose the tool that fits the problem — not the other way around
This sounds obvious. In practice, most companies skip steps 1–3, because time pressure and curiosity about the technology outweigh process discipline. A technical partner who doesn’t ask about steps 1–3 before showing you a demo should be a warning sign.
How to choose the right pilot use case
A Proof of Concept (PoC) shouldn’t be ambitious. It should be the smallest possible scope that answers one question: does AI automation actually work in our environment, and does it deliver measurable value?
A good pilot case meets four criteria:
High volume, low decision complexity. A process that runs hundreds of times a month, but follows a similar pattern each time. Verifying invoices from regular vendors, answering repetitive customer questions, routing service tickets — good PoC material. Complex contract negotiations — not.
Accessible, structured data. The agent needs data to work with. If the information critical to the process lives in free-text emails, in specific people’s heads, or in systems without an API — the PoC will be fighting infrastructure, not testing automation. That’s a problem to solve before the pilot, not during it.
A measurable outcome. Choose a process where you can measure the before-and-after state. Hours spent per week, average ticket resolution time, manual error rate, month-end close duration. Without a baseline metric, you don’t have ROI — you have opinions.
Low failure risk. A PoC shouldn’t touch business-critical processes. If the agent makes a mistake during the pilot, the cost of that mistake should be recoverable. This is why early-stage implementations often run in “suggest only” mode — the agent recommends, a human approves.
What a PoC should include — and what it isn’t
This distinction matters, because many companies confuse a demo with a proof of concept.
A demo is not a PoC. A demo shows that a tool can do something in a controlled environment, on sample data. Impressive, but useless as the basis for an investment decision.
A PoC is not an MVP. An MVP (Minimum Viable Product) is the first version ready for end users. A PoC answers the question of whether the approach is feasible — it doesn’t deliver production-ready value.
A good PoC includes:
- Your company’s real data (even anonymized) — not sample datasets provided by a vendor
- One specific sub-process — not “automate customer service” as a whole, but e.g. “automatically verify invoices from 10 regular vendors”
- Measurable KPIs defined before the start — percentage of cases handled correctly, processing time, number of escalations
- Integration with at least one production system (even in read-only mode) — a PoC that only runs on data exported to Excel doesn’t test what will actually hurt at full deployment
- A defined definition of success — at what level of accuracy do you recommend moving to full deployment?
What a PoC doesn’t need: a full UI, production documentation, integration with every system, or handling of 100% of edge cases.
Timeline: from workshop to production deployment
Below is a realistic timeline for a typical AI automation project in a 50–400 person company. It assumes one specific process, one system to integrate with, and a client-side team ready to collaborate.
Week 1–2: Discovery workshop
Mapping the current process, identifying volume and bottlenecks, assessing data quality and accessibility, defining business rules, setting KPIs and success criteria. This is the most important stage — it determines whether the project hits the mark.
Week 3–4: Agent configuration
Environment setup, first integration with a production system (read-only), model and rule configuration, testing on historical data.
Week 5–6: PoC and calibration
Running the agent on real data in “suggest only” mode, measuring performance against defined KPIs, iterative calibration of rules and model.
Week 7: Decision and scope
PoC report with concrete results, go/no-go recommendation, defining the full deployment scope and pricing model.
Week 8–14: Production deployment
Full integration, edge case handling, team onboarding, launching monitoring and a KPI dashboard, 30/60/90-day follow-up.
Total: 8–14 weeks from the first workshop to a system running in production. For simpler processes (one system, structured data), it can be shorter. For processes requiring multiple integrations or messy data — longer.
What to require from a technical partner
This is a question decision-makers rarely ask explicitly before signing a contract. The result is disappointment three months later, when it turns out “AI implementation” meant configuring an off-the-shelf SaaS tool with minimal customization.
A checklist worth having when evaluating proposals:
Process and discovery
- Does the partner start with a discovery workshop, or with a tool demo?
- Do they ask about data, integrations, and success criteria before presenting a quote?
- Can they say “this process isn’t a good fit for AI automation — here’s why”?
Technical aspects
- Is the agent built around your data and processes, or is it a pre-built product with configuration on top?
- How does integration with your systems (ERP, CRM, knowledge base) work?
- Is the code and architecture yours after the project ends — or are you locked into the vendor’s platform?
Security and compliance
- Where is the data hosted — within the EU?
- How is data anonymized before being sent to the LLM?
- Does the deployment comply with GDPR and — where applicable — the EU AI Act?
Long-term support
- Does the partner offer monitoring and maintenance after deployment?
- What does the follow-up model look like (30/60/90 days)?
- Do you have access to a KPI dashboard and performance reports?
Pricing model: setup fee + subscription vs. time & materials
Before signing a contract, make sure you understand what you’re actually buying.
Three main models exist in the market:
Time & Materials (T&M)
You pay for the team’s time. Flexible, but hard to budget for. The risk of scope overrun sits on your side if requirements weren’t clearly defined upfront.
Fixed price
A set price for a predefined scope. Good budget protection, but requires a very precise specification before the start — every scope change generates an addendum. Rarely seen in AI projects, where scope tends to evolve during the PoC.
Setup fee + monthly subscription
A one-time implementation and configuration cost, followed by a monthly fee for hosting, maintenance, monitoring, and support. This is the model we use at ITSharkz. Advantages: predictable operating cost, the partner has a vested interest in the system performing well long-term (not just at handover), and it’s easier to plan TCO over 24 months.
TCO over 24 months — what’s worth calculating:
When comparing offers, consider not just the implementation cost, but also:
- Monthly LLM model cost (scales with volume)
- Hosting and infrastructure cost
- Maintenance cost and business rule updates
- Cost of future integrations with new systems
- Cost of your own team’s time and involvement
A cheaper upfront deployment often means a more expensive maintenance bill later — or no maintenance at all, and system degradation over time.
Summary
Implementing AI automation isn’t an IT project. It’s a business project that requires leadership buy-in, a clearly defined problem, and a partner who understands your processes — not just their own tools.
Three things to remember:
- Start with the process, not the tool. Choose one specific sub-process with high volume, measurable cost, and accessible data. A 4–6 week PoC will tell you the real potential.
- A PoC is not a demo. It requires real data, integration with a production system, and KPIs defined before the start. Without that, you don’t have a basis for a decision.
- Ask about TCO, not just implementation price. Maintenance, monitoring, rule updates, and LLM cost over time are part of the equation — and they determine whether the project is actually worth it.
If you want to see what an early-warning case looks like — what happens when this process is skipped — read our article on why most AI agent projects never reach production.
Book a discovery workshop with ITSharkz and start from the right step.
→ https://itsharkz.com/ai-agents/