System: MWMS
Document Type: Operating Framework
Authority Level: MCR Source Of Truth
Status: Active
Version: v1.0
Primary Location: MCR
Future Operational Destination: Sales Brain, AIBS Brain, Finance Brain, Operations Brain, Automation Brain, Data Brain, Compliance Brain, Risk Brain, HeadOffice Brain
Parent Page: Sales Brain
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-21
Source / Origin: AI Automations by Jack material covering meeting-triggered proposal creation, transcript retrieval, requirement extraction, project outcome extraction, requested timing, client identity, business logos, template-based document generation, PDF creation, email drafting, payment links, proposal status, and outcome tracking
MWMS Classification: Sales Brain Operating Framework / Proposal Generation Standard / Commercial Approval Framework / Transcript To Proposal Governance / Client Offer Document Control System
Primary Brain: Sales Brain
Supporting Brains: AIBS Brain, Finance Brain, Operations Brain, Automation Brain, Data Brain, Compliance Brain, Risk Brain, Customer Brain, Content Brain, HeadOffice Brain
Related Pages: Sales Brain Canon, AIBS Brain Canon, MWMS Meeting Intelligence And Action Extraction Framework, MWMS AI Assisted Outreach And Sales Follow Up Automation Framework, MWMS Client Communication Automation Framework, MWMS Client Intelligence Report Automation Framework, MWMS Prompt Architecture And Automation Output Reliability Framework, MWMS AI Output Validation Standard, MWMS AI Tool Permission And Access Framework, MWMS AI Automation Security And Risk Checklist, MWMS Client Context Isolation And Privacy Boundary Standard, MWMS Client Approval And Review Gate Protocol
Purpose
The purpose of the MWMS Client Proposal Generation And Commercial Approval Framework is to define how MWMS converts an approved sales conversation, discovery meeting, diagnostic review, client brief, or qualified opportunity into a controlled commercial proposal.
This framework governs the complete transition from:
conversation
to extracted requirements
to proposed scope
to pricing
to commercial approval
to document generation
to client delivery
to response
to acceptance or rejection
to operational handoff
This framework exists because proposal automation can reduce:
manual proposal writing
forgotten follow-up
inconsistent documents
missing requirements
slow turnaround
repetitive formatting
poor version control
untracked outcomes
However, proposal automation also creates material commercial risk.
A proposal may contain:
scope
deliverables
deadlines
pricing
payment terms
assumptions
exclusions
performance claims
responsibilities
commercial commitments
contract-like wording
next-step instructions
A model must not be allowed to invent or approve these matters merely because it can generate a polished document.
The purpose of this framework is therefore not simply to automate proposal documents.
It is to establish a governed commercial approval system.
Core Doctrine
The MWMS doctrine is:
AI may extract, organise, draft, format, compare, flag, and prepare.
AI must not independently approve price, scope, terms, deadlines, guarantees, discounts, or contractual commitments.
The complete proposal lifecycle is:
Opportunity Qualified
→ Proposal Trigger Confirmed
→ Client And Meeting Matched
→ Source Records Retrieved
→ Requirements Extracted
→ Ambiguities Identified
→ Problem And Desired Outcome Confirmed
→ Proposed Scope Drafted
→ Deliverables Defined
→ Assumptions, Dependencies, And Exclusions Defined
→ Timeline Drafted
→ Pricing And Payment Terms Added By Authority
→ Claims And Risks Reviewed
→ Commercial Approval Obtained
→ Proposal Document Generated
→ Final Recipient And Attachment Checks Completed
→ Send Approval Obtained
→ Proposal Delivered
→ Delivery Confirmed
→ Client Response Tracked
→ Questions Or Revisions Managed
→ Proposal Accepted, Rejected, Parked, Expired, Or Superseded
→ Accepted Proposal Handed Off To Operations
→ Outcome Intelligence Recorded
A proposal workflow is incomplete if it only produces a PDF.
It must also govern:
which meeting or source record created it
which client it belongs to
what was actually requested
what remains uncertain
who approved the commercial terms
which version was sent
who received it
what response occurred
what changed during revision
what becomes operational after acceptance
Scope
This framework applies to:
AIBS client proposals
consulting proposals
automation proposals
AIOS proposals
project proposals
service proposals
diagnostic-to-offer proposals
implementation proposals
retainer proposals
pilot proposals
paid discovery proposals
proposal PDFs
proposal documents
proposal emails
proposal follow-up workflows
proposal revision workflows
proposal acceptance records
proposal-to-project handoff
future proposal-generation AI Employees
This framework does not replace formal legal contracts, terms of service, statements of work, engagement letters, or regulated disclosure documents where those are required.
A proposal may support a contract.
It must not be treated as a complete contract unless specifically reviewed and approved for that purpose.
Core Definition
A client proposal is a controlled commercial document that explains:
the client problem or opportunity
the desired outcome
the proposed solution
the proposed scope
the deliverables
the expected timeline
the responsibilities
the assumptions
the exclusions
the price
the payment terms
the next step
MWMS Definition
An MWMS Client Proposal is:
A source-linked, version-controlled, commercially approved offer document that translates verified client requirements into a clear proposed scope, deliverables, timeline, price, terms, responsibilities, assumptions, exclusions, and next action without inventing commitments or overstating certainty.
The Proposal Operating Model
Every proposal system should operate across twenty layers:
Proposal Trigger Layer
Client And Opportunity Identity Layer
Source And Meeting Match Layer
Transcript And Evidence Layer
Requirements Extraction Layer
Problem And Desired Outcome Layer
Scope Formation Layer
Deliverables Layer
Assumptions Dependencies And Exclusions Layer
Timeline And Milestone Layer
Pricing And Payment Layer
Claim And Evidence Layer
Risk And Compliance Layer
Proposal Template Layer
Commercial Approval Layer
Document Generation Layer
Delivery Approval Layer
Response Revision And Version Layer
Acceptance And Operational Handoff Layer
Outcome Intelligence Layer
- Proposal Trigger Layer
A proposal should only begin from an approved trigger.
Possible triggers include:
discovery meeting completed
diagnostic completed
qualified sales opportunity
client requests proposal
sales owner authorises proposal
scope review completed
approved brief received
pilot opportunity approved
The trigger should identify:
Proposal Trigger:
Trigger Date:
Opportunity:
Client:
Sales Owner:
Source Record:
Reason For Proposal:
Authority:
Rule
A completed meeting does not automatically require a proposal.
The opportunity must be sufficiently qualified.
- Client And Opportunity Identity Layer
The system must identify the correct:
client
company
contact
opportunity
sales owner
meeting
email thread
account
proposal destination
Required identity fields may include:
Client ID:
Company:
Primary Contact:
Contact Email:
Opportunity ID:
Meeting ID:
CRM Record:
Sales Owner:
Identity Confidence:
Existing Client: Yes / No
Rule
The proposal must not proceed where the client, opportunity, or source meeting is uncertain.
Similar names, shared domains, forwarded messages, or generic inboxes require review.
- Source And Meeting Match Layer
The proposal must be linked to the correct source records.
Possible sources include:
meeting transcript
meeting recording
discovery notes
client brief
form submission
diagnostic report
email thread
CRM notes
approved statement from sales owner
previous proposal
Source-match checks should confirm:
participant identity
meeting date
meeting title
client email
opportunity
latest relevant conversation
proposal request
source completeness
Rule
The latest transcript returned by a tool is not automatically the correct transcript.
Source matching must use more than one signal where practical.
- Transcript And Evidence Layer
A transcript is an evidence source, not a final commercial instruction.
Transcript limitations may include:
speaker errors
missing words
poor audio
wrong attribution
ambiguous timing
informal comments
unconfirmed ideas
sarcasm
tentative language
contradictory statements
A proposal input record should distinguish:
Direct Client Statement
Sales Team Statement
Confirmed Decision
Tentative Idea
Question
Assumption
AI Interpretation
Unknown
Rule
The system must not turn conversational ambiguity into commercial certainty.
Transcript Confidence
Use:
High
Medium
Low
Unusable
A low-confidence transcript should require human review before proposal drafting.
- Requirements Extraction Layer
The system may extract:
client problem
current state
desired outcome
requested capabilities
business constraints
technical constraints
budget signals
timing signals
stakeholders
approval process
must-have requirements
nice-to-have requirements
risks
questions
unknowns
Requirement Status
Confirmed
Probable
Unconfirmed
Conflicting
Out Of Scope
Deferred
Rule
Only confirmed requirements should be presented as agreed requirements.
Probable or unconfirmed requirements must be clearly marked or resolved.
Proposal Input Pack
Before scope drafting, create:
Client:
Opportunity:
Source Records:
Current Situation:
Problem:
Desired Outcome:
Confirmed Requirements:
Unconfirmed Requirements:
Constraints:
Stakeholders:
Budget Information:
Requested Timing:
Risks:
Open Questions:
Recommended Next Step:
Human Review Required:
- Problem And Desired Outcome Layer
The proposal should clearly explain:
the current problem
why it matters
the desired outcome
how success may be recognised
This section must not exaggerate the client’s pain or invent urgency.
Problem statements should be grounded in:
client statements
approved diagnostics
verified operational evidence
current records
Desired outcomes should distinguish:
client-stated outcome
MWMS recommendation
possible future opportunity
Rule
A recommended outcome must not be written as though the client already approved it.
- Scope Formation Layer
Scope defines what MWMS proposes to do.
Scope should identify:
work included
systems included
business units included
users included
locations included
channels included
integrations included
data sources included
implementation activities
training
testing
documentation
support
Rule
Scope must be explicit enough to prevent hidden work and expectation drift.
Scope Status
Draft
Commercial Review
Approved
Revised
Superseded
Scope Boundary Rule
The proposal should state what is not included where omission could create confusion.
- Deliverables Layer
Deliverables should be specific and measurable where practical.
Each deliverable should define:
Deliverable:
Description:
Owner:
Acceptance Condition:
Dependency:
Target Timing:
Revision Limit Where Applicable:
Handoff Requirement:
Possible deliverables include:
workflow design
automation build
dashboard
AI assistant
knowledge base
data integration
client training
documentation
testing report
support period
Rule
Activities are not automatically deliverables.
“Work on automation” is not an adequate deliverable.
- Assumptions Dependencies And Exclusions Layer
Assumptions may include:
client supplies access
client provides approved content
client responds within defined periods
third-party tools remain available
data is legally usable
required subscriptions are maintained
Dependencies may include:
API access
calendar access
email access
CRM access
hosting
client approvals
external provider performance
Exclusions may include:
legal review
custom software outside scope
ongoing media spend
third-party fees
unlimited revisions
unrelated integrations
data correction outside the agreed boundary
Rule
Assumptions, dependencies, and exclusions must not be hidden in vague wording.
- Timeline And Milestone Layer
The timeline should define:
estimated start
conditions required before start
milestones
review points
client responsibilities
estimated completion
factors that may change timing
Timeline language should distinguish:
Target Date
Estimated Date
Fixed Commitment
Dependent Date
Unconfirmed Date
Rule
The AI must not convert “we would like this next month” into a guaranteed delivery date.
- Pricing And Payment Layer
Pricing is a controlled commercial field.
Possible pricing structures include:
fixed fee
setup fee
monthly retainer
usage fee
milestone payments
pilot fee
hourly fee
performance-linked component where approved
Pricing fields should include:
Currency:
Subtotal:
Tax:
Total:
Payment Schedule:
Deposit:
Recurring Charge:
Third-Party Costs:
Usage Costs:
Late Payment Terms:
Proposal Validity:
Pricing Approval Owner:
Rule
AI may insert approved pricing.
AI may not create, discount, modify, or negotiate pricing without authority.
Payment Link Rule
A payment link may be included only when:
the correct product or invoice exists
the price matches the proposal
the currency matches
the client is correct
the payment terms are approved
the link is tested
the proposal is approved for delivery
- Claim And Evidence Layer
Claims may concern:
revenue
cost savings
time savings
conversion
performance
delivery capability
security
compliance
integration capability
implementation speed
Claims should be classified as:
Verified MWMS Evidence
Client-Specific Estimate
Illustrative Example
Target
Possibility
Unsupported
Rule
Unsupported claims must not appear in the proposal.
Results from other clients must not be presented as guaranteed outcomes.
- Risk And Compliance Layer
Proposal review should consider:
privacy
client data
security
recording consent
regulated activities
marketing compliance
intellectual property
third-party licensing
vendor terms
jurisdiction
financial claims
medical claims
legal claims
data residency
sensitive data
Risk levels may be:
Low
Moderate
High
Restricted
Rule
High-risk or restricted proposals require specialist review before delivery.
- Proposal Template Layer
A proposal template should define:
document title
client name
client business
date
proposal version
prepared by
executive summary
current situation
desired outcome
proposed solution
scope
deliverables
timeline
responsibilities
assumptions
exclusions
pricing
payment terms
risks
next step
validity period
approval or acceptance method
Template rules should define:
required sections
optional sections
branding
logo placement
page structure
font
document style
file name
version display
Rule
Template consistency must not remove commercial judgment.
Client Logo Rule
A client logo may be used where:
it is sourced correctly
its use is appropriate
it does not imply endorsement beyond the proposal relationship
the correct client is confirmed
the correct version is used
- Commercial Approval Layer
Commercial approval is mandatory before external delivery.
The approver should review:
client identity
opportunity
problem
desired outcome
scope
deliverables
timeline
assumptions
dependencies
exclusions
price
tax
payment terms
claims
risks
next step
proposal validity
Commercial Approval Decisions
Approve
Approve With Conditions
Revise
Hold
Reject
Escalate
Commercial Approval Record
Proposal ID:
Version:
Approver:
Decision:
Conditions:
Approved Price:
Approved Scope:
Approved Timeline:
Approved Terms:
Approved Claims:
Date:
Rule
Generating a proposal document does not mean the proposal is commercially approved.
- Document Generation Layer
Once approved content exists, the system may generate:
Google Document
Word Document
client portal document
approved HTML document
Generation should confirm:
correct template
correct client
correct logo
correct approved data
correct proposal version
correct pricing
correct date
correct payment link
correct file name
complete sections
no unresolved placeholders
Rule
No proposal may be delivered with unresolved placeholders, wrong-client details, or draft comments.
Document File Naming Standard
Recommended structure:
Client Name Proposal Service Version Date
Example:
Acme Dental AIOS Proposal v1.0 2026-06-21
- Delivery Approval Layer
Delivery is a separate approval.
Before delivery, confirm:
recipient
CC recipients
sender
subject
email body
proposal attachment
attachment version
client identity
commercial approval
delivery channel
confidentiality
send authority
Delivery Modes
Draft Only
Human Approved Send
Client Portal Upload
Approved Manual Delivery
Restricted
Rule
Document approval does not automatically create send authority.
Proposal Delivery Record
Proposal ID:
Version:
Recipient:
Sender:
Channel:
Subject:
Attachment:
Approval:
Sent Date:
Provider Result:
Delivery Status:
Follow-Up Date:
- Response Revision And Version Layer
Client responses may include:
question
clarification
revision request
price objection
scope objection
timeline objection
acceptance
rejection
delay
no response
Each revision should create a new version where material content changes.
Material changes include:
scope
deliverables
price
payment terms
timeline
assumptions
exclusions
claims
legal wording
Proposal Version States
Draft v0.x
Approved v1.0
Revised v1.1
Major Revision v2.0
Superseded
Expired
Accepted
Rejected
Rule
Never overwrite the only copy of a proposal that was sent to a client.
Revision Record
Previous Version:
New Version:
Requested By:
Reason:
Fields Changed:
Commercial Reapproval Required:
Approved By:
Sent Date:
- Acceptance And Operational Handoff Layer
Acceptance may occur through:
signed agreement
approved email
digital acceptance
payment
purchase order
formal instruction
Acceptance must be verified.
The accepted proposal should create an Operational Handoff Pack containing:
client
accepted proposal
accepted version
scope
deliverables
timeline
dependencies
client responsibilities
MWMS responsibilities
price
payment status
key contacts
risks
open questions
sales notes
meeting sources
project owner
first operational action
Rule
Operations must receive the accepted commercial truth.
It must not rely on a summary that conflicts with the accepted proposal.
Proposal Versus Contract Rule
Where a separate contract is required, proposal acceptance must not be treated as final operational authority until the required contract is executed.
- Outcome Intelligence Layer
Proposal systems should record:
proposal count
approval time
time from meeting to proposal
time from proposal to decision
revision count
acceptance rate
rejection rate
expiry rate
average value
discount rate
scope-change frequency
common objections
common exclusions
common causes of delay
proposal-to-project conversion
Outcome intelligence should support:
sales improvement
offer improvement
scope control
pricing review
template improvement
qualification improvement
Rule
Proposal analytics should improve commercial decisions, not merely count documents.
Proposal Status Model
Every proposal should use controlled states.
Opportunity Qualified
Proposal Requested
Source Review Required
Requirements Extracted
Open Questions
Drafting
Commercial Review
Revision Required
Commercially Approved
Document Generated
Delivery Review
Approved For Send
Sent
Viewed
Questions Received
Revision Requested
Decision Pending
Accepted
Rejected
Expired
Parked
Superseded
Operational Handoff Complete
Rule
Only valid state transitions should be permitted.
Proposal Data Record
Proposal ID:
Client ID:
Opportunity ID:
Company:
Primary Contact:
Sales Owner:
Meeting ID:
Source Records:
Proposal Trigger:
Current Status:
Problem:
Desired Outcome:
Confirmed Requirements:
Unconfirmed Requirements:
Scope Version:
Deliverables:
Assumptions:
Dependencies:
Exclusions:
Timeline:
Currency:
Subtotal:
Tax:
Total:
Payment Terms:
Proposal Validity:
Claims:
Risk Level:
Commercial Approver:
Commercial Approval Status:
Document Version:
Document Location:
Delivery Approval:
Recipient:
Sent Date:
Client Response:
Revision Count:
Acceptance Status:
Accepted Version:
Operational Handoff Status:
Outcome:
Last Updated:
Proposal Input Validation Standard
Before drafting, validate:
client exists
opportunity exists
source exists
source belongs to client
meeting is correct
transcript is sufficiently complete
requirements can be identified
open questions are recorded
commercial owner exists
Rule
Invalid inputs must stop or route the proposal workflow.
Proposal Output Validation Standard
Before commercial review, validate:
required sections exist
client identity is correct
scope is present
deliverables are present
assumptions are present
exclusions are present
timeline is present
pricing is present or intentionally pending
terms are present
claims are identified
open questions are visible
no unsupported commitments exist
Proposal Pre-Send Validation Standard
Before send, validate:
commercial approval exists
delivery approval exists
proposal version matches approval
recipient is correct
attachment is correct
subject is correct
body is correct
payment link is correct
no unresolved placeholders exist
no internal notes remain
no superseded version is attached
Rule
A polished document that fails validation is not send-ready.
Human Review Standard
Human review is mandatory for:
first proposal to a new client
new offer
new pricing model
custom scope
discount
performance-linked pricing
high-value proposal
regulated use case
sensitive client data
unusual legal term
unusual timeline
material guarantee
high-risk claim
AI-generated assumption
conflicting meeting evidence
Human review must be informed.
The reviewer should see:
source evidence
open questions
AI extractions
commercial fields
risk flags
version changes
Proposal Follow-Up Standard
Follow-up should be based on proposal state.
Possible follow-up messages include:
delivery confirmation
clarification offer
decision-date reminder
question response
revision confirmation
expiry reminder
closeout
Follow-up must not:
invent urgency
claim limited availability falsely
change price
change scope
pressure the client improperly
continue after rejection or suppression
Rule
Proposal follow-up should support a decision, not manufacture pressure.
Proposal Expiry Standard
Every commercial proposal should define a validity period where appropriate.
After expiry:
price may require review
timeline may require review
availability may require review
third-party costs may require review
scope assumptions may require review
The system should not automatically extend an expired proposal.
Proposal Rejection Standard
A rejected proposal should capture:
reason
price issue
scope issue
timing issue
trust issue
priority issue
competitor
internal delay
no decision
poor fit
The system should distinguish:
Explicit Rejection
No Decision
Expired
Parked
Lost To Competitor
Disqualified
Rule
A non-response is not automatically a rejection.
Proposal Acceptance Standard
Before marking accepted, confirm:
accepted version
acceptance evidence
signatory authority where required
payment status where relevant
contract status
start conditions
operational owner
Rule
A positive email does not always equal complete commercial acceptance.
Failure Modes
Failure Mode 1: Wrong Transcript
The proposal is generated from another meeting or client.
Correction
Use client, participant, date, meeting, and opportunity matching.
Failure Mode 2: Transcript Treated As Perfect
Speaker errors or ambiguous comments become proposal facts.
Correction
Apply transcript confidence and human review.
Failure Mode 3: Informal Idea Becomes Scope
A possibility discussed during the meeting becomes an included deliverable.
Correction
Classify requirements as confirmed, probable, unconfirmed, or out of scope.
Failure Mode 4: AI Invents Price
The model creates a plausible price.
Correction
Restrict pricing to approved commercial data.
Failure Mode 5: AI Applies Discount
The model attempts to overcome an objection by lowering price.
Correction
Require authorised human approval for discounting.
Failure Mode 6: Desired Date Becomes Guaranteed Deadline
A requested date becomes a fixed commitment.
Correction
Classify dates as target, estimate, fixed, dependent, or unconfirmed.
Failure Mode 7: Missing Exclusions
The proposal appears broader than intended.
Correction
Require assumptions, dependencies, and exclusions.
Failure Mode 8: Activity Presented As Deliverable
The proposal promises effort rather than a defined output.
Correction
Define measurable deliverables and acceptance conditions.
Failure Mode 9: Unsupported Result Claim
The proposal guarantees performance without evidence.
Correction
Classify and review all claims.
Failure Mode 10: Wrong Client Logo
The document uses another company’s logo.
Correction
Validate client identity and asset source before generation.
Failure Mode 11: Broken Payment Link
The proposal directs the client to an incorrect or unavailable payment route.
Correction
Test the approved payment link before delivery.
Failure Mode 12: Draft Automatically Sent
The document generation workflow sends externally without review.
Correction
Separate generation, commercial approval, and send approval.
Failure Mode 13: Wrong Recipient
The proposal is sent to an unrelated contact.
Correction
Validate the client, recipient, and opportunity before delivery.
Failure Mode 14: Superseded Version Sent
An old proposal is attached after revision.
Correction
Use version status and pre-send validation.
Failure Mode 15: Internal Notes Exposed
Draft comments or review notes remain in the client document.
Correction
Run final document inspection.
Failure Mode 16: Proposal Overwrites History
A revised proposal replaces the only copy of the original.
Correction
Maintain immutable sent versions.
Failure Mode 17: Client Acceptance Not Verified
A vague positive response is marked as accepted.
Correction
Define valid acceptance evidence.
Failure Mode 18: Operations Receives Wrong Scope
The delivery team works from a summary that conflicts with the accepted proposal.
Correction
Use an accepted-version Operational Handoff Pack.
Failure Mode 19: Proposal Treated As Contract
Work begins despite required legal documentation being incomplete.
Correction
Define proposal, contract, payment, and start-condition boundaries.
Failure Mode 20: Proposal Automation Becomes Proposal Factory
Every completed meeting creates a proposal regardless of fit.
Correction
Require opportunity qualification and proposal authority.
Failure Mode 21: Ambiguity Hidden
The generated proposal looks certain despite unresolved questions.
Correction
Surface open questions and block approval where material.
Failure Mode 22: Third-Party Costs Omitted
Client assumes external tools are included.
Correction
State third-party subscriptions, usage, and vendor costs.
Failure Mode 23: Revision Changes Commercial Terms Without Reapproval
A revised document is sent after price or scope changes.
Correction
Require new commercial approval for material changes.
Failure Mode 24: Proposal Metrics Reward Volume
The team optimises proposal count rather than qualified acceptance.
Correction
Measure conversion, value, cycle time, revision quality, and project success.
Governance Responsibilities
Sales Brain
Owns:
proposal strategy
opportunity qualification
problem definition
desired outcome
scope recommendation
deliverables
proposal follow-up
commercial progression
client response
AIBS Brain
Owns:
AIOS offer design
AIOS proposal packaging
client automation scope
productised service boundaries
AIBS delivery assumptions
Finance Brain
Owns:
price integrity
currency
tax treatment
payment schedules
discount authority
margin review
commercial viability
Operations Brain
Owns:
delivery feasibility
resource assumptions
implementation dependencies
operational handoff
delivery acceptance conditions
Automation Brain
Owns:
workflow triggers
source retrieval
document generation
status transitions
tool confirmation
failure handling
duplicate prevention
delivery logging
Data Brain
Owns:
proposal records
client identity
opportunity linkage
meeting linkage
version history
document location
status integrity
outcome data
Compliance And Risk Brains
Own:
regulated claims
privacy
security
data handling
legal escalation
restricted industries
sensitive proposal terms
Customer Brain
Supports:
clarity
client experience
communication quality
decision support
Content Brain
Supports:
document language
human-quality writing
structure
brand voice
presentation quality
HeadOffice
Owns:
cross-Brain authority
high-value exceptions
unusual terms
strategic pricing conflicts
major risk escalation
final governance
Future AI Employee Ideas
Proposal Input Analyst
Primary Brain: Sales Brain
Purpose:
Extracts confirmed requirements, uncertainties, desired outcomes, stakeholders, constraints, and open questions from approved source records.
Proposal Scope Drafting Assistant
Primary Brain: Sales Brain / AIBS Brain
Purpose:
Drafts proposed scope and deliverables from validated proposal inputs.
Commercial Terms Validator
Primary Brain: Finance Brain / Sales Brain
Purpose:
Checks price, currency, tax, payment terms, validity, discounts, and approval authority.
Proposal Evidence Reviewer
Primary Brain: Sales Brain / Risk Brain
Purpose:
Checks whether proposal claims, assumptions, and outcomes are supported.
Proposal Version Controller
Primary Brain: Data Brain
Purpose:
Maintains proposal versions, revision history, sent records, superseded states, and accepted versions.
Proposal Delivery Safety Reviewer
Primary Brain: Sales Brain / Automation Brain
Purpose:
Checks recipient, attachment, version, approval, subject, email body, and payment link before send.
Proposal Follow Up Coordinator
Primary Brain: Sales Brain / Automation Brain
Purpose:
Tracks proposal state, next action, follow-up date, questions, revisions, expiry, and closeout.
Proposal To Operations Handoff Coordinator
Primary Brain: Operations Brain / Sales Brain
Purpose:
Creates the accepted-scope handoff pack and confirms delivery ownership.
Proposal Outcome Analyst
Primary Brain: Sales Brain / Data Brain
Purpose:
Analyses acceptance, rejection, revision, pricing, scope, and cycle-time outcomes.
Drift Protection
This framework protects MWMS from:
automatic proposal generation after every meeting
wrong-client proposals
wrong transcript retrieval
AI interpretation presented as client agreement
scope invention
price invention
automatic discounting
unsupported guarantees
hidden exclusions
unrealistic deadlines
unapproved payment terms
proposal sending without review
wrong attachments
wrong recipients
old versions being sent
internal notes being exposed
proposal acceptance being assumed
operations receiving incomplete scope
proposal volume being mistaken for sales performance
Drift Signals
Watch for:
“The meeting is complete, so send the proposal.”
“The AI knows what they meant.”
“We can fill in the missing scope.”
“That price sounds reasonable.”
“Just use the standard discount.”
“They said next month, so promise next month.”
“The PDF looks right.”
“The template already has the payment link.”
“Send it automatically.”
“We can overwrite the old version.”
“They replied positively, so mark it accepted.”
“Operations can read the transcript.”
“The proposal is basically the contract.”
“We can fix the terms later.”
Rule
When these signals appear, return to source validation, confirmed requirements, commercial authority, explicit scope, approved price, version control, delivery approval, and acceptance evidence.
Implementation Boundary
This framework defines proposal architecture and governance.
It does not authorise immediate development of:
proposal generators
transcript retrieval automations
PDF workflows
payment-link automations
CRM proposal pipelines
proposal portals
email send automations
acceptance systems
Before implementation, the responsible Brain must create a scoped build brief defining:
proposal use case
client type
opportunity stage
source systems
meeting matching
required input fields
requirement classifications
scope template
deliverable template
pricing source
commercial approvers
risk rules
document template
version model
delivery rules
follow-up states
acceptance evidence
operational handoff
metrics
Rule
No proposal automation should be built without a defined commercial approval boundary.
Strategic Summary
Proposal automation is valuable because it can transform an approved client conversation into a clear, professional, and timely offer.
The durable value comes from connecting:
meeting intelligence
client identity
verified requirements
scope control
deliverables
assumptions
pricing authority
commercial approval
document generation
delivery approval
version control
client response
operational handoff
The strongest starting system is:
Meeting Completed
→ Proposal Input Pack
→ Human Scope And Price Review
→ Approved Proposal Generation
→ Draft Email
→ Human Send Approval
→ Response Tracking
This provides speed without giving AI uncontrolled commercial authority.
Final Standard
The MWMS final standard is:
A client proposal must be source-linked, client-specific, requirement-aware, scope-controlled, commercially approved, versioned, delivery-checked, outcome-tracked, and operationally transferable.
A valid proposal system must define:
proposal trigger
client
opportunity
source records
meeting match
transcript confidence
confirmed requirements
unconfirmed requirements
problem
desired outcome
scope
deliverables
assumptions
dependencies
exclusions
timeline
pricing
tax
payment terms
claims
risk
commercial approver
proposal version
document template
delivery approval
recipient
follow-up
acceptance evidence
operational handoff
outcome
AI may prepare the proposal.
AI may not independently approve the commercial commitment.
That is the MWMS Client Proposal Generation And Commercial Approval Framework.
MWMS System Change Log
Version: v1.0
Date: 2026-06-21
Author: HeadOffice
Change
Created the MWMS Client Proposal Generation And Commercial Approval Framework using the AI Automations by Jack material covering:
meeting-triggered proposal creation
client and opportunity records
transcript retrieval
participant-email matching
meeting-status triggers
requirements extraction
what was discussed
what the client wants
requested timing
client logo insertion
document templates
PDF generation
proposal email drafts
pricing
payment links
proposal outcome tracking
The framework converts the course’s document automation into a governed twenty-layer commercial proposal system.
The framework adds standards covering:
- proposal triggers
- client and opportunity identity
- source and meeting matching
- transcript confidence
- requirements extraction
- problem and desired outcome
- scope formation
- deliverables
- assumptions
- dependencies
- exclusions
- timeline and milestone classification
- pricing authority
- payment terms
- claim evidence
- proposal risk
- commercial approval
- document generation
- delivery approval
- proposal versioning
- revision control
- acceptance evidence
- proposal-to-operations handoff
- proposal outcome intelligence
Added explicit doctrine that:
- a completed meeting does not automatically require a proposal
- a transcript is an evidence source, not a final commercial instruction
- AI may extract and draft but may not approve price, scope, deadlines, guarantees, discounts, or terms
- document generation and send authority are separate
- a revised proposal must preserve sent-version history
- operations must receive the accepted commercial truth
- a proposal must not be treated as a complete contract where separate legal documentation is required
Change Impact Declaration
This is a new Sales Brain framework.
It creates the governing commercial boundary between:
- meeting intelligence
- sales requirements
- scope drafting
- pricing
- proposal generation
- client delivery
- operational handoff
The framework does not change the authority of the MWMS Meeting Intelligence And Action Extraction Framework.
Meeting Intelligence may produce a Proposal Input Pack.
It may not independently authorise commercial terms.
The framework does not authorise automatic proposal sending.
The recommended first operational mode is:
- source retrieval
- proposal input extraction
- human scope review
- human price approval
- approved document generation
- draft email creation
- human send approval
Pages Created
- MWMS Client Proposal Generation And Commercial Approval Framework
Pages Updated
- None as part of this page creation
Pages Deprecated
- None
Standalone Pages Not Created
The following standalone pages were not created because their durable intelligence is governed within this framework:
- MWMS Automated Client Proposal Framework
- MWMS Transcript To Proposal Framework
- MWMS AI Proposal Writer Framework
- MWMS Proposal PDF Automation Framework
- MWMS Fireflies Proposal Automation Framework
- MWMS Proposal Email Automation Framework
- MWMS Client Logo Proposal Template Framework
- MWMS Proposal Pricing Approval Standard
- MWMS Proposal Version Control Framework
- MWMS Proposal To Operations Handoff Framework
Registries Requiring Update
- MCR Page Registry
- Sales Brain Page Registry
- MCR Copy Map
- MWMS Course Absorption Decision Registry
Canon Version Update Required
No immediate Sales Brain Canon version change is required unless the Canon must record the addition of a new active framework.
The next scheduled Sales Brain Canon alignment should recognise:
- Proposal Input Pack
- commercial approval authority
- proposal version control
- delivery approval
- accepted-proposal operational handoff
Change Log Entry Required
Yes.
The new v1.0 framework must be recorded in:
- MWMS System Change Log
- MCR Page Registry
- Sales Brain Page Registry
- MCR Copy Map
- MWMS Course Absorption Decision Registry
Strategic Absorption Result
The AI Automations by Jack proposal-generation material has been absorbed as a governed commercial proposal system rather than a tool-specific PDF automation.
The absorption preserves:
- transcript-supported proposal inputs
- client identity
- meeting status
- structured requirement extraction
- template-based documents
- personalised branding
- PDF generation
- draft email creation
- proposal outcome tracking
The absorption rejects:
- automatically generating a proposal after every completed meeting
- using the latest transcript without source verification
- treating transcript interpretation as client agreement
- allowing AI to invent scope
- allowing AI to invent pricing
- hard-coded commercial terms without review
- automatic external sending
- wrong-recipient and wrong-attachment risk
- overwriting previous proposal versions
- assuming acceptance from vague positive replies
- treating a proposal as a contract where further legal documentation is required
The resulting v1.0 framework establishes that MWMS proposal generation must be:
- source-linked
- identity-aware
- requirement-controlled
- ambiguity-visible
- scope-defined
- deliverable-specific
- assumption-aware
- exclusion-aware
- price-authorised
- evidence-backed
- commercially approved
- version-controlled
- delivery-checked
- acceptance-verified
- operationally transferable
END OF FULL FILE OUTPUT