Three iterations, a web platform with two or three users, and roughly 1,080 hours of manual work taken on by an assistant. A story about building solo and getting to know my actual audience.
My brief for introducing AI at a conservative company was fairly open-ended: “Go on, show us what your AI can do. We'll give you a chance, but we're not convinced.” A little credit had been extended.
Finding something useful to do was up to me. I started looking at procurement and sales: documents, requests, orders, and data copied by hand. Dedicated «1C» ERP operators acted as the managers' hands inside, entering information and clicking through the system on everyone else's behalf.
The company ran on «1C» ERP, a business management and accounting system widely used across the former Soviet Union. Over twenty years, it had been continually customized around the company's needs, while employees built their working routines around those customizations. Orders, documents, and calculations all lived there.
That was how Lenochka began: an AI assistant for this routine work. Over time, she learned to analyze tenders, match products to catalog entries, and work with 1C data. She acquired a convenient web interface and a chat backed by an agent that could handle multistep tasks.
She had two or three users.
I kept improving the system, while most employees kept working as before. I thought the hard part was behind me; all that remained was getting people to use it. That “all that remained” was where I was most wrong.
To make the project work in practice, I had to rethink my own idea of a good product—and make a decision that fitted poorly with my original picture of a modern AI assistant. We were still a long way from the closing credits and a standing ovation.
But it all started with a Telegram bot.
The first bottleneck I found was in the 1C operators' work: reviewing tender documents took hours. A hundred-page contract, a procurement document with eight hundred line items—you had to check the technical specification against the initial price calculation, spot qualifications buried in appendices, and copy the relevant clauses into 1C. A crucial detail could be hiding in a single footnote.
The first Lenochka was a Telegram bot: send the documents, get an analysis. She handled that part quite well.
Afterward, though, someone still had to transfer the information into 1C, find the related records, and prepare the documents. The rest of the request was still a human's job.
I had also misjudged the choice of platform. Most employees didn't use Telegram. They would have to learn another tool, find the chat, and upload their documents. Later, restrictions on access to Telegram added another obstacle.
From my side, it looked like “just send the file to the bot.” From the employee's side, it was a separate adventure before they could get on with their actual work. I had supplied the word “just” on their behalf, of course.
First iteration — tender analysis in Telegram. English-localized screenshot; identifying details obscured.
I put a lot of time into the web version: expanded document analysis, catalog matching, automatic pricing, document creation, and invoice preparation. I added 1C integration and a chat with Lenochka. Agent sessions made it possible to delegate multistep tasks in plain text. A helper for one operation was becoming a full platform.
The obstacles from the first version seemed to be gone: no Telegram, more capabilities, tighter integration with the business system. Open the web app and get to work. In my head, that was exactly what the user did.
Widespread use still didn't follow. You demonstrate, explain, and make improvements—and the next day, everyone does things the familiar way. When you're responsible for the rollout, you eventually want to ask: what else do you need?
People opened 1C in the morning and spent the day there. It held their orders, customer records, documents, and conversations.
My interface was convenient for someone who had already decided to use it. That decision was precisely what I hadn't managed to earn.
To me, opening another tab was trivial. To them, it meant learning a different interface, figuring out what to ask the assistant, and switching between windows to check the answer. They were still responsible for the result.
My audience wasn't looking for a new way to work. They wanted to get things done in familiar surroundings and stay in control. My convenient interface required changes they hadn't signed up for.
So the question changed: how could I give them Lenochka's capabilities while asking them to change as little as possible about their working day?
Second iteration — the web platform and agent chat. English-localized screenshot; identifying details obscured.
There was already a messenger inside 1C, known in the company as “As’ka,” the old Russian nickname for ICQ.
If ICQ's spirit is still alive anywhere, it's in this ERP. That was where a new contact appeared: an AI assistant you could give a task to in an ordinary message.
1C also has its own programming language. Yes, you really can find code with Russian keywords in this system. And yes, you can run modern AI agents on top of it.
On one side, a cloud language model. On the other, Cyrillic code entities
“ЗаказПокупателя” (Customer Order), “Номенклатура” (Product Catalog)
and As’ka of course. The cyberpunk we deserve.
Background processes connect the two: a poller watches for messages and tasks in 1C, a queue passes them to a watcher, and the watcher starts agent sessions. Integration tools, including a COM connection to 1C, let the agent read data and carry out the actions defined by the workflow. The result goes back into the ERP.
For the employee, all of this amounts to “message Lenochka, get an answer.”
People who had previously avoided Lenochka began trying her, including senior colleagues with 30+ company experience and over who didn't want to leave their comfortable, familiar routines. Now the assistant had come to them; they didn't even have to relocate to another tab. They gave her real tasks and came back for help.
Getting into the familiar interface turned out to be easier than earning trust.
Third iteration — Lenochka in the messenger inside 1C. English-localized screenshot; identifying details obscured.
While some people wrote “Lenochka, you're amazing,” others said “she's stupid and makes mistakes.” A useful AI assistant also turned out to have an awkward property: being useful can be exactly what makes it frightening.
Not everyone said it outright, but behind some of the resistance I saw concern about people's own roles. Today the assistant reviews documents; tomorrow someone might ask why that requires a separate employee.
Some came back with new tasks, some wrote the system off after its first mistake. Others chose the most energy-efficient AI adoption strategy: pretending it didn't exist.
The complaints about errors were fair. An employee has a specific order and is responsible for it. A speech about the rapid progress of language models doesn't fix a wrongly matched item.
That meant thinking carefully about verification. In workflows that require it, Lenochka prepares a draft and asks for confirmation. Tools validate data before writing and read it back afterward. If an employee has changed the original record in the meantime, the system needs to catch that before applying its own changes. People need to understand what the assistant has done and where their decision is required.
A chat has a limitation: somebody has to write first. Notice the task, remember the assistant, gather the materials. For an audience that was ignoring AI only yesterday, that's an ambitious plan. So Lenochka acquired background work.
The system launches relevant workflows in response to email and ERP events, or on a schedule.
By the time an employee gets to the task, some of the work is already done. Lenochka delivers the result to the familiar messenger herself. Hiding from automation gets harder when it starts messaging you first.
For example, an emailed request goes through attachment reading, customer lookup, line-item extraction, and matching against the 1C product catalog. The output is a prepared order that can be created in the system after the required confirmation, then checked.
Product matching happens in stages. The first two check for exact matches and search the reference data. Model reasoning only comes in at the third stage, when it needs to work out what a product actually is and which catalog entry it corresponds to. If there's still no clear answer, Lenochka asks for clarification. A model can mix up two items very convincingly, so its enthusiasm alone doesn't qualify it to write to the ERP.
At this point, the vast majority of employees were using Lenochka. After two versions that needed help finding users, a different question emerged: how much work was she taking on? It was time to count operations and estimate how long they would have taken by hand.
The latest version has been running for two months and has become the company's main way of creating orders.
Over the past two weeks, 90% of the orders she created needed no manual editing. People could use the document without a round of “thanks, now I'll redo it all.”
The operational figures are now quite concrete.
Two months of Lenochka in production: 1,080 hours of manual work saved, worth approximately $8,000 — equivalent to about 5% of monthly payroll on average.
By the latest measurement, Lenochka had handled work that would have taken around 1,080 hours manually, based on the company's internal time standards. That's 135 eight-hour working days over two months: document review, order preparation, and other operations employees previously had to find time for.
At the company's average internal rate of RUB 625 an hour, that work is worth RUB 675,000. To put the scale in context, the monthly average value of the manual work Lenochka takes on is roughly 5% of the company's monthly payroll. Employees still work in the same ERP.
I'm building Lenochka on my own, with AI tools. I study the processes, choose what to automate, and check whether employees actually use the result.
AI helps me explore code, implement features, and check changes. Product decisions and responsibility remain mine. You can build a working feature faster now. Figuring out why nobody wants it is still your problem.
I'm using AI to build a system that helps other people work with AI. Somewhere in the middle, you still have to talk to people—with no “regenerate response” button.
I think that part will remain indispensable: the easier technology becomes to build, the more it matters to understand people and work through change with them.
On my next project, I'd ask earlier: where do employees spend their day, what do they repeat by hand, and when do they need help? Those answers determine the interface, integrations, and how much initiative the agent needs to take.
If you're considering AI for your company, start with one sequence: receive a request, read it, find the data, transfer it, check it, create the document. Count the manual steps and the switches between systems. That gives you something concrete to discuss when considering an implementation and its impact.
I'd imagined introducing AI would look a little different. But at this project, the future's first stop was ICQ.