Working on a proposal in Google Docs

When a proposal is generated into a Google Doc, you write and review in Google Docs, with SiftHub alongside it in the Browser Extension. This article covers reviewing responses, checking where they came from, and collaborating with your team.

If your proposal lives in SiftHub's own editor, see Working on a proposal in the Web App instead.

Opening the proposal

Open the project from Projects and click the primary document on the Overview tab. The Google Doc opens in a new tab.

Make sure the SiftHub Browser Extension is installed and you are signed in. The Floating Widget appears at the edge of the document — that is where all SiftHub actions live while you are in Google Docs.

How this differs from the Web App

The practical difference: in Google Docs, SiftHub cannot edit a specific paragraph in place. It gives you the improved response and you paste it where you want it. Google Docs' version history is your safety net.

Reading the generated proposal

The proposal is written into your document under each section heading. Where the solicitation asked specific questions, the answers appear beneath the question text.

Answers are colour-coded so you can see at a glance what needs attention:

• Normal text — SiftHub found enough information to fully answer.
• Yellow highlight — a partial answer. Worth checking and completing.
• Red highlight — SiftHub could not find the information. You need to write this one.

Working through the yellow and red passages first is the fastest way to get a document to first-draft quality.

Reviewing a response

To see where a response came from and work on it, use Review AI answer.

1. Highlight part of the generated response, or part of the question text above it.
2. Click Review AI answer in the Floating Widget.

The response opens in the Browser Extension, where you can:

• Check its sources — every document the answer drew on, so you can verify a claim before it goes to a buyer
• See alternate answers and matched Q&As — other candidates SiftHub considered, including approved entries from your Q&A Repository
• Refine the answer with "Modify" presets — for example, make it shorter or change the tone.

When you are happy with it, copy the answer and paste it back over the original text in the Google Doc.

Note: You must highlight some text, not just place your cursor in it. If you only click into the text you will see "No answer associated with selection".

Review AI answer stays available in any document where SiftHub has generated at least once, so you can come back to a response days later and still see its sources.

Tracking progress and collaborating

Statuses, assignees and comments live in SiftHub, not in the Google Doc. That is what lets a team divide a proposal up and see how far along it is — Google Docs on its own has no concept of a section being approved or owned by someone.

Open the Projects tab in the Browser Extension while the document is open to work with the proposal's sections and questions without leaving Google Docs. The same information is in the web app on the project's Overview tab, in the Section / Question Progress panel.

Statuses

Every section and question carries a status, and the project's progress figure is the share of items that reach Approved.

Assigning work

Assign a section or question to whoever should own it, with a due date. Assignees see their items in My Tasks, and you can filter the project by assignee, status or due date to see what is outstanding. Overdue items are flagged.

Because a proposal has narrative sections as well as questions, you can assign a whole section to one person — they own the prose and every question inside it — or hand out individual questions. Security questions to your infosec lead, commercials to your deal desk, the narrative sections to whoever owns the story.

Requesting content and getting it reviewed

Two workflows do most of the work on a proposal:

• Request content — ask a colleague, a non-collaborator, or an external guest to write or improve a specific section or question. They can contribute without needing full access to the project. See Content Request Workflow.
• Submit for review — send content to a reviewer, who approves or rejects it with a comment. See Content Review Workflow.

For bringing in subject-matter experts who do not use SiftHub day to day, see Guest User Workflow.

Comments

Each section and question has its own comment thread in SiftHub. Mention a colleague with @ to notify them. Because comments are attached to the item rather than to a position in the document, they survive the text being rewritten — useful on a proposal where a whole section may be regenerated.

Note: Comments you add in Google Docs are Google's own comments and are not visible in SiftHub. Use Google's comments for line-level copy edits, and SiftHub's comments when you want the discussion tracked against the project.

History

Every section and question keeps a timestamped activity log — when SiftHub detected it, when it was generated, who edited it, who submitted it for review, and who approved it. Where an answer was edited, the entry shows what changed and offers a Compare changes view with the previous and updated versions side by side, removals in red and additions in green.

This is what makes a proposal auditable after the fact: months later you can see who approved a claim and what it drew on.

Working through several at once

Select multiple sections and questions and act on them together — request content, mark as updated, submit for review, approve, reject, or change the assignee across the whole selection. This is how you set a proposal up at the start of a review cycle rather than clicking through items one at a time.

For the fuller treatment of these workflows, see Document Collaboration in the Web App — the collaboration model is identical; only the document surface differs.

Editing the document

Everything else works as it normally does in Google Docs. Use Google's own toolbar for formatting, add sections and tables as usual, and rely on Google Docs' version history to roll back a change.

Edits you make by hand are kept. If you later review a response that has been edited since it was generated, SiftHub tells you the response has been modified so you know you are not looking at the original.

Finishing up

When the proposal is ready, download it from Google Docs in whatever format the buyer asked for — File > Download — or share the document directly. You can also add it to the project's Submission package in SiftHub to keep everything for the bid in one place.

A suggested way to work

1. Read the whole document first before changing anything, so you can see how the sections hang together.
2. Fix the red and yellow passages first — those are the gaps SiftHub already knows about.
3. Check sources on anything you would not say out loud to the buyer. Review AI answer is quicker than searching for the claim yourself.
4. Divide the work in SiftHub, not in the document — assign sections so people know what they own.
5. Regenerate with an instruction before rewriting from scratch. Asking for a shorter or differently framed version is usually faster.
6. Approve as you go so the progress numbers on the project mean something.

Troubleshooting

• Nothing generated into the document. Check that SiftHub's service-account email has Editor access to the Google Doc, and that the document sits in your My Drive or a folder your organisation has shared with SiftHub's service account. See Autofill in Google Docs for the access steps.
• "No answer associated with selection". Highlight some text rather than placing the cursor in it.
• The Floating Widget is missing. Check that the Browser Extension is installed and that you are signed in.
• The document is a .docx opened from Drive. Convert it first with File > Save as Google Docs.