Creating a proposal in the Web App

This article covers creating a proposal that lives in SiftHub's own document editor — from either a blank document or your own template. If you would rather work in Google Docs, see Creating a proposal in Google Docs.

Before you start

Have these ready. Only the first is strictly required, but the difference in output quality between the first alone and all four is large.

• The solicitation or RFP document. This is what the buyer sent you. SiftHub reads it to work out what the proposal has to cover.
• Your template, if you are using one. A .docx, or a Google Doc you can link to.
• Deal context. Call notes, discovery notes, anything that says what this buyer actually cares about.
• Any instructions that are not obvious from the documents — a section to skip, a tone to hold, a fact about this deal SiftHub could not know.

Starting the proposal

Go to Projects and click Create Project. Under the document upload area, click Create proposal from template/blank document.

Choose Fill a template or Start with a blank document.

Option 1: Start with a blank document

On Google Workspace, SiftHub offers a Google Doc link field by default. Click Create in the web app instead to work in SiftHub's editor. On Microsoft 365, SiftHub creates the blank document straight away.

Either way SiftHub creates an empty document, names it Proposal.docx, and moves on. There is no folder to choose and no permissions to grant — the document lives inside SiftHub.

With a blank document, SiftHub builds the whole structure itself from the buyer's requirements, and formats it using your workspace's brand settings if they are configured, or SiftHub's defaults if not.

Option 2: Fill a template

If your workspace has templates configured, this step opens on a Template library tab. Pick one from the list. Switch to New template to supply a different one instead.

If your workspace has no templates configured, you go straight to supplying one: on Google Workspace, paste a link to the template in Google Docs, or click Upload template instead to upload a .docx. On Microsoft 365, upload the .docx directly.

Note: Templates must be .docx files. Your administrator configures the template library for the whole workspace.

What makes a good template

SiftHub works from your template's structure, so the structure is worth getting right:

• Use real heading styles rather than manually bolding and enlarging text. SiftHub reads the heading hierarchy to understand which sections contain which subsections, and uses it to decide how new content should be formatted.
• Leave sections empty, or use an obvious placeholder such as [response goes here], where you want SiftHub to write. An empty heading with nothing under it is a clear signal.
• Leave content in place where you want it kept. Legal terms, standard SLAs, your standard company description — write them once in the template and SiftHub will generally leave them alone.
• Use placeholders such as [Client] where you want deal-specific details filled in. These are an explicit signal to personalise.

Adding project context

Once the document is set, the Project context window opens. This is the single highest-leverage step in the whole flow.

Supporting documents

Upload or link everything relevant to this deal. Supported formats are .txt, .pdf and .docx, up to 20 files.

The most important one is the solicitation or requirements document — the RFP itself. SiftHub identifies it automatically from what you attach; you do not tag it. This is what tells SiftHub which sections the proposal needs and what each one has to address.

Beyond that, attach anything that makes the response specific rather than generic:

• Call notes and discovery notes — what the buyer said their problem was, in their words
• The buyer's own materials — their annual report, their tech stack, their stated priorities
• Any prior correspondence about this deal

Facts from these documents take precedence over your general knowledge base. If your knowledge base says you support twelve integrations and the call notes say the buyer only cares about Salesforce and Snowflake, SiftHub writes about Salesforce and Snowflake.

Instructions

The Instructions tab is a single free-text field, and it overrides everything else. Use it for anything SiftHub could not work out from the documents.

Useful things to put here:

• Sections to skip or keep. Do not include the pricing section — we are submitting commercials separately. Keep the About Us exactly as it is.
• Tone and length. Keep responses short and crisp. Formal tone throughout — this is a government bid.
• How answers should be written. Keep answers concise. Do not cite external links. Always spell out acronyms on first use.
• Facts about this deal that are not in any document. The incumbent is Acme. Do not name them, but the transition section should address switching cost.
• Named people or numbers. Project lead is Priya Nair. Proposed go-live is 1 March.

Formal tone, UK English. Skip the Pricing section entirely. The buyer's main concern from the discovery call was data residency in the EU — make sure Security & Compliance addresses it directly. Keep the Executive Summary under 400 words.

Click Continue when you are done. You can add supporting documents to the project later from the Project documents tab, and you can come back to your instructions at any time.

Answer settings and sources

Back on the Create Project page, the document row carries three controls. They work the same way here as they do on a questionnaire project, and they apply to the whole proposal.

Instructions

Opens Additional instructions. This is the same field as the Instructions tab in the Project context window — anything you typed there appears here, and editing it in either place changes the same text. It is simply a second way in, so you can revise your instructions without reopening Project context.

Sources

Opens Source Filters, which controls what SiftHub is allowed to draw on when it generates. Two parts:

• Set sources — a row of chips for every source connected to your workspace: Documents, Q&A Repository, Google Drive, HubSpot, Slack, Zendesk, Zoom, Jira, Clari, Google Calendar, Website, Notion. Click a chip to include or exclude it. Select all and Deselect all are at the top right.
• Select collections — pick one or more Collections and answers will only be generated from sources inside them.

Worth restricting when the proposal has a compliance angle. For a government bid or a security-heavy RFP, narrowing to your Q&A Repository and a vetted Collection means every answer traces back to content someone has already approved. For a commercial proposal where you want the richest possible context, leave everything on.

Whatever you set here shows up later against each individual response, so a reviewer can see which sources produced a given answer.

Settings

Opens Autofill settings.

• Generation mode — how much reasoning SiftHub applies before answering.
• Set language — the output language. Defaults to English (US); the dropdown is searchable.
• Length — how long responses should be. Standard is balanced and precise.

Under Advanced are the two context toggles, and they matter more than the rest:

• Supporting documents context (on by default) — personalises responses using the instructions, reference docs and deal notes you added to the project's supporting documents. Leave this on. Turning it off means SiftHub ignores the RFP and your call notes.
• Deal context from connected sources (off by default) — personalises responses using deal context pulled from your CRM, call recordings, Slack and other connected tools. Turn this on when the opportunity is already well documented in HubSpot or your call recordings and you want SiftHub to use it without you attaching anything by hand.

Click Apply to save. You can change all three of these later from inside the proposal.

Creating the project

Fill in the project name, owner, delivery manager, due date and any other fields your workspace uses, then click Create.

This is the moment everything happens: SiftHub creates the project, creates the document, and starts generating. You land in the editor with the proposal being written in front of you.

How SiftHub writes the proposal

Understanding this helps you set up better projects and know what to check first.

1. It reads your template's structure

SiftHub works out what sections exist, what is already written in them, and how they are formatted — heading levels, fonts, colours. New content it writes will match. With a blank document, there is no structure to read, so it builds one.

2. It reads the solicitation and pulls out requirements

SiftHub goes through the requirements document and extracts what the buyer is actually asking for: the sections they have specified, the content each one must contain, and every individual question or requirement.

3. It maps requirements to sections

Each requirement is matched to the section it belongs in. A question about encryption at rest goes to your Security section. A requirement about phased rollout goes to Implementation.

Where the buyer asks for something your template does not have a home for, SiftHub adds a new section, positioned as close as it can to where the solicitation implies it belongs. So if the RFP requires a Transition Plan and your template has no such section, one appears.

4. It writes each section response

For each section, SiftHub writes the prose — grounded in your instructions first, then the deal documents, then what the solicitation asks for in that specific section, then how you have written that kind of section in past proposals, then your knowledge base.

That fourth input matters more than it sounds. SiftHub looks for past executive summaries when writing an executive summary, past technical approaches when writing a technical approach. The output should read like your company wrote it, not like generic AI prose.

5. It handles template content that is already there

This is the part worth understanding if you are using a template.

When the signals are mixed and SiftHub is not sure, it leaves your content alone. That is deliberate: if it wrongly leaves something generic, you fix it with one instruction in the editor; if it wrongly overwrites careful drafting, you have to go back to the original template. You can always override in either direction from the Instructions field — personalise the About Us for this deal, or keep the Executive Summary as it is.

6. It answers the questions

Questions inside sections are answered the same way SiftHub answers a questionnaire — matched against your Q&A Repository and documents, with sources cited. A section can have both a written response and a set of questions, and the two are handled independently.

7. It formats everything

With a template, SiftHub takes your fonts, colours and heading styles and applies them to what it writes. With a blank document, it uses your workspace's brand settings if configured, and SiftHub's defaults if not. Section responses are always body text, never heading styles, so a generated answer never comes out looking like a heading.

While it generates

The document structure appears first — cover page, headings, boilerplate — then sections fill in as they are written. You can scroll, read and start working on finished sections while the rest are still in progress. The progress indicator at the top updates as sections complete.

A worked example

You have received an RFP from VelocityEdge Media. You have a standard response template with a cover page, Executive Summary, About Us, Solution Overview, Security & Compliance and Legal Terms. The RFP asks for all of those plus a data migration plan, and includes twenty specific security questions.

You upload your template, attach the RFP and your discovery call notes, and write in Instructions: the buyer's main concern is migration risk from their current vendor, formal tone.

What you get:

• Cover page — untouched, your branding intact
• Executive Summary — written from scratch, leading with migration risk because that is what you flagged and what the call notes support
• About Us — your existing paragraph, left alone
• Solution Overview — your generic pitch rewritten around VelocityEdge's stated requirements
• Data Migration — a new section, added because the RFP asked for it and your template had no home for it
• Security & Compliance — your standard intro paragraph kept, with the twenty RFP questions added beneath it and answered from your Q&A Repository
• Legal Terms — untouched

Every section and question is in the Outline with a status and an assignee, ready for your team to review.

Getting better results

• Attach the solicitation. Without it SiftHub is writing a generic proposal. With it, it is answering this buyer.
• Attach call notes. This is the difference between a proposal that lists your capabilities and one that addresses their problem.
• Use the Instructions field properly. Two or three specific sentences are worth more than any other setting on the page.
• Fix your template once. Proper heading styles and clean placeholders improve every proposal you ever generate from it.
• Do not over-supply. Twenty loosely related documents dilute the context. Attach what is genuinely about this deal.
• Check the added sections first. Sections SiftHub added because the RFP demanded them are the ones most worth a careful read.

What happens next

Once generation finishes, the proposal is yours to review, refine and work through with your team. See Working on a proposal in the Web App.