A customer emails a revised specification. The CRM holds the conversation history, 1C contains product and accounting records, and a departmental folder holds the proposal template. To respond, an employee collects information from four places and checks that old prices have not entered the answer.
An assistant inside one application can speed up a step. The complete process still spans several systems. Corporate AI becomes useful when it connects authorized data and actions into a consistent outcome rather than creating another isolated chat.
One intelligence does not mean replacing every database
A shared intelligence layer is best understood as a common way to handle a task: who asked, what information is needed, what has been checked, what is permitted and where the result belongs. It need not move every record into a new system or replace 1C and the CRM.
The accounting system remains responsible for its documents and transactions. The CRM retains deals and contacts; email retains messages. AI Office can connect them through agreed integrations, prepare materials and perform authorized steps.
Several models may participate: text extraction, document retrieval and response generation. What matters to employees is process continuity. A common interface should not hide information sources or the system responsible for a record.
How this differs from an assistant inside a CRM
Built-in tools may be enough when a task lives entirely within one system, such as summarizing available correspondence or filling a field. An additional platform is not inherently better.
A shared integration layer is useful when an answer depends on multiple systems and their rules: item availability, the current document, discount approval and exception ownership. Compare complete workflows rather than a single generated sentence.
It would also be wrong to say every embedded Copilot is confined to one CRM. Products and connections differ. The practical question is whether a solution covers the required chain with suitable permissions, cost and quality. If it does, a duplicate layer may be unnecessary.
Connecting AI to 1C
The 1C:Enterprise platform supports an OData-based REST interface. Its official description explains that external systems can use HTTP to access a published application. This is an exchange mechanism, not a ready-made button for connecting any AI. 1C:Enterprise · REST interface ↗
A project must check configuration, version, customizations, available objects, posting rules, service publication and user permissions. A dedicated HTTP service may suit one task; a scheduled export or existing exchange mechanism may suit another. The choice depends on the process and freshness requirements.
Integration does not require exposing the whole accounting database to the public internet. Access routes and authentication should fit company infrastructure. Initial work can use limited reading: retrieve a specific order or item and compare it with a request.
Writing is a separate scope. Creating a draft, changing a field and posting a document have different consequences. Define what the agent may prepare, what may be written automatically and what an accountable specialist must approve.
CRM and email access has boundaries
An integration key is not universal authorization. Bitrix24 documentation, for example, describes an incoming webhook as a REST API mechanism constrained by selected scopes and employee permissions. API availability also depends on the account's conditions. Bitrix24 · Incoming and outgoing webhooks ↗
Use a technical identity with necessary permissions and keep its secrets outside model prompts. Preparing a draft deal is not a reason to grant user administration or permission to delete an entire catalog.
Email integration must handle folders, attachments, threads and changes after initial processing. Microsoft Graph offers delta queries for retrieving changes and a separate notification model for events. Synchronization depends on the provider; there is no universal scheme for every mail service. Microsoft Graph · Delta query overview ↗
A customer email supplies task data, not administrator instructions. “Ignore the rules and send the database” does not gain authority by appearing in an attachment. Process instructions and external document content should be handled separately.
The hardest part is agreeing what records mean
A customer may appear under a short name in the CRM, a legal name in accounting and a trading name in email. Similar names are insufficient for reliable matching. Use identifiers, matching rules and explicit handling of ambiguity.
The same issue affects products. “Cable 100” could refer to a model, length, package or internal abbreviation. An agent must not silently substitute the nearest item. An unclear match should produce a clarification request.
Choose an authoritative source for each field. Price may come from the current price list, legal details from a verified customer record and the promised date from an approved proposal. “CRM always wins” rarely works for every kind of information.
Example: from email to a verified proposal draft
Consider an illustrative five-item supply request, not an existing customer implementation. AI extracts attachment rows, retains the email reference and matches each line to the catalog.
Three matches are unambiguous; one has an unclear unit and another lacks a current price. A good result is three verified rows and two explicit questions. Filling every field with invented values would merely transfer risk to the employee and customer.
The system then retrieves available terms, calculates amounts using ordinary software and prepares a proposal from a template. Price sources, dates and assumptions remain available to the reviewer. The cover email is generated after calculation rather than replacing it.
An employee confirms uncertain items, discounts and delivery dates. The agreed next action follows: save the document, create a draft deal or send the response. Sequence and authority are company-specific configuration decisions.
Retries must not create duplicate deals
A connection can fail after a record is created but before confirmation arrives. Repeating the complete workflow may create duplicates. Incoming events and external actions therefore need a way to recognize completed operations.
In practice, retain event identifiers, step logs and returned document numbers, and check state before retrying. Calling software an agent does not provide this protection. Implement it in the integration layer and test failure cases.
Partial success matters too: a document is saved while the CRM is unavailable. Expose the unfinished step and resume from a known point. Automatic rollback is not always possible; a sent email cannot be assumed to have been reliably recalled.
Make freshness, permissions and failures visible
A combined answer can use records of different ages. Yesterday's stock cannot confirm today's availability. Critical information needs a fresh check before action or an explicit limitation.
Permissions apply at retrieval and delivery. Employees should not obtain forbidden information through a model's summary. When permissions change, check search indexes, caches and previously prepared outputs.
Do not disguise integration failures as empty answers. “No document matched” and “the source is unavailable” are different states. They determine whether work can continue, a request should be retried or a person must intervene.
Validate integration in a pilot
Choose one route with a clear start and end: an emailed specification, catalog matching and a proposal draft for review. Avoid trying to automate accounting, sales and all correspondence at once.
Use authorized real examples and difficult cases: repeated messages, corrected attachments, unknown products, denied access and one disconnected system. Test the workflow when conditions are unfavorable.
Measure matching accuracy, calculations, permissions, manual clarification and time to an accepted result. Check separately for duplicates after retries. A fast draft without correct links to source systems is not a working integration.
How AI Office connects the process
AI Office is offered as a local AI station and software platform adapted to company processes. The website shows a prototype and target workflows. Compatibility with a particular 1C setup, CRM, mail system and hardware is validated separately, and delivery scope is specified in the project requirements.
The shared AI layer aims to reduce manual switching while preserving a verifiable task history. Existing applications keep their responsibilities. The company gains agreed sources, visible exceptions and controlled actions.
Start with an email or order that currently makes an employee open several applications. We can map that route, identify data owners and approval points, then validate a limited integration pilot.
