A consultant proposal and delivery handover should preserve exactly what the client accepted, then turn that agreement into owned delivery work. The CRM needs to connect proposal versions, scope, assumptions and project responsibility. Marking an opportunity as won is only useful when the delivery lead can tell what has been promised and what still needs deciding.
Begin at the moment delivery receives the work
Picture a project lead opening a newly won engagement. The proposal says “review current processes”, while the sales notes mention workshops at three offices. The price is visible, but the number of workshops is not. No dashboard can resolve that ambiguity; the handover must point to an accepted scope with enough detail to plan.
Work backwards from the questions that lead needs answered. What outcome is the client seeking? Which deliverables are included? Who supplies inputs? What constitutes completion? Who can make decisions? Record these answers in structured fields or clearly labelled sections, with links to supporting material rather than scattered message excerpts.
This approach is especially useful for advisory engagements that move from discovery into a defined project. Retainers and open-ended support need their own capacity and request rules. Do not force every commercial arrangement through an identical fixed-project handover.
The proposal should have an identity and a history
Keep an opportunity as the commercial pursuit and a proposal as a versioned offer within it. A revised price or deliverable list should create a new proposal revision. Preserve earlier revisions and show which was sent, superseded or accepted. The current editable working document should not silently replace the accepted record.
Record the accepting contact, acceptance date, method and supporting reference according to your business process. That is an operational record of the agreement, not a claim that the CRM determines contractual enforceability. Any unresolved condition should remain visible before work is scheduled.
Separate fee amount, currency, fee basis and billing milestones. A fixed fee, a daily rate and an estimated budget mean different things to delivery planning. Avoid using one unlabelled value field for all three. If an estimate assumes five days of work, retain that assumption even when the commercial headline is a total price.
Give assumptions an owner before they become delays
A project can depend on client interviews, data extracts, workshop attendance or access to an existing system. Model each dependency with an owner, needed-by date and consequence if late. A sentence buried in a proposal appendix is unlikely to drive someone's daily task list.
Distinguish an assumption from a confirmed input. “Client will supply a clean contact list” may be an estimating assumption; “file received and checked” is an operational event. When the assumption fails, create a review task for scope, timing or price instead of automatically expanding the team's obligations.
Keep exclusions visible as well. A process review might exclude software implementation or staff training. Delivery staff should see those boundaries before responding to a client request. Link any later approved addition to the original engagement, with its own scope and commercial decision.
A delivery lead's acceptance checklist
- Read the accepted proposal revision and confirm that deliverables can be identified individually.
- Check the planned team, estimated effort and proposed start against actual availability.
- Identify the client sponsor, day-to-day contact and people authorised to resolve scope questions.
- Review dependencies, exclusions and any outstanding discovery findings.
- Confirm where working documents, decisions and deliverable reviews will be recorded.
- Acknowledge the handover, or return it with specific missing information and an owner.
Allow a commercially won opportunity to remain “handover pending”. This makes the gap measurable without pretending that delivery has accepted the work. A returned handover should keep its history and reason. Sales can then fix the missing detail without creating a second opportunity or a duplicate project.
Test the awkward proposal revision
In a fictional test, a consultant sends revision one for two workshops and a findings report. Revision two adds a third workshop and changes the fee. The client accepts revision two, while a team member still has revision one open in another browser tab.
Create the project from the accepted proposal. Expect three workshops, the correct fee basis and a link to revision two. Attempt a second creation from the stale tab. The system should reject the superseded proposal or direct the user to the existing project, rather than produce conflicting delivery records.
Next, delay a client data extract that is needed for the report. The dependency should become overdue and reach the project lead's queue. It should not mark the report complete or alter the accepted deadline without an explicit decision. Add an approved follow-on workshop and confirm that it appears as a change, preserving the original scope.
Make the handover boundary visible in reporting
Track accepted proposals awaiting handover, handovers returned for clarification and engagements waiting for client inputs. Use separate dates for commercial acceptance, delivery acceptance and actual start. These answer different management questions and should not be replaced by a single “won date”.
Bring representative proposals into a pilot, including one with a revised scope and another with a postponed start. Ask the delivery lead to plan the work using only the new record. Every clarification they still need is evidence for improving the handover. The related field service quote-to-job workflow shows how the same acceptance boundary changes when delivery involves sites, equipment and visits.
To scope CRM development with Visuosofts, prepare an anonymised proposal and the questions your project team asks after a sale. Contact the team to turn those questions into a practical handover screen and acceptance criteria.