The service zoo: how to connect 1C, your CRM, your bank and Telegram into one stack
The average company runs 101 cloud services, Okta's 2025 report found, and at best a third of them are connected to each other: according to MuleSoft, only 29% of enterprise applications are integrated. The rest are joined by a person with a keyboard — copying, transferring and making mistakes. The good news: removing that manual bridge does not require replacing 1C, the accounting and ERP platform most Russian companies run on, along with your CRM and your bank, with a single "mega-system" — they can be connected into one stack.
Below is a jargon-free walkthrough: what integration is and how it works, which approaches exist and how they differ, what to do about 1C and about services with no API, where Federal Law 152-FZ, Russia's personal data protection law, comes into it, and which link to start with.
What is systems integration in plain language?
Integration is data exchange between programs set up to run without a human: an event that happens in one system appears by itself in every other system that needs it. A payment arrives at the bank — the invoice is closed in accounting, the deal moves forward in the CRM, and a notification lands in the manager's Telegram. Nobody copied anything: the systems agreed to exchange data themselves, according to rules described in advance.
The typical picture in a growing company: accounting in 1C, sales in the CRM, enquiries in Telegram, reports in spreadsheets, payments in the bank client. Each system is good in its place, and between them sits an employee who moves data by hand and makes mistakes.
The "zoo" itself is normal, not a sign of disorder. In the Okta Businesses at Work 2025 report the average company uses 101 applications; in large businesses, according to MuleSoft research, it is 897. What costs money is something else — the gaps between systems: wherever data is carried by hand, the business pays in time and errors.
What does a connected stack give the business?
A connected stack removes double data entry: every figure is entered once — in the system where it was born — and from there reaches everywhere it is needed on its own. The effect is measurable: in research by SberAnalytics and Sber Business Soft, 37% of companies that introduced automation report a drop in the share of manual operations, and 36% report fewer errors in documents and reports.
In practice it looks like this:
- A payment from the bank automatically closes the invoice in accounting and moves the deal in the CRM.
- Warehouse stock is visible to the sales manager right inside the CRM — no call to the storekeeper.
- The manager receives a summary in Telegram, assembled from every system at once.
- Transfer errors disappear as a category: a machine does not miss the cell.
The price of manual bridges is higher than it looks. According to an hh.ru survey from 2025, one employee in four in Russia spends more than six hours a week on reports and reconciliations that nobody has automated — almost a full working day spent shifting figures between systems.
How do systems exchange data without a human?
Through an API — a program's "entrance for other programs". If a service has an API, another system can ask it for data or hand over its own in a strictly defined form, like a visitor at a reception window. Almost everything Russian business uses has an API today: 1C, CRM systems such as Bitrix24 (a Russian CRM and collaboration suite) and amoCRM, the Russian inventory service MoySklad, banks, online cash registers and Telegram.
Several more mechanisms work around APIs, and each has an everyday equivalent:
- A webhook is a "call back": the system reports an event itself, the moment it happens. Like a text message from your bank about a debit — you do not check your account every five minutes, the bank sends the message itself.
- A message queue is a "waiting room" for data: if the receiving system is temporarily unavailable, the data lines up in the queue and is delivered once it is back — nothing is lost.
- Shared reference data is a "passport" for every client and product: one identifier across all systems, with duplicates caught automatically.
- An exchange log is the stack's flight recorder: every data transfer is recorded, so the question "where did this figure come from" always has an answer.
The first two mechanisms are responsible for speed, the second two for trust in the data. A stack without queues and a log works right up until the first failure.
What integration approaches are there and how do they differ?
There are four workable approaches: direct system-to-system links, intermediary builder platforms, a data bus, and replacing the zoo with one shared system. The choice depends on the number of systems and the cost of a failure: the more connections there are and the more expensive a mistake is, the more a centralized solution with queues and an exchange log matters. For two or three systems direct links are enough; beyond that a bus pays off.
| Approach | What it is in plain terms | When it fits | Weak point |
|---|---|---|---|
| Direct links ("point to point") | A bridge between two specific systems | 2–3 systems, simple scenarios | The number of bridges grows explosively: 5 systems can require 10 of them |
| Intermediary builder (iPaaS) | A subscription "translator" service that joins systems using ready-made templates | Standard scenarios, quick tests of a hypothesis | A ceiling on complexity; data travels through someone else's cloud; the subscription gets more expensive as volume grows |
| Data bus | A "sorting centre": all systems connect to a single hub that knows the route of every parcel | 4+ systems, non-standard logic, high cost of error | Requires design work and a development team |
| One "mega-system" instead of all | Moving the whole business into a single product | Processes are standard and you are ready to bend them to fit the system | Long and expensive; processes bend to someone else's logic; everyone has to be retrained |
Hybrids are common: a standard link can sit on a builder platform while flows that touch money run on the bus. We design stacks on a data bus as custom development: with queues, an exchange log and monitoring, on your infrastructure — so that a failure in one service does not bring down the rest.
Can 1C be connected to a CRM, a bank and Telegram?
Yes — it is the most common combination in Russian business. Since version 8.3.5 the 1C platform has had built-in exchange mechanisms: HTTP services and the OData protocol, through which external systems read and write data without changes to the configuration. Banks provide statements via API, CRM systems accept enquiries, and Telegram serves as the channel for notifications and bots.
A heavily customized 1C configuration is not a death sentence: an adapter is written for it, a translation layer between your database and the rest of the stack. It all starts with an audit of the specific database: which data is born where, and who needs it next.
A separate word about Telegram. According to Mediascope, 55% of Russia's population open it every day — so summaries and alerts arrive where the manager already lives, without another app. The full standard scenario: the payment reaches the bank, 1C closes the invoice, the CRM moves the deal, the owner gets a message — all within seconds and without a single copy-paste.
Common mistakes in integration projects
Four mistakes repeat from project to project: syncing everything with everything without an owner system, undefined rules for resolving conflicts, fragile links with no queues or retries, and the absence of an exchange log. Each is built in at the start and surfaces months later, as discrepancies in the data that nobody can explain any more. All four are closed off at the design stage.
- Syncing everything with everything. Every type of data must have an owner system — a single source of truth: accounting owns money, the CRM owns clients, the warehouse owns stock. The other systems read, but do not overwrite what is not theirs.
- Ignoring conflicts. What happens if a record is changed in two systems at once? The rules for settling such disputes are described during design — otherwise each case has to be sorted out by hand.
- Building on fragile links. Without queues and retries, one service being unavailable is enough for the data to drift apart. A queue turns a failure from an emergency into a delay of a few minutes.
- Keeping no exchange log. The stack works, but nobody understands exactly how — and the team is afraid to touch it. A log makes every figure explainable.
What if a service has no API?
The data is retrieved by other routes: parsing emails and documents, reading export files, scraping — a program "reads" a page or a document the same way a person does, only fast and without getting tired. Unstructured formats — scans, PDFs, free-form emails — are handled today by AI: it extracts amounts, dates and item names from them with accuracy good enough for accounting, with a human checking the result.
The classic "system with no API" is the Excel spreadsheets that hold half of a company's accounting. They too can be plugged into the stack through file parsing, but more often this is a signal that the area is ready to move into a proper system — we set out seven signs of that moment in our article on when a business should leave Excel behind.
One-off utilities for tasks like this — an export converter, a price-list parser — can now be put together in an evening with AI: how that works and where the limits of the method lie, we covered in our article on vibe coding. In a permanent stack, where a mistake costs money, such utilities are replaced by engineered adapters with queues and a log.
How do you stay compliant with 152-FZ when connecting systems?
Keep the data inside Russia and check whose server the exchange runs through. Since May 2025 a company's first personal data leak costs it a fine of 3–15 million rubles, and a repeat one a turnover-based fine of 1–3% of annual revenue. Integration is precisely the point where client data starts moving between systems, and the route of that movement needs to be controlled.
The main pitfall is intermediary builder platforms: inside them the data physically passes through the platform's cloud, frequently a foreign one. For enquiries containing names and phone numbers, that is already 152-FZ territory. Before connecting any intermediary it is worth answering one question: where geographically will a copy of your data end up.
A stack on your own infrastructure or on servers inside Russia closes that question: data moves directly between your systems, access is split by role — who sees and changes what — and sensitive information does not leave the perimeter without sign-off.
Which link should you start with?
With the most expensive manual one. Usually that is "bank to accounting" (the accountant posts payments by hand), "enquiries to CRM" (leads get lost in chats) or "warehouse to sales" (managers sell what is not in stock). One link takes weeks of work, the effect is visible immediately, and from there the stack grows one step at a time.
A plan for the first step:
- Write down every place where data is moved by hand: from the bank into accounting, from email into a spreadsheet, from the spreadsheet into 1C.
- Calculate the price of each transfer: employee hours per month plus the cost of errors and lost enquiries.
- Pick the single most expensive link and assign an owner system for that data.
- Run the exchange in parallel with the manual process: for a couple of weeks the figures are reconciled and trust in the stack grows.
- Add monitoring: a broken exchange should be visible on the day it breaks, not a month later through discrepancies.
A connected stack is the foundation of management reporting: when data flows on its own, the owner's dashboard shows the state of the business in the moment, without waiting for the monthly report. And where integrations sit on the wider map — from choosing the first process through to AI — we covered in our guide business automation: where to start.
If you would like to start with an audit of your own "zoo", tell us about the task: we will work out which manual links cost the most and propose a plan with a target expressed in money. We build the stack on your infrastructure or on servers inside Russia and support it after handover — adapters are updated when external services change.
Sources
- Okta: Businesses at Work 2025 — the average number of applications per company reached 101
- MuleSoft: Connectivity Benchmark Report 2025 — 897 applications in a large company, 29% integrated
- SberAnalytics and Sber Business Soft: research on automation in Russian companies, November 2025
- hh.ru: survey on time spent on non-automated reports and reconciliations, 2025
- 1C: Developer Guide, chapter 17 "Integration with external systems" — HTTP services and OData
- ConsultantPlus: fines for personal data leaks from May 30, 2025
- Mediascope: data on Telegram usage in Russia, 2025
Frequently asked questions
We run an old, heavily customized 1C configuration. Can it be integrated?+
In the overwhelming majority of cases, yes. Since version 8.3.5 the 1C platform has supported data exchange through HTTP services and the OData protocol out of the box, and for heavily customized configurations an adapter is written — a layer that translates your database into the language the other systems speak. The project starts with an audit of your specific database.
Is integration safe? Will our data pass through someone else's services?+
It depends on the approach. Intermediary builder platforms route data through their own clouds, often located abroad — for personal data that is a risk under Federal Law 152-FZ. A stack on your own infrastructure or on servers inside Russia removes that risk: data moves directly between your systems, access is split by role, and sensitive information does not leave the perimeter without sign-off.
What happens if one of the services changes its API?+
Exchange with that service stops, but with the right architecture no data is lost: it accumulates in a queue and is delivered once the adapter is updated. That is why the stack needs monitoring — a failure is visible immediately, not a month later through discrepancies — and ongoing support: a team that updates adapters when external services change.
How is integration different from moving to a single all-in-one system?+
Integration keeps the tools people are used to and connects them through data exchange — rollout goes step by step, one link at a time, without stopping the business. Moving to a single system means data migration, retraining everyone and months of implementation. That is justified when your current systems duplicate each other or are dying, not when they are simply poorly connected.
How long does the first integration take?+
One link between two systems takes weeks, not months: automatically posting bank payments into accounting, say, or passing website enquiries into the CRM. The timeline depends on data quality and on whether the systems have APIs. The benefit appears with the very first link — after that the stack grows one step at a time.