Adopting artificial intelligence

Adopting AI — means embedding a model into a process that already runs, not launching a separate system beside it. The model reads the company's data, finds a pattern in it and produces a decision; the action on that decision is carried out by the system the process lives in — CRM, ERP, the warehouse program, the checkout, the portal, the messenger.

That is why a project starts not with choosing a model but with four answers: what data exists and what condition it is in; which decision needs to be made; who executes that decision and with what; and which figure will show that things got better. Without any one of the four, a model adds one more data source nobody is responsible for.

Where AI is not needed. If a rule can be written in a single line — stock below five units, notify purchasing — it is written as a rule: cheaper, predictable and verifiable line by line. AI belongs where there are dozens of signals, they change over time, and a person has so far been deciding by eye: classifying an enquiry, estimating demand, spotting an atypical operation, extracting fields from a free-form document.

Collected data is not ready for use: the same item is called three different things, units of measure are mixed up, half the records lack a mandatory attribute, and some rows are duplicates of one operation. A model trained on such a set will reproduce the mess rather than find a pattern.

AI processing covers three jobs here: bringing records to a single form, filling in attributes where there are none, and sorting objects into categories that did not exist in the source data.

• Normalization — a single format for dates, numbers, units of measure, phone numbers, addresses and registration details
• Name matching — VVGng cable 3x2.5, VVG-ng 3*2.5 and vvgng cable 3x2.5 GOST are reduced to one catalog item
• Filling in gaps — a missing category, brand or unit of measure is predicted from the other fields on the card
• Classification — a product is assigned to a group, an enquiry to a topic, a payment to an expense item, a counterparty to a segment
• Feature extraction — characteristics are pulled from the description: volume, weight, power, composition, shelf life
• Duplicate detection — two cards for one counterparty or two documents for one delivery are found from a combination of fields rather than from an exact string match
• Consistency checks — negative stock, a dispatch date earlier than the order date, line items that do not add up to the document total

Action: confident corrections are applied automatically and written to the log with the original value; borderline ones go to the owner of the reference data for confirmation as a single list rather than as individual emails.

Why this is a job in its own right

Data quality is not a one-off tidy-up before a project but a continuous process: reference data grows every day, suppliers change their price list formats, and managers create cards from scratch instead of searching for the existing one. That is why the cleansing rules and models live in the system alongside the data and are applied on every load.

Every correction has an author — a rule or a model — a time, and an old and a new value. This is not bureaucracy: without the history it is impossible to work out why last month's report shows different numbers today.

Result

Reference data stops branching, reports by product group and expense item agree with each other, and preparing data stops eating up most of the timeline of every analytics project.

An ordinary report answers the question it was asked: revenue by month, sales by branch, stock by warehouse. The questions are asked by a person, so you see exactly what somebody thought to look at.

AI processing reverses the direction here: the model reviews the breakdowns itself and brings back the ones where an indicator behaves differently from what was expected. Not draw me a chart but here are three places where something unusual is happening, and here is what it correlates with.

What intelligent analytics does:

• Segmentation — customers, points of sale and products are grouped by actual behavior rather than by categories thought up in advance
• Decomposing an indicator — a drop in revenue is broken down into the contributions of categories, branches, channels and average receipt: it becomes clear what exactly fell
• Links between events — which attributes of an order, a customer or a location most often accompany a refusal, a return, a late payment or a customer leaving
• Risk assessment — the probability that an order will be cancelled, an invoice will not be paid on time, a customer will stop buying
• Ranking attention — a list of objects requiring investigation, sorted by potential losses rather than alphabetically
• Queries in plain language — a question put to the data in words, with a mandatory reference to the source and the period in the answer

Action: a finding does not stay in a dashboard — it turns into a task with an addressee and a deadline: investigate the location with the drop, contact the customer in the risk group, check the category with rising returns.

Routine means operations that repeat dozens of times a day, require attention and require no qualifications: copying data from an email into a card, assigning a payment to an expense item, appointing a performer, checking that a document is complete, setting a status.

AI processing is needed where the input is not formalized: the email is written in words, the document arrived in someone else's format, the request is worded differently by every customer. The model brings such an input into a structure, after which ordinary rules — predictable and verifiable — take over the process.

Operations that become automatic:

• Sorting incoming emails and requests
• Determining the topic and urgency of an enquiry
• Assigning a performer and a deadline
• Creating a customer card and a deal
• Extracting data from documents
• Matching a document against the order and the invoice
• Assigning a payment to an expense item and a contract
• Checking that a document package is complete
• Drafting a reply to a standard request
• Translating texts and bringing them to a single form
• Preparing statements and certificates from a template
• Filling in product card fields from the description
• Checking a request for completeness before it is launched
• Prioritizing a task queue
• Summaries by shift, day and site
• Alerts to responsible people on events

Action and result: the operation is carried out by the system and written to the log with an author, a time and the original value. The employee moves from data entry to handling exceptions — the cases where the model is unsure or where the cost of an error is high.

Data: delivery notes, invoices, certificates, contracts, specifications, payment orders, applications, equipment datasheets, emails with attachments. The formats vary: pdf, a phone photograph, a scan, an export file, a paper original.

AI processing: text recognition, identifying the document type, extracting fields and table sections, matching line items to the catalog and linking the document to an order, a contract or a counterparty. For every field a value and a confidence figure are returned.

What is extracted:

• The parties' details — name, registration numbers, address, bank details
• Number and date of the document, references to the contract, invoice and order
• The table section — line items, quantity, price, amount, tax rate
• Totals — net amount, tax, total due, currency
• Terms and deadlines — payment terms, delivery terms, warranty, penalties
• Signatures and stamps — presence, not authenticity: authenticity is a matter for legally binding document flow

Action: the document is matched against the order and the invoice, discrepancies are listed, and the document is either posted or sent for review to a specific employee. Result: entering documents stops being a job of its own, and discrepancies are found before payment rather than at month-end close.

Where the boundary lies

Recognition never gives one hundred percent accuracy on any set of documents — and it should not. The point is something else: the system shows which fields it trusts and which it asks to have confirmed. The operator checks a few flagged fields instead of typing the whole document.

Poor source quality is no excuse for a silent error: a blurred photo, a cropped page, a missing second page of a specification are all flagged explicitly and returned to the sender with the reason stated.

Result

Processing speed stops depending on the volume of the incoming flow, and accounting and procurement see the state of documents in one list rather than in individual employees' mailboxes.

Data: emails, requests from the website, messages in messengers, call transcripts, support chat correspondence, reviews and ratings. All of it free-form text that a person has had to read and sort until now.

AI processing: the enquiry is assigned to a topic and a subtopic, urgency and sentiment are determined, the order number, product name, address and other entities are extracted from the text, and the enquiry is linked to the customer's history. Repeat enquiries about the same matter are merged into one case.

Action: the request goes into the relevant group's queue with its fields already filled in, the response deadline is calculated from the urgency, a repeat enquiry is raised in priority, and the customer receives a confirmation with a number and an expected timeframe.

Result: enquiries stop sitting in a shared mailbox until morning, and the manager sees not lots of complaints but a structure: which topics the flow is growing in, where response time is rising and which products generate repeat enquiries.

What examining the whole flow gives you

A single enquiry tells you about a case; the whole flow tells you about the product and the process. Classification by topic over a period shows what exactly causes questions: unclear instructions, an error in a product description, a failure at a particular step of checkout, a delay at one delivery service.

That is why topics are not invented: first the enquiries are grouped by meaning automatically, then the resulting groups are edited by hand and fixed as reference data. From then on it lives alongside the product, and new groups are suggested by the system.

A bot is not one model but several connected parts. The separation matters in practice: each part has its own failure mode, its own metrics and its own way of being fixed.

• Understanding the request — what the person wants to do and which parameters they gave: order number, date, product, address
• Knowledge retrieval — selecting the fragments of documents and records the answer will be built on
• Access to systems — the set of permitted operations: view an order, create a request, change a delivery date. Each is described explicitly; the bot has no arbitrary actions
• Composing the answer — the model assembles the answer strictly from what was found and what the systems returned; whatever is not in the sources does not appear in the answer
• A check before sending — the answer is verified against the sources and the action against the user's rights and limits
• Handover to a human — escalation rules: low confidence, a repeated question, a negative reaction, a topic from a restricted list
• Log — what was asked, what was found, what the bot did and on what grounds. Without this a complaint cannot be investigated

The connection channels — the website and the customer account, messengers, email, a phone line with speech recognition, the internal portal and employee workplaces. The logic is the same throughout: the channel changes the form of input, not what the bot is allowed to do.

Where the answer comes from

The bot does not remember your documents — it searches them at the moment of the question and answers from what it finds. That is why an updated policy takes effect as soon as it is uploaded rather than after the model is retrained, and that is why every answer has a source.

How a bot is launched

The first thing assembled is a set of real questions — from correspondence, enquiries and internal chats. The bot is tested against it before launch: answers are checked against the sources and errors are examined by cause. Only then is the bot opened to users, usually to one group first.

An internal assistant differs from a customer bot in its source data: it works with corporate information and within the rights of a specific employee. The same question from a warehouse worker and from a finance director gives different answers — because different documents are available to them.

What an assistant does at a workplace:

• Answers from the policies — how to file something, who approves it, what the deadline is, which document form to use, with a reference to the clause
• Assembles a briefing on an object — customer, deal, contract, order, device: history, open questions, upcoming deadlines
• Prepares drafts — an email, a quotation, a reply to an enquiry, a task description, meeting minutes
• Keeps records for the employee — the outcome of a call or a meeting turns into tasks, deadlines and an updated card
• Files requests — to HR, procurement, technical support: the fields are filled in from the conversation rather than from a twenty-field form
• Prepares a shift summary — what happened on the site during the period, what is still open, what needs a decision

Result: the employee spends time on the work rather than on finding the right document, recalling a policy and filling in forms. The assistant does not make decisions for the person — it removes the preparatory part.

Corporate knowledge is rarely in one place: policies in one folder, contracts in a second, technical documentation in a third, and half the answers in correspondence. Searching by file name does not work here, because a person is not looking for a document but for an answer.

Data: policies and orders, contracts and annexes, technical and project documentation, instructions, the base of resolved enquiries, minutes, reference data, the correspondence archive — each with an owner and an access level.

AI processing: documents are broken into fragments and every fragment is indexed by meaning; the question is matched against fragments rather than against titles. The answer is assembled from what was found and comes with a quotation and a reference to the document, the page and the revision.

Action and result: an employee gets an answer with a source in seconds instead of going round their colleagues; borderline cases are checked against the quotation; outdated documents are visible immediately — if the answer came from a revision two years old, that is stated in the answer itself.

What makes a knowledge base work

• One entry point — sources are connected to the index rather than copied by hand into new storage
• Revisions and dates — the revision of the document is known for every fragment; the current one is separated from the archive
• Rights are inherited — from the source systems, so the index never becomes a way around access restrictions
• Event-driven updates — a changed document is reindexed immediately rather than on a monthly schedule
• Feedback — this answer did not help is flagged in the interface and goes into review together with the question
• Gaps are visible — questions for which no source was found are gathered into a list: that is the brief for writing the missing policy

What a knowledge base does not do

It does not replace the document management system and does not become the source of truth: a legally binding document stays where it was signed and is stored. The index is a way of finding and quoting it, not a separate copy living a life of its own.

A request arrives in free form and through any channel: an email, a message, a form on the website, a phone call, an attached file. Before adoption a person reads it, transfers the data into the system, determines the type and assigns a performer — which takes anything from a few minutes to a few hours of waiting in a queue.

AI processing: the request type is determined, fields are extracted — object, address, deadline, contact, contract number — completeness is checked, urgency is assessed, and the request is linked to the customer and their history. Anything missing is requested automatically in the same channel.

Action: the request is created in the system with its fields filled in, a group or performer is assigned by the rules, a deadline is set and a confirmation with a number is sent. Duplicates about the same matter are linked rather than spawning a second request.

Result: the performer receives a complete request and starts with the work rather than with clarifications. The time from arrival to assignment stops depending on who opened the shared mailbox and when.

The path of a request

What has to be configured

• A directory of request types and the rules for assigning performers
• Mandatory fields for every type — otherwise the follow-up request does not work
• Response deadlines by contract and priority
• A rule for merging repeat enquiries about the same matter

A model always gets things wrong — the question is how often, where exactly and what it costs. That is why every adoption has two sets of figures: the quality of the model itself and the change in the process. The first interests the engineer, the second the business, and they do not coincide automatically.

• Precision and recall — for each class separately rather than as a single average: a rare but expensive class matters more than a common one
• Share of automatic decisions — how many operations went through without a person at the given confidence threshold
• Share of corrections — how many automatic decisions a person cancelled or changed
• Operation time — from arrival to completion, compared against the baseline before adoption
• The cost of an error — what a miss costs and what a false positive costs; the threshold is tuned to that ratio rather than to the elegance of a metric
• Data drift — a change in the make-up of the input data that makes quality fall without a single edit to the system

The confidence threshold is a control knob, not a constant. Raise it and the company gets less automation and fewer errors; lower it and the opposite. The value is chosen by the cost of an error in the specific process.

What the panel shows

Operation after go-live

A model is not a one-off delivery. Data changes: new products, new enquiry topics, new document formats, new suppliers appear. That is why the project builds in regular quality checks on fresh data, retraining on a schedule or on a threshold being crossed, and review of the cases where a person corrected the decision.

Operators' corrections are the most valuable training material: they are gathered into a separate set and used in the next round of training. This way the system improves on its own work rather than on somebody else's data.