Turn structured CRM, form and tender data into native proposals

Inputs that belong in the run

A proposal run should start from facts you already trust, not from a prompt that asks the model to remember the whole company. Useful inputs are a CRM opportunity, an enquiry, a questionnaire, extracted tender requirements, a completed form, a JSON or API payload, and approved boilerplate or evidence your team has already accepted.

On an entitled Salesforce deployment, those opportunity, account or custom-object fields can be mapped into the same automation used for other documents, and the finished file can be attached back to the record. Without that connector, an application can still POST a structured create payload to the API. That second path creates a file. It is not CRM write-back.

• CRM opportunity or account fields where Salesforce is entitled
• Enquiry, questionnaire or website form
• Tender requirements you have already extracted
• JSON or API payload from the system of record
• Approved paragraphs, credentials and evidence — selected, not dumped in full

Outputs

The usual outputs are a Word proposal with heading structure and styles, and a PowerPoint pitch deck with real slide layouts. Both are native Office files. Where you need a PDF, the paid document service can convert an Office file to PDF. The public free MCP server does not include conversion.

An Excel pricing or capacity workbook can sit beside the narrative when the numbers belong in formulas. Generate that workbook on the Excel path, with the same rule used for financial models: calculate in the sheet, and let the proposal text explain the result.

• AI Word generator
• AI PowerPoint generator
• Financial model generation

Corporate templates

Repeatable proposals use the organisation’s document structure: Word styles and heading order, and PowerPoint layouts and slide-master structure defined in the schema. Paid tenants can merge keyed replacements into an existing template file so the cover, styles and legal footer stay put while the opportunity facts change. Template libraries are specific to the organisation. The free MCP server creates a new file and does not merge into a house template.

A buyer-locked tender form is a different job from a house-style proposal. Use signed-in Form Filler or a human-owned template merge when the layout is already fixed by the buyer. Generating a fresh design is the wrong tool for a portal form that must be completed in place.

• AI form filler
• Word document automation

Select evidence before the model writes

Do not place every case study, policy and credential into the prompt. Search and filter first. Retrieve the facts and evidence that match this opportunity. Send that selected set to the model. The model drafts structured document state. OfficeMaker creates the Office file.

That sequence is the same token-efficiency idea as querying a workbook before an analyst narrative: middleware or your source system holds the archive, and the model sees the relevant slice. How much context you save depends on how large the archive was. The published PowerPoint comparison shows the pattern for a different workflow and is an illustration, not a fixed saving for proposals.

The path is schema → structured JSON → validation → OfficeMaker middleware → native Office file. The model works in JSON, which is extensively represented in training corpora, rather than assembling Office Open XML or a document-rendering program.

• Token-efficiency write-up
• Query Excel before the LLM

Human approval

AI generation of a proposal or tender response does not mean unsupervised submission. Pricing, credentials, legal commitments and compliance statements need a person who is allowed to make them. Organisation workflows can pause for approval by an assignee or, where configured, by a Microsoft, Cognito or Google directory group, before the file is stored or sent.

OfficeMaker does not submit tenders to a procurement portal and does not calculate bid strategy.

A proposal workflow

One concrete sequence, using only steps the product can represent:

CRM opportunity → selected evidence → structured sections → validation → OfficeMaker file → human approval → storage or send.

1. A CRM opportunity, form or API payload identifies the buyer and the ask.
2. The workflow collects the facts that are allowed to appear.
3. Search or filter selects approved evidence instead of attaching the whole library.
4. The assistant writes proposal sections as schema-valid structured state.
5. OfficeMaker validates that state and creates the DOCX and, where requested, the PPTX.
6. A person approves the file.
7. The approved file is stored, delivered to Microsoft 365 where connected, or written back to the CRM where that entitlement is on.

What this replaces

Teams use OfficeMaker to cut manual copy and paste between the CRM and the document, bespoke scripts that rebuild the same proposal, repetitive formatting, and duplicated templates that drift apart. The CRM, the bid process and the commercial judgment stay. Microsoft Word and PowerPoint stay as the review surface.

Developer and API details, metering, and the corporate rollout sequence are on the linked pages.

• Corporate deployment
• Pricing
• Document generation API
• MCP document generation
• Salesforce document generation

Evidence behind this

Native Office files

Claim. OfficeMaker creates native Word, Excel and PowerPoint files.

Mechanism. The model supplies schema-valid structured state. OfficeMaker middleware validates that state and constructs the .docx, .xlsx or .pptx file.

Evidence. Document generation API

Limitation. Create is available on the public free sandbox. Merge, edit and conversion of existing files are paid document-service verbs.

Template merge is a paid verb

Claim. An existing house template can receive keyed replacements on the paid document service.

Mechanism. Merge applies declarative keyed updates to an existing Office file after the payload is validated.

Evidence. OfficeMaker facts

Limitation. The public free MCP server does not expose merge or edit.

Middleware and token use

Claim. Doing file work outside the model can reduce unnecessary token use.

Mechanism. Parsing, filtering, calculation, validation and file construction happen in OfficeMaker middleware, so the model works with relevant structured state rather than a rendering program or a screenshot loop.

Evidence. Token-efficiency workflow write-up (15 April 2026)

Limitation. The published figures are reasoned estimates for one PowerPoint workflow, about 60,000–90,000 tokens for a Python/PptxGenJS path with image review versus about 20,000–30,000 for OfficeMaker on that example. Savings vary by document size, workflow and model. They are not a billing guarantee.

Questions

Can a generated proposal be submitted without review?

It should not. OfficeMaker can create the Word or PowerPoint file and can pause an organisation workflow for human approval. Generation does not submit a tender, and it does not replace commercial or legal sign-off.