Commercial proposal automation: where the process breaks
A manager assembles a commercial proposal manually: item list copied from the catalog, prices from the price list, terms from correspondence on a similar deal.
One document takes several hours, and the request itself all this time lives in email and is nowhere recorded as a task with a deadline.
Approval of prices and discounts happens there too, in emails: the manager receives a figure without calculation history and sends it back for clarification, and the manager waits for a response.
Response speed to the client drops to a day or more — during this time they manage to collect proposals from competitors and compare terms, while the original price and discount are confirmed already outdated.
A separate problem is different versions of the document. Edits are made in a copy of the file, the total in the spreadsheet is recalculated manually, and no one can say with certainty which version went to the client.
If volume or discount changes after sending, the calculation is redone, and some requests are lost at the calculation stage — they are simply not counted.
The cost of such a process is not only the manager's hours, but also deals that are lost silently, without a clear reason for refusal. Below we examine how this is closed: at which step time is lost and what needs to change in the chain.
What automation delivers: effect on timelines and quality
Preparing a commercial proposal is assembly from different sources: prices in one file, terms in another, discount approved in correspondence.
Automation changes the principle itself: the manager selects the client and line items, and the system inserts current prices, terms, and template. The preparation cycle shrinks from hours to minutes, and edits are made before sending, not after.
A single price source is not a shared folder, but a reference data system with access rights, change history, and linkage to customer groups. A price is edited in one place and immediately appears in all proposals; a document sent a month ago will not diverge from today's. This also removes the eternal question of whose price version is correct.
Calculation is the most frequent source of discrepancies: percentages of base, discounts, taxes, and rounding on a long specification. According to industry estimates by Deloitte, a notable share of errors in commercial documents arises precisely from manual data transfer.
The system calculates by formulas and reconciles the total with the deal terms, so reducing the share of calculation errors is achieved not by attentiveness, but by validation at the assembly stage.
Repeat customer requests are handled separately: a similar configuration is assembled from deal history in a couple of steps.
As a result, a whole class of rejections disappears — a proposal no longer goes out with an outdated price, someone else's terms, or an arithmetic error in the final total.
Document assembly options: comparison of approaches
The assembly mode is chosen not by the "power" of automation, but by deal variability and flow volume.
The three modes below are not maturity levels, but different trade-offs: the more fields taken from the deal card, the less manual input and the stricter the requirements for data cleanliness.
Let's separately note the limitations of automation. As long as the deal is standard, the set of blocks, payment terms, and timelines are assembled without edits.
As soon as non-standard deal terms appear — installments, tying payments to stages, warranty clauses — the assembler creates a draft and gives it to the manager for confirmation rather than sending it directly to the client.
| Option | When it fits | Limitations |
|---|---|---|
| Template with manual filling | Up to 15 proposals per month, terms are unique each time, the manager knows the product well | Time grows linearly with the number of deals; versions diverge — outdated terms and timelines end up in the sent file |
| Generation from deal data | Regular flow, deal fields are consistently filled in the system | Document quality depends on how complete the card is; non-standard wording and clauses have to be edited manually |
| Event-driven flow assembly | Deal stage change, repeat customer request, or recalculation after line item changes | An error in source data is replicated across all documents; a version log is mandatory — who changed what |
Practical conclusion: a hybrid mode covers most scenarios — generation from deal data plus mandatory confirmation on line items with non-standard terms.
This way standard proposals go out in minutes, and the risk of sending incorrect terms to the client remains with the manager, not with automation.
Implementation stages: from process review to handover
The order of stages here is not a formality. If we start with text generation, we will get neat documents with incorrect figures, and we will have to sort it out with live customers. First we record how the sale actually works, and only then transfer that logic into the system.
- Sales process audit. We examine who prepares the document and at which step, which approvals the discount goes through, and where the proposal is delayed the longest.
- Data source map. We record where prices, stock, customer terms, and deal history come from, and which rule applies when systems diverge.
- Calculation and discount rules. We transfer into explicit logic what previously relied on the manager's experience: discount limits by category, option costs, deferred payment terms. Exceptions remain, but with a clear approval threshold.
- Pilot on one document type. We launch generation on one template and one product group — discrepancies are visible on live deals while the scope is narrow and edits are cheap.
- Validation on historical deals. We run closed deals through the new rules and compare the result with actual documents. The match rate is an objective readiness criterion, and discrepancies show which rule is described incompletely.
- Handover to the customer's environment. We provide regulations, access, and instructions for managers, and set up error notifications. The system remains within your processes, not on our test bench.
What remains with the customer: configurations and regulations
Along with the solution, you retain everything that describes its behavior: generation rules, assembly scenarios, access rights, and regulations. The settings are structured so that the team changes them without our help, rather than developer rules. Below is what exactly is recorded during handover.
- Generation rules description — which blocks are mandatory, which depend on segment, amount, and payment terms, and which are populated from the deal card. The rules are stored as a separate set, not in code, so the process owner changes the wording.
- Configured assembly scenarios — one for each proposal type: initial, repeat, tender, partner. The scenario defines data sources, trigger conditions, and block order.
- Templates and wording library — branded formatting with field substitution and ready text variants by segment; edited without rebuilding the solution.
- Access control — roles for manager, supervisor, and rules editor: who launches assembly, who changes rules and templates, who sees history. Rights are assigned by role, not manually to each person.
- Document handling regulations — versioning, approval points, retention periods, and the procedure for replacing or withdrawing a document. Manual steps, if any remain, are described separately.
- Instructions for the sales department — how to launch assembly, what to check before sending, how to submit for revision, and where to look when data diverges.
- Change log — who and when changed rules, templates, and access; in a disputed situation, the cause of the discrepancy is visible.
Case study: tender packages instead of manual assembly
The sales department assembled the first tender packages manually: details from the deal card, descriptions from old emails, attachments from a folder on a shared drive.
One package took 6–8 hours, and every third one came back for revision due to the wrong template, an outdated version, or a missing attachment. With a flow of about ten requests per month, some tenders never reached sending — there simply wasn't time to assemble them.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Tender package assembly | 6–8 hours of manual work | 40–60 minutes, most of which is review |
| Discrepancies in documents | Every third package went for revision | Isolated cases, found during review |
| Data sources | 5–7 scattered files and folders | Deal card and block library |
| Reuse of wording | Copying from past emails | Ready blocks with versions |
| Manager's role | Full manual assembly | Verification and confirmation |
The mechanics changed not in the volume of text, but in where effort is applied. Deal data is pulled from Bitrix24 — details, delivery scope, terms; wording is taken from a library of ready blocks with versioning, so reuse does not turn into copying outdated versions.
The system assembles a draft and leaves unfilled fields visible — they are found during review, not at signature.
Human review of the document remains a mandatory step: the manager verifies the scope, terms, and attachments, after which the package is recorded as the final version. There is no auto-send — the decision always rests with the responsible person.
"Previously I learned about a problem in the package from the client. Now the manager brings a ready document, and my review takes ten minutes instead of an hour," — sales department head.
How is template substitution different from semantic generation?
Variable substitution is a deterministic operation: there is a template, there is a reference of values, and the output is the same document for the same data.
It is predictable and easy to verify by line-by-line version comparison, but the structure and logic of the text are predefined and do not adapt to the composition of a specific deal.
Semantic generation from the deal goes from a structured description: line item composition, customer industry, negotiation stage, constraints, and typical objections. Wording is assembled for this context, not selected by branching conditions.
The block about timelines and work procedure differs in content for a distributor and for a manufacturing holding, not by a substituted name.
Both approaches break on typical document errors. Substitution produces residual fragments of someone else's template, desynchronization of units and timelines between sections, different spellings of the same organization, and unstated assumptions.
Generation adds its own class of risks — variability where literal precision is needed: details, dates, payment terms, warranty wording.
That is why in the working scheme we take immutable fields by substitution from the reference, and semantic blocks — rationale for choice, description of the effect, answers to objections — we generate.
On top, validation is applied: mandatory field checks, document version reconciliation, and a checklist before sending.
The guideline for choosing is simple. If most of the text repeats from deal to deal, substitution is enough. If the composition of the argument changes, semantic generation is needed with strict constraints on immutable fields.
According to reviews of typical errors in commercial documentation, most defects are not about style, but about data inconsistency between sections: wording quality begins with all numbers and timelines having a single source.
What is clarified before the start: limitations and risks
Before the start, we address technical doubts that most often come up at the second or third meeting: how the solution will behave on your accounting database, who is responsible for an incorrectly calculated line in the document, and what counts as the result of the first stage.
Below are five questions we ask ourselves so as not to move them into the middle of the work. For each, we agree on the acceptance criterion in advance.
We have several accounting systems — where do we start?
We start with a source map: where prices, stock, deal history, and discount rules are stored. If data diverges between systems, we fix source priority and build an intermediate layer — then generation reads already reconciled data, not "whatever comes out."
What to do with non-standard terms and manual clauses?
Standard line items go into the rules, non-standard ones into an editable block with a clear note that calculation for them requires the manager's involvement. This way automation does not replace expertise, but stops slowing down on every deal.
How are calculations verified?
We calculate control examples on historical deals and reconcile the total with what was issued manually. A discrepancy is not a reason to "fix it by eye," but a signal to find the rule that produced it.
Who is responsible for an error in the finished proposal?
We distribute responsibility by stage: data collection failure, calculation logic, and final sending are different zones. The contract records which classes of errors the system covers and where human review is mandatory.
What will the first stage be?
The first stage is a limited scope: one product flow or deal type, with measurement of preparation time and the share of documents without manual edits. Then we expand based on results, not according to a plan.
Let's discuss the task: what to prepare for the conversation
To make the estimate and work plan rely on facts rather than guesses, it is enough to gather a few things for the conversation. Describe the process in your own words and attach examples — we will clarify the rest in dialogue.
Input data for the estimate:
- 5-10 commercial proposals that you consider successful, and 2-3 weak ones — they show the target style, structure, and acceptable boundaries;
- data sources: catalog, price lists, discount and timeline terms, where the system should take line items from;
- template and formatting requirements: mandatory blocks, legal wording, brand elements;
- approval rules: who checks the proposal before sending to the client and at which stage;
- limitations: prohibited wording, confidential data, requirements for where materials are stored;
- scope of work: how many proposals you prepare per month and what deadline the customer needs a response by;
- access: a test environment of the accounting system or anonymized export to test the solution on your data.
We discuss the implementation stage order at the first meeting: current process, prototype on your materials, approval of verification rules, launch into the working environment, and employee training.
After the review, we will return with an estimate and work plan — with timelines, team composition, and control points.
We are ready to discuss the task in a convenient format: describe it in free form — that is enough to start.
