AI Audit and Pilot: start with the process, not the technology

Instead of choosing a tool and looking for a use case for it, we first check where time is actually disappearing in your company. You get a document with a recommendation and a pilot scope, not an offer for an implementation nobody has costed yet.

Who this is for

When it's worth starting with an audit

1

No direction

You know AI could help, but you don't know where. The topic is on the board's agenda, budget is provisionally set aside, but nobody can point to the process to start with.

2

Several ideas

You have several ideas and don't know which is best. The audit compares them against the same criteria: effort, risk, impact on day-to-day work.

3

Need for proof

A board rarely approves an investment based on the belief that "AI helps everyone now." The audit produces a document you can put on the table.

4

Verification

You've already received a quote and want to check it before deciding.

When an audit isn't needed

If you know exactly what you want, have the process documented and your knowledge organized, this stage can be skipped and you can go straight to the pilot. We'll say so directly if that's the case. The audit is not a mandatory gate before every conversation.

How we qualify a process for audit

Three questions that show whether there's anything to discuss

Question 1

  • Where does time disappear? Where does the team lose the most time today rewriting data, searching for information, preparing responses, or keeping track of things?

Question 2

  • Where is the data? What data is needed to improve this, and where does it currently sit?

Question 3

  • Cloud or on premises? Can this data be processed in the cloud, or does it have to stay within the company's environment? This question determines the shape of the whole project, which is why we ask it right away.
Scope
What we analyze
  • Process
    How a case flows today from start to close, how long each step takes, where it sits waiting on someone, where manual work is created.
  • Data
    What information is needed, in what form it exists, where it sits, and whether it's current. This point most often reveals that part of the knowledge used daily doesn't exist anywhere in writing.
  • Systems
    What you actually use, what data is available, and what can be done with it without interfering with systems critical to running the business.
  • People and decisions
    Who decides at each point in the process, which decisions must stay with a person, and where approval is needed before the next step. Setting that boundary is part of the audit.

What you receive

A document in three parts, ready to present to the board

Written without technical jargon, so it can be read at a decision-making meeting.

Part 1

  • Current state A process map marking the points where manual work and delays occur. A short description of the systems in use and the data available.

Part 2

  • Findings and priorities A list of the highest-potential areas, ranked by effect and effort, not by what's technically most interesting. Each with an estimate and a note on what it requires on your side.

Part 3

  • Recommendation and pilot One selected solution with justification, plus a ready pilot scope: what it covers, how long it takes, what metrics, and what baseline.

Recommendation format

We present options and point to one

The recommendation isn’t a single sentence saying “we propose implementing X.” The decision stays with you, but it isn’t made blind. For each option we give effort, risk, and impact on the team’s daily work. An example recommendation scope:

Option A

  • Organizing what already exists Sometimes it's enough to fix the flow of information or document missing procedures, without implementing anything new.

Option B

  • Automating a fragment Narrow scope, fast result, limited risk. The most common recommendation for a first project.

Option C

  • Broader implementation with integrations Bigger effect, longer project, more dependencies between systems and teams.
Pilot model
A pilot is a limited fragment, not a smaller version of the whole implementation
  • Narrow scope
    One case category, one team, or one document type. Enough to see the effect, no more.
  • Metrics and baseline set in advance
    Success criteria are written down before work starts, and the baseline is measured before the start. This is the most commonly skipped element and the most common cause of disputes over whether an implementation "worked."
  • Clear boundary of responsibility
    What the system does and what stays with a person. Set in writing before anything is switched on.
  • Continuation decision based on data
    After the pilot we come back with results and a recommendation: expand, change approach, or stop where we are.
Success criteria and metrics

We choose metrics to fit the process, not the other way around

At the audit stage we select two or three of them and set a baseline for each. Below are the ones that work most often.

Case handling time

From intake to closure.

Cases handled manually

How many still require rewriting data.

Time to find information

How long it takes to find the answer needed to do the work.

Number of errors

Mistakes arising from manual data entry.

Cases closed independently

Share of cases closed without involving another person.

Unit cost

Cost of handling one case, if it can be reasonably calculated.

What we don’t provide: results from other companies’ implementations presented as a promise for your process. A number pulled from a different context says nothing about your situation. We measure on your data, in your setting.

Process audit or application audit

Two different services, worth knowing which one you need

If the problem is an existing application rather than a process, we start from the other path.

See: Application Refactoring with AI →
  • Process audit

    The starting point is the way work is done: a case, a document, a request, the flow between people and systems.

    Answers the question: where is it worth improving the work.

  • Application and code audit

    Concerns a specific piece of software: its technical condition, security, architecture, and potential for further development.

    Answers the question: is this application worth developing further, and what risks does it face.

Further implementation paths

After the audit, the project follows one of the defined paths

This is settled in the recommendation, not after signing a contract. In every case there is one lead team and one point of contact. We don’t pass you between companies.

Product projects: GOTOMA Software House

  • Implementation of software, assistants, and automation within an existing environment. Most projects follow this path: a website assistant, document work, automating a fragment of a process, integration with your systems.

Infrastructure projects with GOTOMA GENERAL

  • Technical criteria: data and the model cannot leave your infrastructure, or a dedicated environment is needed.
  • Business criteria: hardware or physical infrastructure, coordination of several contractors, a grant or tender procedure, several locations, changes to the ERP or MES itself.

Cross-cutting projects: Grupa GOTOMA

  • If the need spans several areas at once, for example sales, documents, and infrastructure, we run it within the Technology Group, with one consultation instead of three separate conversations.

Book a case analysis

A short conversation after which you’ll know whether an AI implementation makes sense in your case.

Let's talk