Why AI proposal generation stalls on real catalogs
Almost any automation of proposal preparation runs into the same place: the proposal is assembled by hand from data that lives in four or five disconnected sources.
Line items are in an export from the accounting system, specifications are in the supplier catalog, prices and terms are in a separate spreadsheet, and customer history is in the CRM.
The manager copies rows, checks SKUs by eye, and glues the text together manually, because no single source serves as the reference for the rest.
The first technical failure is the absence of a single matching key.
The SKU in the accounting system, the supplier's catalog number, and the code on the website almost never match one-to-one, while composite items are assembled from components that are not listed as separate rows in the price list.
Without a normalization and fuzzy matching layer, the model pulls specifications from a neighboring item: the row looks correct but describes a different product — and that goes out to the client.
The second is uncontrolled terminology. The same product is named differently across sources, synonyms and abbreviations are not consolidated anywhere, and units of measurement are mixed.
Until there is a managed dictionary of synonyms and rules for normalizing names, AI proposal generation either copies the supplier's wording verbatim or rewrites it so that non-existent options and incompatible configurations surface in the proposal.
The third is versioning of prices and terms. The price list is updated more often than anyone can recheck it, the current version is not marked anywhere, and the discount matrix lives outside the system.
This is exactly where the main share of errors in commercial proposals appears: an outdated price, a lost row, a term from a previous price list. Preparing such a document takes several days, and part of that time goes to rechecking rather than working with the client.
We break down how this is closed: a reference dictionary, item normalization, and generation on top of verified data rather than raw exports.
What changes after implementation: speed, accuracy, coverage
The time to prepare a proposal stops depending on the manager's workload: the request enters processing, and the system assembles a commercial proposal from the deal card, catalog, and communication history.
Instead of several hours of manual formatting, the document is ready to send in minutes, and a standard proposal is assembled with no human involvement at all.
Proposal personalization rests on a single data source.
The system is connected to the accounting system — for example, to deals in Bitrix24 — to the catalog and price list: the assortment, terms, and discount logic are taken from there, while the text is adapted to the industry, scale, and objectives of the specific client.
No one transfers data by hand, so descriptions and figures in the document always match current data.
The reduction in manual work is visible in the share of edits after sending. When prices and terms are inserted automatically, the proposal does not have to be reissued due to discrepancies — the share of returns for revision falls from tens of percent to isolated cases.
A whole class of errors — an outdated price list, the wrong template, a lost terms block — disappears because it no longer has a carrier: manual assembly.
Coverage grows without expanding the team. The manager is freed from formatting and spends time on negotiations, so the volume of sent proposals increases several times over with the same department headcount.
At the same time, the supervisor sees the status of all requests in full, without any being lost in email.
Proposal preparation modes: templates, rules, models
None of the modes replaces the others — they cover different parts of proposal preparation.
Template-based generation maintains the structure and mandatory blocks, solution selection rules determine the composition, and model-based text assembly is responsible for wording tailored to a specific client.
Which one suits your case depends on the number of variables in the deal and on how strictly the text needs to be controlled.
| Mode | When it fits | Applicability boundaries |
|---|---|---|
| Rigid template | Short cycle, standard service, flow of similar deals | Wording does not change for the client's industry and scale |
| Solution selection rules | Catalog of services with explicit applicability conditions | A described catalog is required; rules must be maintained with every change in composition |
| Model-based text assembly | Detailed text for a specific client is needed | Fact-checking and strict structural constraints are required |
| Generation from deal data | The deal has accumulated history, industry, request composition, past agreements | Quality drops where fields are not filled in or are outdated |
In practice, the modes connect into a single loop.
Solution selection rules assemble the composition from the catalog, the model expands each item for the customer's industry and scale, and the template defines an immutable framework — the block of terms, timelines, and liability, which is not rewritten by generation.
Every result is saved with a version and the source deal data, so the proposal can be reproduced, compared with the previous revision, or rolled back if the inputs change.
Implementation stages: from data audit to acceptance on deals
The order of stages is strict: generation starts not with text but with data, and you cannot skip the audit.
If a source returns an outdated price list or an empty field, the model will produce a plausible but incorrect proposal — and the error will go to the client under our name.
- Data audit. We inventory the sources: CRM records, deal history, price lists, catalog, warehouse stock, contract templates. We look at field completeness, duplicates, unit discrepancies, and outdated items — here it becomes clear what is even permissible to feed into generation.
- Data flow diagram. We fix which field comes from where, where it is normalized, and what does not leave the customer's environment. The diagram becomes the basis for integration and the criterion for validating the result.
- Generation rules setup. We set allowable discount ranges and mandatory blocks: validity period, delivery and payment terms. The model varies wording, but not commercial terms.
- Testing on historical deals. We run generation on closed deals and compare with the versions managers sent manually. Every discrepancy points to a rule we did not describe.
- Access and journal. We differentiate rights to change rules and view prices, and enable logging: you can see who received a proposal, when, and on what data.
- Acceptance on real deals. A pilot with a group of managers using metrics: share of proposals sent to the client without edits, preparation time, number of errors in deal terms. Then handover — procedures for updating rules and price lists, manager training, and a person responsible for data quality.
What we hand over: generation rules, diagrams, procedures
An AI commercial proposal generation project is not closed when the model produces its first draft, but when the customer can change the generation rules independently, without us.
Therefore, the output is not a set of settings in a personal account, but a set of artifacts that can be read, versioned, and handed over to new employees.
- Library of approved wording — text blocks by products, industries, and deal stages with a note on where wording is legally mandatory and where variability is allowed; the letter is assembled only from this set.
- Integration diagram — which systems provide data (accounting system, customer database, catalog), in what form, and how often; failure points and behavior when a source is unavailable are marked separately.
- Access policies — who sees templates, who edits wording, and who releases the letter; role-based differentiation and an action log.
- Review procedure — the release order: automatic checking for prohibited claims, guarantees, and personal data, then approval by the responsible person, then sending.
- Solution documentation — assembly logic, field dictionary, and instructions for adding a new product or segment without code changes.
- Set of reference examples — pairs of "input data → correct proposal" used to check quality after every template change.
- Handover procedure — a working session with your team, an acceptance checklist, and a support period after launch.
Each item goes through acceptance: if a procedure cannot be executed without us, we go back and refine it.
Case study: how we accelerated proposal preparation and eliminated errors
Sales department of an industrial supplier: eight managers, 40–60 commercial proposals per week from a catalog of several hundred items.
Before automation, each proposal was assembled manually — rows were copied from spreadsheets, the discount was recalculated, and terms were agreed in correspondence.
One document took from two to three hours, and approximately every eighth proposal went out with a discrepancy in price or configuration.
What we restructured in the data flow
The catalog, discount rules, and standard terms were moved into a single source from which the generator takes data.
The manager fills in the deal card — industry, volume, timelines, set of items — and the system assembles a draft: it selects wording for the segment and calculates the total using the current price list.
Before sending, the document undergoes checks: price, availability, delivery time, and whether terms match the discount. Deal data remained in Bitrix24 — no second source had to be created.
What changed
The average proposal preparation time decreased from two to three hours to 15–20 minutes: the manager edits a ready draft rather than assembling the document.
The share of proposals with discrepancies in price and configuration fell from 12% to less than 1%, and the number of proposals per week grew by about a third with the same headcount.
"Previously we checked every line manually, and something still slipped through," says the head of the sales department.
"Now the system highlights disputed points before sending." "We finally see which wording and terms most often lead to a deal, and we replicate them across other segments," adds the commercial director.
What to do if the catalog, prices, and deals live in different systems
The catalog sits in the accounting system, prices are in supplier price lists, deals and order history are in the CRM, and stock is in the warehouse system. While a manager assembles the proposal, they correct discrepancies manually and notice them along the way.
As soon as AI proposal generation takes over assembly, any discrepancy goes into the document and then to the client — so the question is not the model, but where it gets its data from.
There are three robust ways to work with disparate sources, and the choice between them depends on how often prices change and on freshness requirements.
| Option | When it fits | Limitations |
|---|---|---|
| Live query to sources | Prices change daily, catalog is small | Dependence on availability of all systems: if one fails, the proposal cannot be assembled |
| Scheduled export to an intermediate layer | Speed and resilience to source failures are needed | Data lags by one update cycle; desynchronization monitoring is needed |
| Unified dictionary as a master system | Catalog and pricing rules are shared across all channels | A dictionary owner and a change management procedure are needed |
In any option, the customer needs read-only access to the sources, a person responsible for item matching, and a decision on which system is authoritative when prices conflict.
The ceiling of the entire scheme is set by the quality of the source data. If an item appears in three spellings, and the price is specified without a validity period and pack multiple, catalog synchronization will succeed, but the proposal will still go out with an error.
Input normalization — SKU, unit of measurement, pack multiple, price validity period — is needed before generation gets access to the data.
Common technical concerns and solution limitations
The concerns here are technical, and they surface before the start, not after. Below are direct answers: where generation breaks, how text control is arranged, what happens to data, and who is responsible for an error in a finished document.
How is non-standard nomenclature handled?
Generation relies on the catalog: SKUs, specifications, and compatibility rules. Items without a card are not invented — they go into an exception list for manual revision by the manager.
Who is responsible for text quality and style?
Before sending, the document undergoes checks: mandatory blocks, figures, and deadlines are verified against the source, and prohibited promises are cut off by rules. The final word belongs to the manager, who approves the version.
Where will generation definitely not work?
Tenders with a rigid form, non-standard supply schemes, and unique technical requirements. There, the system assembles a draft and suggests what data is missing, while an engineer completes the logic.
What about data security?
Role-based access differentiation, an action log for each document, and encryption during transmission and storage. Customer data is not used to train third-party models.
Who is responsible if there is an error in the document?
We fix the area of responsibility in the procedure: check rules, templates, and logs are our part; the customer confirms the actual deal terms. The logs make it possible to recover where a specific wording came from.
Let's discuss your task: what to send for assessment and a plan
To come back with a project assessment rather than an abstract range, we need a minimum of inputs. Without them, the scope of work has to be guessed, and at the start of the project the estimate diverges from reality.
- 20–30 commercial proposals already sent: both those the client signed and those that went unanswered — they show which blocks are mandatory and which managers add by hand.
- Data sources for personalization: CRM export, catalog, deal history, and industry attributes of customers. Any table export will do, as long as the fields are visible.
- Description of segments and rules: how a proposal for a large customer differs from a retail one, which terms are inserted automatically, and which are approved by the supervisor.
- Template and formatting requirements: branded blocks, mandatory wording, and volume restrictions.
- Restrictions on generation: what cannot be output without a human — prices, deadlines, guarantees, personal data, and the client's commercial terms.
- Launch scenario: who forms the proposal, from which system it is sent, and whether proofreading is needed before sending.
- Access for work: a test environment and an anonymized copy of data — on these we check text quality without touching the production database.
- Acceptance criteria: how you will measure the result — share of proposals without edits, preparation time, and number of fields filled in automatically.
If some data is closed, tell us right away: we will select a scheme in which training uses anonymized examples, and the production database remains with you.
Describe the task in free form — we will come back with an assessment and a staged implementation plan, with explicitly stated assumptions and what needs to be clarified before the start.
