Review a proposal for missing scope before sending it

A proposal review should find what a customer might reasonably misunderstand. Use the assistant to compare the draft with the source requirements, then make the commercial decisions yourself.

Prepare the input

Supply the draft, customer requirements, approved capabilities, and any agreed exclusions. Give each document a version. Do not include live credentials or unnecessary customer data.

Run the workflow

Ask for a requirement-by-requirement matrix. Separate covered, partially covered, absent, and contradictory items. Then inspect assumptions about delivery, access, acceptance, and ongoing support.

Prompt to copy

Requirements: [text]. Proposal: [text and version].
Approved offer facts: [facts].
Create a matrix: requirement, proposal section, coverage, open question.
Flag unsupported promises, ambiguous scope, and missing acceptance criteria.
Distinguish an editorial suggestion from a commercial change.
Do not invent pricing or rewrite exclusions as included work.

Review a worked example

Illustrative requirement: “Create a calendar request.” The proposal says “Confirm bookings automatically.” That is a scope change, not stronger wording. The review should flag the required system access and transactional behavior. Check that every gap points to an actual section.

Also check definitions. A proposal can use the same word as the requirement while describing a different service. “Integration” might mean a manual export, a read-only lookup, or a live write. Ask the owner to resolve that ambiguity in the offer itself; a reviewer note alone will not protect the customer from misunderstanding.

Use it again

Resolve the questions with the offer owner, then rerun against the revised version. Keep the accepted version explicit. See Bot for document preparation and contact Golub to scope business-specific integration work.