One person. A 1-to-7-day turnaround on RFPs. 80% of questions being repeats of things already answered somewhere in Notion, old email threads, or a doc nobody could find in time.
That was the reality before Virna Harri started automating. Virna is a Senior Technical Support and Solutions Engineer at zenloop, a saas.group portfolio brand. Over the past year, she’s built two live AI workflows that now run inside a real, revenue-connected Customer Ops function. Not a pilot. Not a proof of concept. Live, with guardrails, serving real customers.
Here’s what changed – and the decision framework behind every tool choice.
Start with the problem that’s actually costing you
The temptation when AI tools become accessible is to automate everything at once. That’s the wrong move.
Virna’s starting point was brutally practical: find the single bottleneck with the highest repetition rate and a clear success metric. For her, it was RFP responses. Every sales cycle required manually combing through Notion pages, email threads, and old docs to answer questions the team had already answered dozens of times. It was slow, inconsistent, and entirely dependent on one person.
That’s the profile of a problem worth solving first: high repetition, measurable time cost, clear “done” criteria. If your AI project can’t answer the question “how will we know it worked?” before you build it, you’re not ready to build it.
What two live workflows actually look like
Workflow 1: RFP analyzer
Virna built a RAG (Retrieval-Augmented Generation) system using Supabase and pgvector, with an AI model generating draft responses from retrieved knowledge.The system ingests the knowledge base – previous RFP answers, internal docs, Notion – and retrieves the most relevant content to draft responses automatically.
The result: RFP turnaround dropped from 1-7 days to 1-2 hours. First drafts now take around 10 minutes. 85% of questions are covered automatically from the knowledge base. One person no longer bottlenecks the sales pipeline.
A human still reviews every output before it ships. That’s not a limitation – it’s the design.
Since then, the workflow has split into two paths. Sales still uses the standalone RAG app directly – upload an RFP, get draft answers, review. No technical setup required. But on the SE side, the same capability now runs inside the agentic coding environment, where it can ingest a spreadsheet, detect structure and language, and generate answers alongside the debugging and investigation tools already in use. Different roles, same underlying capability, each accessed in the way that fits how they actually work.
Workflow 2: AI-assisted support debugging
The second workflow is more technically sophisticated. Using an agentic coding environment with MCP servers connected to Supabase, GitHub, Slack, Asana, Notion, and a custom internal database tool, Virna now investigates customer issues end-to-end inside a single terminal session.
A recent example: a customer reported that a checkbox wasn’t rendering correctly in their survey flow. Previously, that would mean hours of manually querying databases, reading through SurveyJS logic, cross-referencing the codebase, then writing up a troubleshooting log. With agentic coding + MCP, the full investigation – querying the production database, analyzing the expression logic, identifying the wrong operator (contains vs anyof), cross-referencing the codebase, and producing a complete troubleshooting log – took around 20 minutes.
That’s not a marginal improvement. That’s a different category of work.
MCP vs. APIs: The framework that actually works
Most published content on this either oversells MCP as a universal answer or treats it as too experimental to use. Neither is right.
Virna’s tiebreaker is straightforward: predictability and query shape.
| Use API when… | Use MCP when… |
|---|---|
| Query is well-defined and repeatable | Query is exploratory – you don’t know what you need until you start looking |
| You know exactly what you need before you ask | The answer requires reasoning across multiple data sources |
| Speed and reliability are the primary requirements | Steps aren’t predictable in advance |
| No need for reasoning or multi-step logic | Natural language is genuinely the right interface |
“MCP translates natural language into tool actions. Instead of writing API calls, SQL queries, or switching between five dashboards, I describe what I need in plain English and the LLM picks the right tool, constructs the right parameters, chains multiple calls together, and summarises the results.”
– Virna Harri, zenloop
The shape of your query – not the hype cycle – determines which approach wins.
What MCP made easier (and where it’s been frustrating)
MCP’s composability is real. When a debugging investigation needs to touch five different systems in an order you couldn’t have predicted when you started, the ability to chain tool calls dynamically – and have the model reason across all of them – is genuinely useful. You couldn’t hardcode that logic without writing a much more complex system.
But there are real trade-offs worth knowing before you commit:
- Debugging is opaque. When something goes wrong in a multi-step chain, tracing which tool call produced the bad result isn’t always obvious.
- Context management requires manual attention. You can’t assume the model always picks up where the last session left off.
- Tool selection reliability depends heavily on how your tools are named and how clearly your prompt defines the task. It takes tuning.
These aren’t dealbreakers. Virna’s approach was iterative: start with n8n for simpler automation, then move to an agentic SDK and MCP as the use case complexity justified it. No forced tooling. No all-in-one commitment before the value was proven.
The guardrails that make it safe enough to run
Giving an AI system access to production data is the part of this conversation most practitioners skip over. It shouldn’t be skipped – and for teams handling customer data, the stakes are higher than just reliability. There are GDPR implications and customer trust considerations in how you describe what’s happening to that data.
Virna’s setup has four layers of protection: all tools are enforced as read-only at the tool level, not just by policy; first-pass input sanitization filters obvious injection patterns before anything reaches the LLM; the RFP tool surfaces similarity scores to flag low-confidence answers; the debugging workflow uses hedged language in all findings, with human validation before anything reaches a customer; and escalation triggers are defined in an SE Playbook for conditions in which the AI workflow stops and a human takes over.
Virna’s priority stack
Reliability › Auditability › Control › Performance
Reliability is first because customer-facing answers can’t be wrong. Performance is last. A slightly slower system you can trust is worth more than a fast one that surprises you.
The founder angle: When should your SaaS ship an MCP server?
If you’re a SaaS founder watching this space and wondering whether to add MCP server support to your own product, Virna’s threshold is clear: three or more power users asking for LLM or AI integration, and an API that’s already well-documented. That’s it.
Start with read-only tools. Don’t expose write operations. Don’t expose billing. Don’t expose unscoped SQL queries or API key management. The goal is to give LLMs access to your data in a controlled, auditable way – not to hand over the keys to the database.
The crossover point is practical: when users are already working around the lack of native LLM integration – copying data out, building their own scrapers, asking your support team for exports – you’re past it. Ship a read-only MCP server and let them query it properly.
What this means for operators and founders
The pattern Virna built isn’t unique to zenloop. It’s transferable to any small B2B SaaS team willing to be specific about where automation actually helps.
Clear problem. Measurable success criteria. The right tool for the query shape. Guardrails before you scale. Human in the loop for anything customer-facing. That’s operational discipline – and it holds whether you’re a solo SE or a founding team rethinking how your support function works.
One thing worth flagging: what Virna built requires genuine engineering comfort. RAG pipelines, agentic coding environments, MCP server configuration, custom security layers – this isn’t a no-code story. If that expertise doesn’t exist in your team, getting it matters more than picking the right tool.
At saas.group, we see this kind of operational maturity across our portfolio.If you’re running a profitable B2B SaaS and thinking about what it looks like to have this kind of AI and operational expertise in your corner, not just capital, reach out to Pavel (pavel@saas.group).
Table of Contents
Weekly newsletter
No spam. Just the latest news and articles from the world of SaaS and Acquisitions.
