SiftHub handles two kinds of response work. This article explains the second one — proposals — and how to decide where and how to build one.
Proposals and questionnaires
A questionnaire is a structured list of questions. A security questionnaire, a DDQ, a vendor assessment spreadsheet with 400 rows. The work is answering each item accurately, and SiftHub fills them in place.
A proposal is a document you write. An RFP response, a bid, a capability statement. It has an executive summary, a section on your solution, a section on implementation, maybe a pricing table and a set of specific requirements you have to address. Some of it is prose you compose; some of it is questions the buyer asked. The work is producing a persuasive document that covers everything the buyer requested.
Most real RFP responses are a mix. A single proposal might have a three-paragraph executive summary, a technical approach section with narrative plus twelve specific requirements, and a security section that is forty questions in a table. SiftHub handles all of it in one document.
What a proposal is made of
SiftHub reads a proposal as three kinds of content.
|
Type |
What it is |
Example |
|---|---|---|
|
Section |
A named part of the proposal. A section can hold a written response of its own, a set of questions, or both. |
Executive Summary, Security & Compliance |
|
Section response |
The prose written under a section heading — the paragraphs that make the argument. This is what makes a proposal different from a questionnaire. |
The three paragraphs under Executive Summary |
|
Question and its response |
A single requirement or question the buyer asked, with its answer. Questions can sit inside a section, either as question-and-answer pairs or as rows in a table. |
Do you hold SOC 2 Type II certification? |
Everything else in the document — cover page, table of contents, boilerplate paragraphs, logos, page breaks — is kept exactly as it is and is not tracked. This is called an independent block.
Sections and questions are tracked: each one has a status, an assignee, comments and a history. That is what makes a proposal something a team can work through rather than a document one person owns.
The four ways to start
Every proposal starts with two choices: what you are starting from, and where the document will live.
What you start from
- A blank document — SiftHub builds the structure from the buyer's requirements. Use this when the buyer has not prescribed a format, or when you do not have a standard template for this kind of bid.
- A template — your own proposal document, with your branding, standard sections and boilerplate already in it. SiftHub fills it in and adds anything the buyer asked for that your template does not already cover. Use this when you have a house format you want every proposal to follow.
Where the document lives
- In SiftHub — the proposal opens in SiftHub's own document editor. You see the finished layout, edit it in place, and export a .docx when you are done.
- In Google Docs — the proposal is written into a Google Doc, and you work on it there with SiftHub in a side panel through the browser extension.
Which one you are offered by default depends on whether your workspace runs on Google Workspace or Microsoft 365, but both are available either way.
|
|
Google Workspace |
Microsoft 365 |
|---|---|---|
|
Default |
Google Docs. SiftHub asks for a Google Doc link. |
SiftHub's editor. Your templates are Word files and your documents live in SharePoint or OneDrive, so there is no reason to route through Google Docs. |
|
The alternative |
Click Create in the web app instead or Upload template instead to work in SiftHub's editor. |
Paste a Google Doc link if you keep one. |
Choosing between them
Work in SiftHub's editor if you want everything in one place, if your team is on Microsoft 365, or if you want SiftHub to replace a specific section cleanly without you copying and pasting.
Work in Google Docs if your reviewers and approvers already live there, if you need several people editing simultaneously, or if the document has to be shared outside your organisation through Drive.
Note: In SiftHub's editor, one person edits at a time and others view. Google Docs gives you full simultaneous editing.
What SiftHub draws on
A generated proposal is only as good as what it has to work from. SiftHub uses, in order of priority:
- Your instructions — anything you type into the Instructions field when you set the project up. These override everything else.
- Deal and supporting documents — the solicitation, call notes, discovery notes, anything specific to this opportunity.
- The requirements document — what this particular buyer asked for, section by section.
- Your past proposals — how your company writes an executive summary, what your technical approach sections usually cover, the phrasing you actually use.
- Your knowledge base — product facts, certifications, standard messaging.
- Your response preferences — workspace-wide defaults for tone and style.
The practical implication: a proposal written with a solicitation and a set of call notes attached will be substantially better than one written from the knowledge base alone. It is worth the two minutes to attach them.