Setting Up Commercial Proposals in Bitrix24: Templates and Automation

Setting Up CP in Bitrix24: Where the Commercial Proposal Breaks

Setting up a CP in Bitrix24 most often breaks not at the stage of template layout, but at the junction between the deal, product line items, and the document.

A manager assembles the proposal manually: copies the composition from the card, edits prices in the table, and separately adds payment terms and timelines. Each such action is a point of divergence.

The client receives a file where the total does not match what was discussed in the correspondence, and the discount is calculated based on an old price list.

The second typical error is document versions. The proposal goes out to the client, then is edited "quickly" and sent again, but the manager, the supervisor, and the client each have three different files in hand.

In a dispute, it is impossible to prove which revision was agreed upon, and only the latest, already outdated one remains in the CRM. CP automation begins with the document ceasing to be a separate file and becoming a linked entity of the deal.

The third failure is commercial proposal templates without binding to data. If a template does not pull the details, order composition, and terms from the card, it saves time only on layout but does not eliminate manual transfer.

Let's break down how this is closed: which fields are synchronized with the deal, how versions are recorded, and what to check before sending to the client.

What automation of proposal preparation delivers

Automating proposals in Bitrix24 eliminates manual document assembly: the template pulls data from the deal card, product catalog, and price list, and the manager only verifies the terms.

The speed of proposal preparation drops from hours to minutes — a typical proposal takes a single pass instead of reassembling it from someone else's files.

A single source of prices and terms is the key effect. Discount matrices, rates, delivery terms, and timelines are stored in one place and inserted into the document automatically, so the commercial proposal no longer contains prices from an old version of the price list.

Fewer errors follow: no manual copying of line items, no discrepancies between the calculation and the text, no typos in company details.

Fewer edits on the client side means fewer approval cycles.

When the structure, wording, and formatting are fixed by the template, and the calculation is assembled according to rules, the "fix the price" and "the discount is different here" bounce-backs almost disappear. The manager sees which proposals went out, with what terms, and at what stage they are.

Next, we'll break down how this works: from templates and substitution rules to scenarios that prepare proposals without the manager's involvement.

Configuration options: templates, robots, external systems

The choice of approach is determined by how much the quote depends on data from the accounting system and who in the company is responsible for issuing it. Below are three approaches that actually work: from a simple template to integration with an accounting system. There is no "better/worse" between them — they are different classes of tasks.

In practice, a combination is most often assembled: the template is responsible for the appearance, robots handle population and the approval route, while prices and product items come from the accounting system.

Then the manager does not rewrite the price list manually, and the quote does not diverge from what will be seen in the invoice and contract.

The key question when choosing is where the source of truth for price is. If it is the deal card, templates and robots are enough. If it is the accounting system, exchange is unavoidable, otherwise every price list edit turns into manual reconciliation. Let's break down how this is handled in each option.

Implementation stages: from audit to handover of regulations

The work proceeds in sequential blocks: first we record the current sales process and the points where the commercial proposal is generated manually, then we design the target scheme, and only after that do we touch the settings.

This order eliminates the situation where templates have already been reworked but the data in the CRM for them is not prepared.

1. Process survey. We analyze who prepares the proposal and at which stage, which deal fields and product items are involved, and where data is duplicated between the CRM and the accounting system. The output is a map of the current process with a list of manual operations.
2. Scheme design. We define the structure of templates, the set of substitutions from deal cards and the catalog, and the rules for calculating discounts and terms. We agree on the logic before work begins — edits at this stage are cheaper than any rework after launch.
3. Setting up templates and rules. We build templates for typical scenarios: standard sale, tender, renewal. We configure auto-filling of fields, linking to deal stages, and generation of the document directly from the card.
4. Integration with the accounting system. We link the nomenclature, prices, and stock so that the proposal includes current items without manual reconciliation. We configure the exchange so that discrepancies do not accumulate but surface immediately.
5. Testing scenarios. We run each template on real deals: checking substitutions, calculations, numbering, and export to the required formats. We separately check behavior with incomplete data — empty fields, missing items.
6. Training employees. We show managers how to generate a proposal from the card, what to do with a non-standard deal, and where to report failures. Training is conducted on their own deals, not on demo examples.
7. Handover of regulations. We provide documentation on templates, calculation rules, and data exchange, instructions for managers, and the procedure for making changes. We establish who is responsible for each block after launch.

After handover, the client's team can independently add templates and change terms without contacting us for every edit. Describe your task — we will come back with an estimate and a plan based on these stages.

What the client receives after setup

Setting up quotes in Bitrix24 ends not with a "checkbox enabled," but with a set of artifacts that remain in the system and work without us. Each item below is something that can be opened, verified, and handed over to a new employee.

• Quote templates — ready-made forms for typical deals: with company details, logo, terms block, and signatures. The template pulls data from the card, so the manager doesn't type it by hand and doesn't leave someone else's company details in an email to the client.
• Substitution rules — mapping document fields to CRM fields: client, amount, line items, discount, validity period. The rules are described in a table "document field → data source → behavior if empty," so that with an incomplete card the document isn't assembled with empty blocks.
• Approval workflows — routes by amount, deal type, and direction: who approves, in what order, what happens on rejection. The workflow is configured for roles, not specific people, — when an employee is replaced, the route doesn't break.
• User instructions — short guides for each role: manager, department head, approver. With screenshots, descriptions of common mistakes, and the procedure to follow if a document went to the client with a typo.
• Operating policies — the rules by which the process lives: when a quote is created, how long before sending approval is launched, who is responsible for keeping templates up to date, and how changes are made to forms.
• Configured access rights — who can see templates, who can edit them, who approves. Rights are separated by roles so that editing a template doesn't turn into an uncontrolled change to the process.
• Integration map — what data comes from 1C and other accounting systems, what is synchronized automatically, and what is entered manually. This removes the question "why is the price wrong in the quote" at the first discrepancy.

On top of that — a change log and a rollback point: you can see who edited a template or rule and when, and you can revert to the previous version if the new form went wrong. Everything listed is handed over in your environment, with a walkthrough using a real deal as an example.

Case: Reducing the proposal preparation cycle threefold

The client is a manufacturing company with a long approval cycle: the manager assembled the proposal manually, requested prices and stock levels from the economist, and copied the specification from the accounting system.

One proposal took from 4 to 6 hours, and discrepancies in part numbers and outdated prices surfaced only after sending — the document had to be reissued and apologies made to the client.

What was changed

We analyzed typical scenarios and built a library of templates for each: standard delivery, project with installation, service contract.

The template pulls in the counterparty details, commercial terms, and section structure from the deal card — the manager selects a variant and works only with the variable part.

We pull the item list, prices, and stock levels from the accounting system via integration: the proposal includes the current part number and warehouse stock at the time of issuance.

What was achieved

The preparation cycle was reduced from 4–6 hours to 1–1.5: the main time goes into negotiating terms rather than assembling the document. Errors in part numbers and prices have virtually disappeared — data is no longer transferred manually but pulled from the accounting system. The share of proposals that had to be reissued after sending dropped from 18% to 2%.

We also set up a version log: you can see who changed the terms and when, and you can revert to a previous revision. The department head sees conversion for each template and understands which commercial terms work.

The project was carried out on Bitrix24 with integration to 1С — the combination covers both document preparation and accounting.

How do Bitrix24 templates differ from external generators?

Bitrix24 templates live inside the same system where deals, products, and clients are already stored.

A commercial proposal is assembled from the fields of the deal card: plug in the data, apply the template, send it to the client — no exports, manual copying, or version reconciliation.

When details or the price list change, one template is edited, and all subsequent proposals are generated with the new data. This is the key difference from the approach where the document is prepared separately and then manually transferred into the CRM.

External generators take on something else: complex layout, unique design for each campaign, non-standard calculation logic.

But for this you have to pay with integration — setting up data exchange, synchronizing reference data, handling discrepancies when part of the data has been updated in the CRM and part remains in the generator.

The more entities involved in the proposal, the higher the risk that the client receives a document with an outdated price or the wrong composition.

In terms of customization flexibility, built-in templates cover most scenarios: variables, conditional blocks, different variants for client segments, automatic numbering, and printing.

If logic is needed that the standard tools cannot handle, it is added in a targeted way — but this is a deliberate extension, not a mandatory condition of operation.

In terms of cost of ownership, the difference shows over the long run. An external service means a separate subscription, its own support contour, and a point of failure: if it goes down, proposal sending stops.

Built-in templates require no separate maintenance and are updated together with the system. In terms of maintenance complexity, the same option wins: fewer integrations — fewer places where something diverges.

The choice comes down to the task. Mass standard proposals with data from the deal are faster and more reliable to assemble with standard templates.

An external generator is justified when unique design or calculation logic that is inconvenient to keep in the CRM is the top priority.

In practice, a combination is often used: the foundation is Bitrix24 templates, and an external tool is connected in a targeted way for a specific non-standard scenario.

Common technical questions about CP setup

Setting up commercial proposal templates lives inside a perimeter where the accounting system, employee permissions, and regular platform updates all sit side by side. Below is a breakdown of typical technical concerns that arise before work begins.

What happens after a platform update?

Updates affect templates, business processes, and integration points — this is the most common reason a CP starts generating with an error or loses some fields.

We keep templates and exchange rules in a separate layer rather than in core modifications, so an update does not break the logic. Before rollout, we run the generation scenario on a test perimeter and record which fields and roles are affected.

How is access to CPs segmented?

Permissions are configured by role: a manager sees and edits only their own proposals, a department head sees a summary for the department, and accounting sees approved documents without the right to change the template.

We separately lock down editing of the template itself and the price reference data, otherwise a single incorrect edit will break the document's appearance for everyone. All of this is tested on real accounts, not on a demo user.

How are already accumulated templates and data migrated?

Migration goes in two passes: first we transfer reference data and historical proposals, then templates and rules. Old documents are preserved in their original form for reconciliation, while new ones are generated according to the updated logic.

After the transfer, we reconcile control totals for positions and amounts to make sure nothing was lost or duplicated.

If you still have questions about your perimeter — describe the task, and we will come back with an estimate and a work plan.

Let's discuss your CP setup task

To make CP setup in Bitrix24 based on your actual process rather than an abstract template, we start with a breakdown: which fields the manager fills in manually, where versions get lost, and at which stage the client waits longest for the document.

Based on this breakdown, we put together a work plan and a timeline estimate — without assumptions of "how it usually is for everyone."

Describe the task in free form — that's enough to get started:

• current process: who generates the CP and at what point, what is filled in manually, where errors most often occur;
• data sources: product and service cards, price lists, stock levels, discount terms — where the CP should pull values from;
• templates: how many document variants are needed, how they differ, whether there are branding requirements for layout and print form;
• automation: whether auto-filling of details, total calculation, versioning, and approval by deal stages are needed;
• integrations: related systems from which prices, client data, or payment statuses come;
• roles and access: who sees drafts, who approves the final version, who is responsible for sending it to the client;
• constraints: strict requirements for the export format, existing customizations that must not be broken.

Based on these inputs, our engineers prepare a work plan: setup stages, checkpoints on your data, the scope of documentation, and the handover procedure to the team. Along with the plan comes a timeline estimate — realistic, with buffer for approvals and a test run on real deals.

Let's discuss the task — we'll come back with an estimate and a plan.