- Most customer-data systems are just notebooks. They record everything but never help close a sale any faster.
- What the sales team really needs is an assistant that drafts the proposal, puts in the correct prices and knows what has sold well in similar cases.
- What you need first is one real version of your prices and terms, kept in a single place, instead of everyone working from their own file.
Where old websites and apps stop
The customer-data systems many companies buy work like expensive notebooks. Salespeople fill in what they've discussed, but the system never helps write a single proposal. So salespeople still copy an old file and edit it line by line, just as before.
A traditional CRM stores information after the conversation, but salespeople still assemble proposals from several files. Knowledge of pricing, scope and exceptions lives with a handful of people.
Slow proposals usually have less to do with how well people write and more to do with information scattered across old presentations, price sheets, emails and the memories of a few people. In the rush to close, sales may use different versions of the terms, pick a solution the delivery team can't deliver, or write a contract so vague that the problems surface after the sale.
An AI Proposal Configurator should therefore help people think and check for consistency, all the way from receiving the brief, turning needs into requirements, laying out options, calculating the price and choosing approved wording to requesting approval for exceptions. Producing documents as fast as possible is a secondary goal. The main one is a proposal whose reasoning can be traced, along with the person who confirmed each point.
| The old way | The new AI product approach |
|---|---|
| Call summaries, follow-up reminders and email templates | Turns discovery into a Requirement Map, builds solution options, checks product and price rules, drafts the proposal and opens approvals according to risk |
AI is good at reading and drafting, but prices, scope and contract clauses must come from systems and rules that can be checked. Connecting the CRM, catalog, rate card and approval flow therefore matters more than choosing the model that writes the most elegant prose.
New capabilities a business can put to use
An assistant that's actually useful knows what situation this customer is in and which proposals closed similar cases before. It then drafts the first version with prices pulled from the real system, so the salesperson only has to check and adjust.
What the project is
Users start from an opportunity in the CRM or from meeting notes. The system helps pull out the pain, requirements, constraints, stakeholders and deadline, then shows the gaps for the salesperson to fill in before choosing solution modules and building the outline of the proposal. The screen should stay open to human editing and keep the link between each requirement and the wording in the document.
Key features
Features may include a Discovery Assistant, Requirement Matrix, Solution Configurator, pricing and discount rules, a Clause Library, Capacity Check, Approval Flow, Document Generation and Version Comparison. Managers can see at once which lines differ from the standard and which items are waiting on the person responsible.
Technology and integration
The system needs to connect to the CRM, the Product Catalog, the Rate Card, the ERP or delivery-capacity data, and a versioned document library. AI helps summarize and draft the wording, while the logic for pricing, compatibility and approval authority should sit in a Rule Engine that can be tested. Every claim should trace back to a requirement or a reference source.
Benefits beyond speed
Salespeople spend less time hunting for information and have more room to think strategically. Executives can control margin and exceptions, and the delivery team receives work with a clearer scope. The system also works as a coaching tool, showing new staff which questions to ask and why certain kinds of proposal don't fit.
- Meeting-to-Requirement separates pain points, constraints and decision criteria
- A Proposal Configurator that assembles only what can be delivered
- A Risk Reviewer that flags promises, scope and information not yet confirmed
- Win/Loss Learning that feeds the reasons back into the playbook
Hypothetical case
What it looks like in practice
A technology services company has an agent summarize the meeting and build three options to fit the budget. The system checks the rate card and capacity before drafting the proposal. Cases with special terms go to a director for approval.
In this hypothetical case, a systems company has to put together a proposal covering several branches. The AI reads the meeting notes and builds a Requirement Matrix that separates what the customer confirmed, the assumptions and the open questions. The configurator finds that the schedule the salesperson chose clashes with capacity, so it proposes a phased plan instead of letting the document go out.
When the salesperson asks for a discount beyond the allowed range, the system shows the effect on margin and the terms that could be traded for it, such as a smaller scope or different delivery rounds, instead of refusing like a black box. The approver sees the whole context on one screen, and the final document records who confirmed which exception.
Promise-to-Delivery Check
Every promise in the proposal must be linked to an owner, capacity, an assumption and acceptance criteria.
If it can't be linked, show it as a question rather than writing it as a commitment.
Scope, risks and how to measure results
For the development team · Technical metrics
Never use AI to generate prices, legal terms or guarantees from probability. This information must come from a source with a clear owner and version. Metrics should cover Proposal Cycle Time, Rework, Approval Delay, Margin Deviation and Scope Dispute after the deal is won, because a document that goes out fast but creates a delivery burden doesn't count as a success.
AI can produce a proposal that reads well but misses the context. Never use customer data across accounts, and keep versions of prices and documents.
For the development team · Technical metrics
Metrics to track: Proposal Cycle, Approval Rework, Scope Error, Win Quality and Handoff Completeness
- Discover: follow the real work and collect examples of normal cases and exceptions
- Assist: let AI draft or recommend while people stay in control
- Act: turn on tools one at a time after the test set passes
- Scale: expand once monitoring, fallback, cost control and an owner are in place
Fall back to Assist Mode if the wording has no trace to a requirement, prices don't match the rate card, or the delivery team often has to fix the scope after a win. Those are signs the system isn't ready to generate final documents automatically.
BUSINESS & PRODUCT READINESS
A good proposal connects what the customer wants with what the team can deliver
For the development team · Technical detail
Before using AI to draft proposals, build traceability from Pain → Requirement → Solution Component → Assumption → Acceptance Criteria. If any part has no owner or evidence, show it as an Open Question. This prevents proposals that read smoothly but sell a scope Delivery never confirmed.
For the development team · Technical detail
Prepare the rate card, product rules, clauses, capacity signals and examples of proposals that passed and failed. Separate the information AI uses to suggest options from the rules the system must calculate exactly, then set approvals according to risk, for example for discounts, data access or special timelines.
For the development team · Technical detail
Complete the Traceability Chain from Pain → Requirement → Solution → Assumption → Acceptance first. If wording in the proposal doesn't answer any requirement or has no source, the system should raise a warning instead of inventing reasons after the fact. Standard wording should also be kept apart from the parts salespeople write for a specific customer, so changes stay under control.
Start with a proposal type that comes up often and has a fairly stable structure. Gather good examples, examples that had to be corrected, and the reasons exceptions were approved, then have AI help draft in Assist mode first. Once the team trusts the tracing and the checks, turn on Document Generation or automated workflows.
Which promises often cause rework?
Where do the real prices and clauses live?
Who confirms capacity before a proposal goes out?
How is customer data kept separate between accounts?
Turn the sales playbook into a system that helps people think without boxing in their skill
DNA Maker works with Sales, Pre-sales, Product and Delivery to map the Proposal Journey and a Promise-to-Delivery Map together. We turn the way your best people ask questions, your pricing rules and your known pitfalls into a Requirement Schema and a Review Flow, while your team stays the one that approves the business content.
In the prototype, we test the Meeting Summary, Requirement Map, Solution Option and Proposal Editor with real users, to see whether the system helps them think or only produces more text. What matters most is that salespeople can edit assumptions and Delivery can see what hasn't been confirmed.
DNA Maker helps design a Proposal Workspace that connects your data without making salespeople enter anything twice. We set up the data model for requirements, products, prices, clauses and approvals, with a UX that shows users the impact of each edit, and we define permissions so one customer's data never ends up being used for another account.
Delivery covers the prototype, integration, rule tests, AI evaluation, document templates and monitoring after launch. We can start with one real type of proposal and simulate it from receiving the brief through to approval, so sales, delivery, finance and the client's contract owner can review the logic together before expanding.
DNA Maker can build the Sales Workspace, Proposal Configurator, CRM/ERP/document integration, an AI Reviewer, approvals and versioning, together with evaluation of pricing, scope and data leakage, and a handoff package once the deal closes.
If one type of proposal takes a long time and goes back and forth between departments several times, bring examples that went through and ones that were sent back, and let's talk. We'll help find the rules and build a prototype that measures both cycle time and scope quality.
SOFTWARE ENGINEERING GLOSSARY
Software engineering glossary
These terms are for discussing solution configuration, pricing, versions and acceptance criteria. Executives should be able to get an answer on where a single change to a proposal affects margin, scope and approval.
| Term | What it is | A simple example | What to ask the development team |
|---|---|---|---|
| CPQ | A system for configuring products, setting prices and producing quotes. CPQ keeps options, prices and exceptions under the same rules, which cuts down on proposals that can be sold but can't be delivered. | Choose a package and the price is calculated by the rules | Where do the pricing rules come from? |
| Requirement Map | A structure of needs and constraints. The map links each need to the solution, assumptions and acceptance, so you can check that every part of the proposal has a reason behind it. | Linking a pain point to a feature and the acceptance criteria | Who confirms the requirements? |
| Versioning | Keeping multiple versions in a way that can be audited. Every edit should have a number, an editor, a time and the differences, so you know which document or rule was in use on the day a decision was made. | Knowing which month's prices a proposal used | Which version is the approved one? |
| Acceptance Criteria | The conditions used to confirm that work is done. The criteria must be observable or testable and agreed before delivery, to avoid phrases like “works well” that each side reads differently. | The system exports files in the agreed format | Can this criterion be tested? |
| CRM Integration | Connecting data with the customer relationship management system. A good integration defines which way data flows, who owns each record and how conflicting data is handled; being able to send data once is the easy part. | Proposals and next steps are recorded automatically | Which data must never be overwritten? |
Further reading from the original documents: https://openai.github.io/openai-agents-js/guides/guardrails/