What happened

i-Tom Solutions, a Romanian software company, develops FGO, a SaaS platform for invoicing, accounting integrations, and related financial operations for small businesses. According to an AWS customer case study, the service's growth pushed written support demand to 200–600 requests per day. The queue included both short questions and issues requiring technical investigation. The team wanted to answer routine questions faster and avoid leaving customers without support outside business hours.

Instead of deploying a general-purpose chatbot, the company chose a narrow task: the assistant would answer using FGO's centralized knowledge base. The team built a retrieval-augmented generation, or RAG, workflow that retrieves relevant documentation before generating an answer. The published architecture names Amazon Bedrock for model access, OpenSearch for semantic retrieval, and Lambda for document processing.

The proof of concept took four to five weeks. After it, the validated infrastructure was deployed into the production environment in one week using infrastructure-as-code templates. At the time described, the assistant was operating in controlled production with selected customers while the team monitored accuracy and refined performance. The case-study provider says it was already handling hundreds of customer interactions per day.

That qualification matters. “Controlled production” does not mean that a model was allowed to resolve every customer problem autonomously. It means real traffic was introduced within a limited operating mode that included monitoring, error measurement, and the ability to hand difficult cases to people.

What is confirmed—and what is missing

The source supports several concrete facts:

  • the initial workload ranged from 200 to 600 written requests per day;
  • the first business objective was to answer out-of-hours questions;
  • the assistant used a centralized knowledge base and RAG;
  • the proof of concept took four to five weeks, followed by a one-week production deployment;
  • the rollout involved selected customers and accuracy monitoring;
  • the architecture used Bedrock, OpenSearch, and Lambda.

However, the publication does not disclose the percentage of issues resolved without an employee, answer accuracy, escalation frequency, cost per accepted answer, or a change in customer satisfaction. “Hundreds of interactions handled” cannot automatically be converted into saved support positions: processing a request, answering it correctly, and closing the issue are different events.

For a manager, this is a useful lesson in evidence discipline. The case demonstrates a viable implementation process, but it does not provide a ready-made return-on-investment model. Economics must be measured on the company's own traffic and data.

A transferable architecture for a small SaaS provider

The case can be translated into a vendor-neutral implementation pattern.

1. A request arrives from email, a form, or chat and receives an identifier, channel, language, and timestamp.
2. Rules run before the model: customer verification, removal of unnecessary personal data, and classification by topic and risk.
3. Retrieval selects a small number of fragments from the approved knowledge base together with source, version, and freshness metadata.
4. The model drafts an answer using only the retrieved context and identifies the supporting sources.
5. A release policy decides whether the answer may be sent automatically. Low confidence, missing evidence, financial changes, disputed operations, and incident signals route the case to an employee.
6. The audit record stores the request, retrieved documents, prompt and model versions, policy decision, employee edits, and final outcome.

A cloud implementation can use managed model and search services. A local implementation can use an on-premises LLM, a vector database, and an internal gateway. A hybrid design can keep documents and retrieval inside the protected environment while sending only minimal, de-identified context to an external API. Business rules, an evaluation set, and escalation policy are required in all three designs.

Data that must be prepared

RAG does not repair a poor knowledge base. Before a pilot, materials should be separated into four layers:

  • current instructions approved for customer-facing answers;
  • internal procedures available only to employees;
  • historical conversations that can reveal recurring questions but whose answers must not be copied without review;
  • prohibited or sensitive material, including other customers' details, credentials, passwords, personal data, and payment information.

Every document needs an owner, freshness date, scope, and deletion rule. For a financial SaaS provider, it is especially important to understand which data reaches subprocessors. FGO publishes a dedicated list: it states that the core environment is hosted in AWS Frankfurt, names Bedrock as an internal virtual assistant, and says AWS AI services are configured so operator data is not used to train or improve models. This is the company's own statement; another business should replace it with its own contractual and technical verification.

The minimum evaluation set should include more than frequent questions. Add outdated wording, typos, questions with no answer in the knowledge base, multiple topics in one request, attempts to change financial data, and requests for another customer's information. For every example, define the correct source, expected answer, or mandatory escalation in advance.

How to evaluate quality before auto-send

AWS documentation for RAG evaluation separates retrieval quality from generated-answer quality and uses a query set with expected passages and answers. This is more useful than one average “good/bad” rating.

Seven measures are enough for a pilot:

  • percentage of requests for which the correct document was retrieved;
  • percentage of answers fully supported by retrieved context;
  • percentage of cases in which the system correctly refused or escalated;
  • percentage of drafts accepted by an employee without edits;
  • median time to the first useful response;
  • cost per accepted answer, including retrieval, model usage, and human review;
  • number of incidents, such as data exposure, incorrect financial guidance, or unintended actions.

The auto-send threshold should be based on risk rather than on a model's overall rating. A question about the location of a button can be automated earlier than guidance about changing an invoice or tax document. NIST recommends post-deployment mechanisms for user feedback, appeal and override, incident response, and change management. In customer support, that becomes visible “hand over to an agent” and “report an error” controls plus a trace that can reconstruct how an answer was produced.

Economics: measure the resolved issue

Token price is not the main metric. Full cost includes preparing and refreshing the knowledge base, retrieval, generation, observability, security controls, human validation, and error investigation.

A practical unit is the cost per accepted answer or resolved routine request:

`(infrastructure + model + retrieval + maintenance + employee minutes) / accepted answers`.

Track repeat contacts on the same topic alongside it. If a bot replies quickly but the customer returns, the apparent saving is misleading. Compare the same categories of questions over the same period, not an undifferentiated “before and after AI.”

A 30-day next step

A small SaaS provider does not need to launch an autonomous 24/7 operator immediately. A pilot can be limited to one category, such as integration setup or interface navigation.

  • Week 1: select 100–200 real, de-identified questions, clean the documentation, and assign owners.
  • Week 2: build retrieval and a draft-only mode with no automatic sending.
  • Week 3: measure retrieval, grounding, edits, and escalations; repair source documents rather than only tuning prompts.
  • Week 4: allow auto-send only for one low-risk category and a small share of traffic while retaining immediate human handoff.

Define the continuation condition in advance: for example, zero critical disclosures, a high share of answers with the correct evidence, and less employee time per accepted answer. If the condition is not met, keep the system as an employee assistant. That is not a failed pilot: a high-quality, sourced draft often creates more business value than premature autonomy.

Management takeaway

The i-Tom/FGO case demonstrates a sensible sequence: a narrow objective, a governed knowledge base, a short proof of concept, reproducible deployment, and limited real traffic under observation. The most transferable element is not the particular cloud service but the controlled transition between stages.

Start with three decisions rather than “which model should we buy?”: which requests may be automated, what counts as an accepted answer, and who can stop the system when it fails. Then RAG becomes part of the support process instead of another chat window.