Working on a proposal in the Web App

Once a proposal has been generated in SiftHub's document editor, this is where you review it, edit it, and work through it with your team. This article covers the editor end to end.

If your proposal lives in Google Docs, see Working on a proposal in Google Docs instead.

Opening the editor

Open the project and click the primary document, either on the Overview tab under Primary documents or on the Project documents tab. The proposal opens in a new tab.

You see the document laid out exactly as it will be delivered — cover page, headings, tables, images, page breaks — with the Outline on the right.

The top bar

Managing collaborators

Clicking the collaborator count opens Collaborators. Search for users and teams to add them, and see everyone who currently has access — the project owner is labelled, and anyone else can be removed with the cross beside their name. Click Done to apply.

Editing and viewing

One person edits a proposal at a time. Everyone else is read-only. This is deliberate — it prevents two people overwriting each other in a document where a single section can be rewritten wholesale.

The mode dropdown in the top bar offers:

• Editing — make changes to the proposal
• Viewing — read only, no changes

The first person to open the document gets Editing. Everyone after that lands in Viewing. Switching modes reloads the document, which takes a moment.

What you can still do in Viewing

Quite a lot. Viewing only locks the document content itself:

In Viewing, the toolbar is greyed out and the hover controls on each block are reduced — you will see the block's type, status and assignee, and can open its details, but the actions menu is hidden. Typing on the page does nothing. Everything collaborative still works from the details panel on the right.

In practice this means a reviewer never needs to take the document over. They read, comment, approve and reassign entirely from Viewing.

Sections, questions and everything else

The editor tracks two kinds of content and leaves everything else alone.

• Sections — named parts of the proposal. A section can hold written prose of its own, a set of questions, or both.
• Questions — individual requirements with their answers, either as question-and-answer pairs or as rows in a table.
• Independent blocks — cover pages, boilerplate, images, page breaks, anything that is not a section or question. These render and export exactly as they are, and are not tracked.

Sections and questions each have their own status, assignee, comments and history. That is what makes a proposal something a team can divide up.

Working on a block

Hover over any section or question to reveal its controls.

Actions you will see across the various states: Request content, Mark as updated, Submit for review, Approve, Reject, Change assignee, and on questions, Save answer to Q&A. For the detail on those two workflows, see Content Request Workflow and Content Review Workflow.

Save answer to Q&A is worth calling out: it is how a good proposal answer gets back into your Q&A Repository so the next proposal can reuse it. Doing this as you approve is the cheapest way to improve future generations.

Choosing it opens the Create Q&A form in a new tab, pre-filled with the question text, the current answer, you as Owner, and today’s date as the Q&A origin date. You must pick a Reviewer before it can be created; Status defaults to Draft. An alternate phrasing of the question, attachments, a next review date, Category, Industry, Source tags and Collections are all optional.

Read the pre-filled answer before you create it. The form takes the response as it stands, so anything you would not want in your repository — deal-specific detail, a half-finished sentence — needs editing out first.

Reviewing a response

Clicking Manage — or clicking any block on the page — opens its details on the right. The panel header shows the block type, arrows to move to the previous or next block, the main status action for the current state, and an actions menu.

AI answer details

The generated response, plus two collapsible areas beneath it.

Sources lists every document the answer drew on, with its owner, date and the connector it came from — Google Drive, Zendesk, and so on. Click through to open the source.

Generation settings records what was actually used to produce this specific answer: the instructions applied, the generation mode, the answer language, the length, the source types and the Collections. When an answer is not what you expected, this is the first place to look — it usually turns out a source was excluded or a Collection was restricting things.

Alternate answers

Other candidate answers, split into two tabs. AI answers shows generated alternatives with inline citations and a feedback row for thumbs up or down. Matched Q&As shows entries from your Q&A Repository that matched this question.

History

Everything that has happened to this block, in order — when SiftHub detected it, when it was autofilled, when it was edited, assigned, approved or rejected, and by whom.

Comments

A threaded discussion on this block. Mention a colleague with @ to notify them. Comments are per block, so a question about one requirement does not clutter the discussion on another.

Note: For a section with no written response of its own — one that is purely a container for questions — the details panel shows only History and Comments, because there is no generated answer to display.

The Outline panel

The Outline is the spine of the proposal. It lists every section with its status, assignee and progress through its questions.

• Click a row to jump the document to that section.
• Click the chevron to expand a section and see the questions inside it. Each question row shows its own status and assignee, and opens its own details.
• The header shows the total number of sections.

Acting on several blocks at once

Tick the checkbox on any section or question. The header checkbox selects everything. Once anything is selected, a Manage control appears next to the section count.

From it you can Request content, Mark as updated, Submit for review, Approve, Reject or Change assignee across everything selected at once.

This is how you divide a proposal up at the start of a review cycle: expand the security section, select its twenty questions, assign them all to your infosec lead in one action.

Editing the document

The proposal is a full document editor. In Editing mode, the toolbar above the page gives you:

• Zoom — scale the page view up or down
• Paragraph style — Normal text, Heading 1 through 6, Title, Subtitle
• Font and size
• Bold, italic, underline, strikethrough, text colour and highlight
• Link
• Alignment, bulleted and numbered lists, indent controls, line spacing

The overflow menu at the end of the toolbar holds the rest: image, table, divider, page break, list options, page setup and clear formatting.

Page setup

Page setup controls how the document prints and exports: page size, orientation, and the four margins in inches. Worth checking if you are matching a buyer's formatting requirements.

Selecting and formatting text

Select any text and use the toolbar to format it. Edits to a generated response are saved as part of that block, and show up in its history.

Adding sections, questions and content

There are two ways to add to the document, and they lead to the same place.

1. The plus between blocks. Hover between any two blocks and a plus appears. Click it and an empty block is inserted with the prompt Type / for commands.
2. The slash command. Type / anywhere in the document to open the same menu at your cursor.

The menu splits into two groups. The first three are SiftHub blocks:

• Add Section — tracked in the Outline, with its own status, assignee, comments and history
• Add Question — tracked in the Outline, the same way
• Independent block — not tracked in the Outline; use this for content that does not need reviewing

The rest are ordinary document elements: text, Heading 1, Heading 2, Heading 3, bulleted list, numbered list, table, image, divider and page break.

New sections and questions start in First draft with no assignee, and appear in the Outline immediately.

Converting and removing

If SiftHub read your template differently from how you would have read it — a heading it treated as a question when it should be a section, or a paragraph it tracked that you would rather it did not — use the type dropdown on the block to convert it or remove it from the Outline. Removing from the Outline keeps the content in the document; it just stops being tracked.

Exporting

Export in the top bar downloads the proposal as a .docx, exactly as it appears on screen — branding, tables, images, page breaks and all. It is available in both Editing and Viewing.

The proposal also feeds your project's submission package in the normal way, so exporting by hand is only needed if you want a copy outside SiftHub.

A suggested way to work

1. Read through in Viewing first. Get a sense of the whole document before changing anything, and leave the edit lock free.
2. Check the Outline against the RFP. Everything the buyer asked for should be a section. Anything SiftHub added is worth a careful look.
3. Divide the work. Select blocks in the Outline and assign them in bulk — security to infosec, pricing to commercial, the narrative sections to whoever owns the story.
4. Fix the structure before the prose. Convert and remove blocks first, so nobody spends time polishing a block that is about to be reclassified.
5. Use comments rather than edits when you disagree with a response but do not own it.
6. Save good answers to Q&A as you approve them.
7. Approve as you go. The progress indicator in the top bar is only meaningful if people approve rather than just reading.

Note: Refining proposals with AI directly from the editor's AI Teammate panel is coming soon.