What the documented case showed

A growing UK accountancy practice was not constrained by lead generation. Its bottleneck appeared after the sale. New clients signed proposals and then spent weeks supplying documents, confirming identity, completing checks, and waiting for work to begin. Employees manually copied the same information across email, CRM, practice management, e-signature, and document storage systems.

Vyrion describes a sixteen-week engagement covering interviews, mapping of the actual process, readiness assessment, evaluation of solution categories, target architecture, and a bounded pilot plan. The onboarding journey was decomposed into sixteen stages, from initial enquiry and proposal through document checks, task creation, accounting-system setup, and the kick-off meeting.

The central finding is inconvenient for vendors of all-purpose AI agents: roughly half of the valuable work does not require generative AI. Updating a CRM stage after signature, creating a task, routing an e-signature package, or scheduling a reminder is better handled by deterministic rules. A model earns its place where the workflow encounters an unstructured document, free-form language, or an ambiguous expression.

The source is also explicit about limitations. The practice is anonymised, early observations were not independently audited, and no percentage ROI is published. The engagement produced a target operating model, integration blueprint, accountability boundaries, vendor shortlist, and pilot design. This article therefore does not attribute financial savings that the source did not substantiate.

Where time was being lost

The most difficult section sat between a signed engagement letter and readiness for the kick-off meeting. That stretch concentrated repeated document requests, manual completeness checks, re-keying of client data, and partner interruptions asking where a case was blocked.

The process map revealed patterns common in professional services:

  • customers entered data once, while administrators retyped it into several systems;
  • required-document lists varied by entity type and lived in employees' memory;
  • reminder emails were rewritten from scratch;
  • CRM stages did not reveal the real cause of delay;
  • the next step depended on a person who might be busy or absent;
  • evidence of mandatory checks was scattered across tools.

The exact regulatory steps will differ for a Russian accounting, legal, or consulting company. UK rules should not be copied directly. The engineering pattern is transferable: document the required evidence and accountable role first, then separate predictable coordination from professional judgement.

Three classes of work instead of one “AI agent”

A practical architecture begins by classifying tasks.

1. Deterministic orchestration

These are events with an unambiguous input and output:

  • engagement signed — create the client record and task set;
  • document uploaded — record the event and notify the owner;
  • required field confirmed — advance the workflow stage;
  • deadline approaching — send an approved reminder;
  • minimum pack complete — offer kick-off meeting slots.

A model adds cost and unpredictability here. The real requirements are APIs, queues, retries, event logs, and exception handling.

2. AI with mandatory review

A model is useful for variable content:

  • propose a type for an uploaded document;
  • extract a name, address, or registration number as candidates for review;
  • flag a potentially missing item;
  • draft a message from an approved template;
  • retrieve an answer from an internal playbook through RAG;
  • prepare a short case summary for an administrator.

Model output should not directly overwrite master data. It belongs in a review queue that shows the source document, confidence level, and a visible field comparison.

3. Human decisions

Professional judgement remains with a named specialist: client acceptance, risk rating, escalation of suspicious activity, tax or legal advice, changes in engagement scope, and final confirmation of mandatory checks. AI can assemble context but must not impersonate authority it does not possess.

A minimum target architecture

The centre of the system is not a chatbot. It is an onboarding record with a state machine. Every stage has an owner, required inputs, permitted transitions, and a reason when blocked.

Five surrounding components do the work:

1. A portal or secure form receives customer data and files.
2. An orchestrator connects CRM, e-signature, calendar, task management, and storage.
3. A document service validates formats, runs OCR, and proposes classifications.
4. An LLM or local model generates drafts and answers only from the approved knowledge base.
5. A review queue presents the source, proposed fields, history, and required action to a human.

A smaller company does not need to build every component. Identity verification, e-signature, OCR, and integration platforms can be purchased, while the organisation retains ownership of its process map, escalation rules, message templates, and status dictionary. Those elements encode how the business works and reduce supplier dependence.

A local model is appropriate when documents cannot leave a controlled environment or when prompts and outputs require strict retention control. Local deployment does not replace access control, logging, or deletion schedules. For low volume, an external API may be more economical if contracts, processing region, and restrictions on training with customer data meet company requirements.

Data and security

Before a pilot, build a field register covering the source of truth, owner, sensitivity, retention period, readers, and editors. Identity, financial, and contact data should never be pasted into a shared employee chat or a public AI account.

Russian research reported by CNews said that around 60% of the organisations in the security provider's sample lacked formal AI-use policies, while the volume of data sent to public AI services had increased sharply. The figures describe a vendor sample rather than the entire market, but they illustrate the shadow-AI risk: an employee accelerates a task by copying a customer document into a service the company does not control.

Minimum controls for onboarding include:

  • one approved interface to the model;
  • a ban on sending customer files through public accounts;
  • field masking before an LLM call;
  • role- and case-based access control;
  • logging of inputs, outputs, and approvals;
  • automatic deletion of intermediate copies;
  • tests for wrong document type, missing fields, and low confidence;
  • human escalation by default.

Model economics without invented ROI

Assume a firm onboards forty clients per month. Administrators spend an average of three hours per case on collection, re-keying, and coordination. If a portal, integrations, and reviewable document extraction remove one hour of manual work per case, forty hours are released each month.

At a fully loaded labour cost equivalent to RUB 1,500 per hour, the capacity benefit is RUB 60,000. Assume services and integration support cost RUB 15,000 per month and initial setup costs RUB 300,000. The monthly net benefit before revenue growth is RUB 45,000, implying a simple payback of approximately 6.7 months.

This is an illustrative model, not the result of the practice in the source. Replace every assumption with measured data. Count not only minutes saved but also the cost of mistakes, delay until first billable work, repeated document requests, and partner interruptions. If automation merely shifts labour into an AI-error correction queue, there is no saving.

An eight-week pilot

Weeks 1–2: choose one customer type, document the actual stages, and measure baseline cycle time, re-keying, reminders, and rejected documents.

Weeks 3–4: define one document checklist, statuses, owners, and templates. Connect deterministic transitions without an LLM.

Weeks 5–6: add one AI scenario, such as document classification with human confirmation. Test de-identification, errors, and correction time.

Weeks 7–8: run the new flow in parallel for a limited group, review exceptions, and compare the full cycle with baseline performance.

Scale only on the basis of time to customer readiness, number of manual touches, rejection rate, cost per case, and audit-log completeness. Chatbot response count is not a business metric.

Management takeaway

Do not buy an “onboarding agent” as one black box. Divide the process first: the orchestrator executes rules, AI handles unstructured information under review, and people retain risk ownership and professional judgement. That separation is what turns an attractive demonstration into a controllable production process.