A Telegram bot
instead of the 1C client

A construction company was running 14 sites at once — commercial fit-out for restaurants, showrooms and offices. Accounting lived in 1C UNF on their own server; every site had a foreman and two to four crews. Each foreman called the office 6–8 times a day: "when is the tile arriving," "has the subcontractor been paid," "what is left in the budget." At peak, twelve calls and more.

The office manager burned 4–5 hours of pure phone time daily, trying to do actual work in between. That is not an inconvenience. That is 0.6 FTE the company was paying for a person to read numbers off a 1C screen out loud — roughly ₽48k a month.

There was a second loop. Incoming material was posted to stock with a 1–3 day delay — "I'll enter it later." Because of that, other foremen did not see real stock levels and called again. More calls, later postings; later postings, more calls.

The first suggestion is always to buy more licences and hand out logins. Sound on paper, useless on site. The foreman is in his forties, holding a hammer drill; there is no laptop on site. He will forget the password in week two, and a forgotten password turns into a call to the office — exactly the problem we are removing.

The second suggestion is to publish the 1C web client to the internet. This is where the IT director's real questions start, and where most vendor pages go quiet. Your accounting database becomes reachable from the internet at an address someone will eventually find. And permissions inside the configuration still have to be set up so a foreman sees his own site and not someone else's — that is real work inside 1C.

Three parts, each with one job.

• · 1C publishes its own HTTP services. This is a native platform mechanism rather than a third-party connector: a handful of methods return exactly what is needed — the employee's list of sites, the remaining budget, an order status.
• · A middle service sits between Telegram and 1C on a rented server inside Russia. It owns authentication, permissions, a cache for frequent queries, a queue and retries. If 1C is busy with a scheduled job, the request is not lost and the user never sees an error.
• · The rented server and the client's 1C server are joined by an encrypted WireGuard tunnel. 1C has no public address. The only thing exposed to the internet is the bot.

That is the answer to the IT director's main question: access from outside exists, an inbound door into 1C does not. Full project write-up: 1C UNF and a Telegram bot for foremen.

Login is by phone number from a pre-approved list. The user taps "share number," the system checks it against the list and binds it to the employee record in 1C. There is no password at all, and that is a decision rather than a shortcut: a password people forget turns straight back into a call to the office.

Permissions live in the middle service, outside the bot's interface. A foreman sees his own site and the others stay invisible, because a request for someone else's site never reaches 1C. The difference matters: a hidden button can be worked around, a request that does not exist cannot.

The interface is buttons. Main menu: "My sites" → site → "Orders / Payments / Budget / Confirm delivery." Two taps to a result at most; free-text input survives in roughly 5% of flows. This is not cosmetics: a tool that is awkward to use with gloves on will not be used — people go back to calling, because calling always works.

The most valuable button turned out to be an input one. A truck arrives, the foreman photographs the delivery note and taps "Confirm delivery" in the order card. The photo goes to storage linked to the 1C document, and the material movement is posted to the site. It used to take 1–3 days; it now averages 4 minutes — which also closes the second loop from chapter one: everyone else sees real stock and stops calling to check it.

A large share of the calls are simply checks: "has it shipped yet," "has it been paid yet." Search does not remove those — unprompted messages do: "the tile truck has left the warehouse," "the subcontractor is paid, the act can be signed," "budget overrun on this site, +3% over plan." They are triggered by events in 1C and by scheduled checks.

The side effect turned out to matter more than the stated goal. As long as the remaining budget is a number the office manager reads out, it is an abstraction. Once it is on screen and updates itself, the foreman starts counting money before the decision instead of after it. Project outcome: foreman calls went from 6–8 a day to 0.4, and what remains are genuine exceptions rather than routine.

"We configured the permissions" means nothing until it has been measured. An example from a neighbouring project — an internal knowledge-base assistant. The access levels there looked correctly configured.

I ran a measurement against the live index: how many private chunks the "team" level could actually see. The answer was unpleasant — 1,327. After fixing the rules, private chunks visible at that level dropped to 0 with no loss of working data. Separately I pulled the query log and confirmed nobody had actually reached those chunks.

The same conclusion applies to a 1C bot. Before launch, take an ordinary employee's account and look at what it can physically pull — instead of reading the description of the settings.

Four situations in which I talk clients out of it.

• 1. No access to the 1C server. The whole design rests on being able to publish HTTP services and bring up a tunnel. If your database is rented and you have no administrative access, the first conversation is with whoever runs that server.
• 2. Few field staff, few calls. Do the arithmetic honestly, support included. ₽480k one-time plus ₽12k a month against ₽48k a month saved: ignore support and it's ₽480k / ₽48k ≈ 10 months; count it and the net saving is ₽36k a month, so ≈ 13 months. Vendors quote the first number more readily; plan with the second. With one foreman and two calls a day the saving is several times smaller and the payback drifts into a range nobody bothers to calculate.
• 3. You need full document entry. A bot is strong where the operation is "look up" and "confirm." The moment someone has to create a document with twenty fields and item-by-item selection, buttons run out, and the honest answer is a 1C workstation rather than Telegram.
• 4. The process itself is broken. If material is not posted because nobody owns that step rather than because it is inconvenient, a bot only accelerates the mess. In those cases I propose a process audit first: on one such project two weeks of observation produced 11 candidate automations, and only three — the fastest to pay back — went into build.

Nowhere. And that is worth hearing before somebody sells you an "AI agent for 1C."

Everything above is careful data exchange: methods in 1C, permissions, a queue, retries, buttons. A language model is not needed here, and if you insert one it adds unpredictability exactly where you want the opposite: the remaining budget must be the remaining budget.

The same principle in an adjacent task. Parsing a Federal Treasury statement and loading it into 1C is XML parsing plus writing the bank-client format in Windows-1251 encoding, with no model call anywhere: 2–3 hours of manual work became 5 seconds (how it was done). Shipment paperwork works the same way — 1C supplies the data and the pipeline assembles the invoice and the act.

The model comes later and separately, where there is free text and a decision to make about it: first-line customer answers, search across internal documents with a citation back to the source. Different service, different budget.

A practical rule you can use to test a vendor: if the task can be described as "take field A and show it to person B," it does not need AI.

Numbers from the project described above: 7 weeks from kickoff to live, ₽480k one-time plus ₽12k a month for support. The same design fits logistics (a driver marks "cargo accepted" and "shipped"), manufacturing (a shop supervisor reads the shift plan and logs defects with a photo), field service, sales reps and retail. The common trait is always the same: the person does not work at a desk but needs numbers out of the accounting system.

Before you call anyone, answer four questions — they determine both the timeline and the price:

• a. Which configuration you run — UNF, UT, ERP or KA. Any of them works, as long as HTTP services exist or can be published.
• b. Whether HTTP services are published and who will do it if they are not. If nobody will, that is task one.
• c. Who administers the 1C server — your own staff, a contractor or a landlord. That decides how many days the tunnel takes.
• d. Whether employee records carry phone numbers. Login and permissions bind to them: no records, no per-site separation.

If all four have answers, the sensible first step is a 1–2 week pilot: one flow, one site, five people. Two weeks is enough to see whether people actually use the bot and how many calls it really removed.

The full service — integrations with 1C, Bitrix24 and amoCRM — is described on the services page, from ₽450,000; the price range for this track is listed on the pricing page.