Building a calculator on 1C-Bitrix with results sent by email

Why the 1C-Bitrix calculator loses leads at the final step

Most calculators lose leads not during calculation, but at the final step. The client goes through all the steps, sees the total amount, clicks "Send" — and receives nothing: neither an email nor a confirmation.

Sometimes the email does arrive, but it is empty: the amount is there, but the calculation parameters from which it was assembled did not make it into the email. To the owner, it looks like "the calculator works," even though the funnel is quietly emptying.

The two most common causes are loss of state between steps and validation only in the browser.

Intermediate values are usually held in the page's memory: the client opened the calculation in a new tab, went back, or refreshed the page — and at the final step an empty set of fields is submitted.

If validation of the calculation fields lives only in scripts on the visitor's side, the server accepts anything: zero quantities, negative values, unfilled required parameters.

The third class of failures is silent. The request goes out, the handler responds "thank you," but the email event in 1C-Bitrix did not fire: the email template lost variables, the recipient address remained a test one, sending through the mail server is blocked.

The client sees a thank-you, the manager does not see the email. Such a failure cannot be caught by eye — only by the error log and reconciliation: how many calculations were completed, how many emails actually went out.

We start by analyzing the lead route as a whole: calculating the cost on the website, sending the form by email, and the email arriving in the manager's inbox. Then we examine how each of these junctions is covered.

What changes when the server performs the calculation, not the browser

When the formula lives in a browser script, the result exists only in the tab's memory.

Refreshed the page, lost the network, switched between devices — the calculation disappeared, the email with the lead did not go out, and there is no way to restore what exactly the client calculated: the database contains neither the input parameters nor the total.

Server-side cost calculation moves the point of failure. The parameters go to the 1C-Bitrix side, the formula and reference data are stored in the configuration, and the total is calculated and written to the database before the email is sent.

A connection loss on the client no longer means losing the request: the form restores the unfinished calculation and completes it, and the manager sees the lead even if the email did not have time to go out.

Calculation reliability stops depending on the device and browser. One version of the formula for all visitors, ranges and coefficients are edited in the admin panel without rebuilding the client side, and the amount cannot be substituted using developer tools.

A whole class of failures goes away — the discrepancy of "one number on the screen, another in the email" and empty requests without parameters.

Form response speed is also a server-side task. Reference data is cached, heavy queries are calculated once, and the response arrives within a time the visitor does not notice: the form does not appear frozen.

The manager receives an email with ready parameters and the total; there is no need to recalculate manually — the first response to the client goes out many times faster.

This is verified at acceptance without guesswork: the results are compared against a reference table for a set of parameters, the connection is forcibly broken — the lead must remain in the database with the correct amount.

Calculation methods: server-side, browser-side, and hybrid

The calculation method determines where intermediate values are calculated, how often the form accesses the server, and what the client will see if the price in the reference data has been updated.

On a form with five fields, the difference is unnoticeable; on a configurator with dependent parameters, the choice of method determines response speed and the number of calculations the server can withstand at peak hour.

The hybrid scheme is a typical compromise: the browser calculates the preliminary cost using coefficients from the form and instantly recalculates it when fields change, while the server validates the data, repeats the calculation using up-to-date reference data, and sends the email.

The client sees a response without delay, and the email contains the amount confirmed by server logic.

The limitation of browser-side calculation is that it sees only data already loaded into the form and does not know about stock balances and rounding in the accounting system.

Therefore, we attach recalculation on field change to the completion of field input or to a short delay, not to every keypress: otherwise the form floods the server with requests that no one reads.

Implementation stages: from form audit to email delivery verification

The work order is fixed: first we analyze what is already on the website, then we design the calculation, and only after that do we touch sending. The reverse sequence produces a beautiful calculator with emails that go to spam or arrive empty.

1. Audit of forms on the website. We collect all data collection points — contact forms, lead forms, subscriptions. We look at which fields actually reach the recipient and where validation lets junk through. The calculator is then integrated into this scheme rather than existing in parallel.
2. Calculation scheme. We describe the formula, the set of coefficients, boundary conditions, and behavior with incomplete data. We fix what is calculated in the browser and what must be recalculated on the server: otherwise the total in the email will diverge from what the client saw.
3. Prototype and logic reconciliation. We run the calculation on control sets of input data and compare it with how your manager calculates the same thing manually. A couple of percent of discrepancy is caught here more cheaply than in a hundred already sent leads.
4. Setting up email notifications. Email templates for the client and internal recipients, copies, an attachment with the calculation result. Separately — the sender domain and SPF, DKIM, DMARC records: without them, the email goes to spam regardless of the layout.
5. Verifying email delivery. Test sends to mailboxes of different providers: readability in email clients, landing in spam, correctness of attachments and Cyrillic in the subject.
6. Handover and instructions. We provide documentation: where to change coefficients, how to add a recipient, what to look at in the logs if the email did not go out. After that, changes to rates and fields do not require rewriting the calculator.

Documentation and settings that remain with you

We hand over not only a working calculator on 1C-Bitrix, but also everything needed to change it without us. The document set covers three questions: how the result is calculated, where it goes, and what to do if the email did not arrive.

The artifacts are stored in the repository next to the code — during further development they are updated together with it, rather than living as a separate file with the manager.

• Calculation rules — formulas, coefficients, ranges, and rounding order in table form: using it, any result can be verified manually in a couple of minutes.
• Data flow diagram — from input in the form to recording the lead and sending the email, with validation, logging, and error handling points.
• Email template with the result — markup and plain-text alternative, list of substitutions, subject and sender address settings.
• Lead processing regulations — who responds and within what timeframe, what to do in case of a duplicate, an undelivered email, or a mail service failure.
• Administrator instructions — how to add a field, change a coefficient, view the sending log, and reissue the template without editing code.
• Configuration description — where the mail service keys are stored, what permissions the administrator role needs, and how to enable resending.
• Acceptance scenarios — a set of checks by which you can verify the calculation yourself after release and during the next platform update.

We write the documents in your team's language: without being tied to a specific developer, with examples of completion. If calculation rules or the recipient address change after handover, the edit is made in one place, and the calculation and the email remain consistent.

Implementation example: calculating order cost for a manufacturer

Where we started

A manufacturing company calculated orders manually: the manager clarified the material, thickness, and quantity, then compiled prices from a price list of 60+ item positions.

One calculation took up to half an hour, and on peak days — noticeably longer, and some clients went to those who responded faster.

The form on the website sent an email through an external service, and the calculation result was not saved anywhere — if the email did not arrive, there was no way to restore the lead.

What we changed

We moved the calculation logic into a calculator on 1C-Bitrix: the client selects product parameters, immediately sees the cost and timeline, and the result goes by email and is simultaneously saved in the database along with all selected parameters.

We redesigned sending so that the email is generated on the website side and duplicated into the request — the lead is not lost even if the external mail service returns an error.

The manager receives a request with a ready amount and does not ask again for what the client has already specified.

Metrics before and after

• Share of delivered requests — from ~70% to 99%: losses during sending practically disappeared.
• Time from calculation to manager response — from several hours to 15–20 minutes.
• Manual clarifications per lead — from 3–4 to one: parameters are recorded at the time of calculation.

Additionally, a calculation log appeared: you can see how many requests passed through the calculator and at which step clients most often leave. This provided material for the next form revision — based on actual behavior, not guesses.

What to do if the calculation is already done, but leads are still being lost?

If the calculation on the website is computed correctly, but leads do not arrive, rewriting the calculator is usually not required: it is not the arithmetic that is lost, but the transfer of the result.

Diagnosing an existing calculation takes one pass — the engineer goes through the scenario as a visitor, leaves a test lead with a separate mailbox, and sees at which step the chain breaks.

The bottleneck of the form almost always lies at the boundary between calculation and lead intake.

Typical causes: a field with the amount or configuration arrives in an unexpected form and the handler discards it during data validation; sending hits the mail server limit; the email goes to spam because of an unsigned domain; the lead is not saved anywhere, so if mail fails there is no trace of it.

An end-to-end scenario check shows exactly where the result is lost.

We analyze the event log and mail log, compare the sent email with the record in the accounting system, run the form with empty and boundary values, repeat sending when mail is unavailable — and get a list of failure points with reproducible conditions.

Then the decision is made based on facts, not habit. If the formulas, reference data, and calculation logic are correct, we refine only the transfer: first saving the lead in the database, then notification and a retry queue.

Rebuilding is worth it when the logic itself cannot be corrected — it is duplicated in several templates, does not validate input data, or diverges from prices in the accounting system.

Frequently asked questions about the calculator and sending the calculation

Launching a calculator on 1C-Bitrix is the beginning of operation, not the final point. Below are technical questions that most often come up during acceptance and in the first months of operation.

Emails land in spam — is this solved on your side?

Yes. We send through a separate subdomain with domain verification and signatures by which mail services verify the sender.

We separate the email to the client and the copy to the manager into different templates so that bulk mailings do not drag transactional emails under filters.

What happens if the mail server is unavailable?

The calculation will not be lost: the lead is queued and retries sending, and the result is saved in the database with a status. The manager sees the calculation in the panel even during a mail failure, so the client is not left without a response.

Who is responsible for keeping calculation formulas up to date?

The formulas are your area: you know the rates and rules. We make them portable — coefficients, steps, and discounts are stored in settings, not in code, so the price can be edited without a developer. After each edit, we run tests on boundary values.

Let's discuss the task: what to send for an estimate and work plan

To come back with a work estimate and implementation plan, a finished document is not needed — the customer's initial inputs that are at hand are enough. From them, the volume of formulas, the number of dependencies between fields, and how long approval will take are clear.

• Current calculation. How it is calculated now: a table, a file, or the manager's verbal procedure. A file or screenshot is enough — we will restore the logic.
• Cost rules. Formulas, coefficients, ranges, rounding step, behavior with zero values and minimum order.
• Fields and types. What the visitor enters — dimensions, material, quantity, timeline; what is required and what depends on the previous choice.
• Condition matrix. Combinations where the result is calculated differently: non-standard size, urgency, region, surcharge for options.
• Email examples. Two or three emails with results that go to clients: subject, email body, attachment with the calculation.
• Output point. Where the result goes: sales department address, copy to the client, export to CRM, or file for the manager.
• Constraints and deadlines. What cannot be shown to the client, who approves edits on your side, and by what date the launch is needed.

This is enough to fix the calculation task statement, mark controversial points, and come back with a plan: stages, our area of responsibility, what is required from you, where access will be needed, and who accepts the result. Describe the task — we will send an estimate and work plan.