Proposals
A proposal turns a deal into something the customer can read and accept. It produces a branded PDF and a secure web page showing the same detail, and records every send, view, acceptance and decline.
What you need: the Sales section, the CRM Proposals permission, and the Proposals feature.
Building a proposal
Section titled “Building a proposal”Generate Proposal on the deal opens the form.
Optional content fields:
- Introduction, Scope Notes and Closing Notes - your covering wording, formatted as richly as you like.
- Requested Upload 1, 2 and 3 - descriptions of documents you want back from the customer, such as a signed authority letter.
- Valid Until - when the proposal expires.
- Correspondence Type - which template the emailed proposal uses.
- Include Current Provider Comparison - selected by default where a comparison exists.
Acceptance Payment section:
- Payment required on acceptance - one of No tier payment, Setup (the one-off deal charges), Connections (setup plus connection charges), or First period (connections plus one recurring billing period).
- Additional deposit (before VAT) - a deposit can still be required when no tier payment is chosen.
- Direct Debit required - after acceptance, require a mandate unless a suitable one already exists.
Deal Families section: where the deal group contains independent families, choose a Proposal role for each (Not included, Required choice or Optional choice), a customer-facing Label and an Order. Required families need a customer choice; optional ones can be left out. Each included family brings its existing alternatives with it.
What happens: the proposal is created as a draft with a version number, and its PDF is produced in the background.
Approval before sending
Section titled “Approval before sending”Your platform can require management approval before a proposal goes out. The mode is set per dealer:
| Mode | Behaviour |
|---|---|
| Off | Anyone who can send, sends. |
| Flagged | Approval is needed only where margins are thin or buy costs are incomplete. |
| Always | Every proposal needs approval. |
Request Approval puts it forward; Approve Proposal and Reject Proposal need the Approve Proposal capability. Holders of Send Without Approval bypass the queue entirely.
Important: an approval is bound to the pricing it was given for. Re-pricing the deal afterwards clears the approval, and it must be requested again. This is deliberate, so an approver can never be shown one set of figures and have another sent.
Sending
Section titled “Sending”Send Proposal emails it and takes the deal “with the customer”. Generate Proposal Link mints a shareable acceptance link instead, without sending anything, for when you would rather deliver it through your own channel.
Important: sending freezes the deal and its pre-sale products until the customer answers or you withdraw the proposal. See the proposal freeze.
Send Reminder chases a proposal that is still with the customer and still inside its valid-until date. Proposals also chase themselves towards expiry, and expired ones are swept up automatically.
Supporting documents and customer uploads
Section titled “Supporting documents and customer uploads”Add Attachment uploads a document to this proposal. Attach from Library picks from the shared Attachment Library maintained in CRM Setup, so a standard terms document or case study does not need re-uploading each time.
Every send carries the proposal PDF itself, so attachments are for the extras.
Requested Uploads asks the customer for documents back. Describe up to three, leave a box blank to request nothing, and save. Anything the customer sends appears in the Customer Uploads panel, tagged by whether it arrived through the portal or by email.
Important: requests can only be changed while the proposal is a draft.
What the customer sees
Section titled “What the customer sees”The customer gets a web page carrying the proposal in full: the introduction, an itemised table of the products and services with their features nested underneath, the recurring and one-off charges, any additional charges, the scope and closing notes, and a collapsible terms and conditions section. The PDF is downloadable from the same page.
They accept by typing their name. Depending on your settings they may also confirm they have authority to accept, and the Proposal Acceptance Signature setting decides whether a signature is required, optional or off.
Where the proposal offers alternative options, an option switcher lets them compare and choose one.
What happens on acceptance: the acceptance is recorded with the name, date, address and browser used; an acceptance confirmation PDF is produced; the deal is marked accepted; and any payment or Direct Debit requirement moves to its next state.
Once the proposal is answered the detail comes off the page and it falls back to the headline figures and the PDF link, leaving the PDF as the record of what was agreed.
Working the proposals list
Section titled “Working the proposals list”The Proposals page gives status views for the whole team:
| View | Shows |
|---|---|
| With the customer (default) | Sent, viewed and accepted |
| Awaiting response | Sent or viewed, still unanswered |
| Expiring soon | Inside the reminder lead time |
| Needs chasing | Overdue a reminder |
| Accepted | Answered yes |
| Signed - payment / DD outstanding | Accepted but not yet ready to go live |
| Declined, Expired, All | The rest |
Columns are Customer, Deal, version, Status, Payment, Direct Debit, Amount, Sent and Valid until, with the valid-until date in red once an outstanding proposal has passed it. Hovering an accepted status shows how it was accepted: through the emailed link, in MyAccount, or recorded by an operator.
Export CSV downloads the current view.
Actions on a proposal
Section titled “Actions on a proposal”Download PDF, Generate PDF and Recreate PDF
Section titled “Download PDF, Generate PDF and Recreate PDF”Download PDF fetches the produced document. Where none exists yet you get Generate PDF; where one does, Recreate PDF rebuilds it from the current data.
Email Proposal
Section titled “Email Proposal”Sends or resends the proposal to the customer.
Mark Accepted
Section titled “Mark Accepted”Records an acceptance that happened away from the web page - by phone, by email or on paper.
Required: the Accepted option where the group offers a choice, and Agreed by (name).
Optional: a tick that the customer confirmed their authority to accept, and notes on how they agreed. Where the proposal covers several families, record one accepted option for each required family.
Important: this needs the Accept on Customer’s Behalf capability.
Withdraw Proposal
Section titled “Withdraw Proposal”Takes the proposal back. The emailed links stop serving it, the deal unfreezes, and a corrected version can be generated.
Waive Payment / DD Requirement
Section titled “Waive Payment / DD Requirement”Releases a deal held from go-live by an unmet acceptance payment or Direct Debit requirement.
Required: a Reason.
Important: the waiver and its reason are permanently audited, and it needs the Accept on Customer’s Behalf capability.
Payment and Direct Debit requirements
Section titled “Payment and Direct Debit requirements”Where a proposal asked for a payment or a mandate on acceptance, each requirement carries its own state: not required, required, processing, satisfied, failed, waived, reversed or configuration error.
A deal cannot go live until every requirement is satisfied or waived. The Proposals list has a Signed - payment / DD outstanding view for exactly this, and Sales Home carries a matching card.
Field reference
Section titled “Field reference”Proposal
Section titled “Proposal”Deal, customer, contact, version and current status of this proposal.
| Field | Description |
|---|---|
| Customer | Customer this proposal is for |
| Primary Contact | Main contact at the customer for this proposal |
| Reference | System-generated reference for this proposal |
| Version | Version number of this proposal |
| Status | Current state of the proposal (draft, sent, viewed, accepted, declined, withdrawn, expired) |
| Valid Until | Date until which this proposal remains valid |
| Correspondence Type | Correspondence type whose email template delivers this proposal; leave blank for the standard proposal email |
| Supersedes | Earlier proposal version this one replaces |
| Expired | When the proposal was automatically marked expired |
| Included Deals | Deals covered by this proposal (the primary plus its alternatives), snapshotted at generation |
Content
Section titled “Content”Generated proposal document and the deals presented as alternatives.
| Field | Description |
|---|---|
| Introduction | Opening section shown at the top of the proposal |
| Scope Notes | Scope or summary notes included in the proposal |
| Closing Notes | Closing section shown at the end of the proposal |
| Requested Upload 1 | Description of a document the customer is asked to upload on the approval page; leave blank to request nothing |
| Requested Upload 2 | Description of a second document the customer is asked to upload; leave blank to request nothing |
| Requested Upload 3 | Description of a third document the customer is asked to upload; leave blank to request nothing |
| Includes Current Provider Comparison | Whether this proposal version shows the snapshotted current-provider savings comparison |
Delivery
Section titled “Delivery”How and when the proposal was sent to the customer.
| Field | Description |
|---|---|
| Generated PDF | Generated proposal PDF document |
| Correspondence | Correspondence record for the emailed proposal |
| Sent By | User who sent the proposal to the customer |
| Sent | When the proposal was sent to the customer |
| Viewed | When the customer first opened the proposal |
| Downloaded | When the customer first downloaded the proposal PDF |
| Reminder Sent | When an expiry reminder was last automatically sent to the customer |
Acceptance
Section titled “Acceptance”Customer response, chosen option and acceptance evidence.
| Field | Description |
|---|---|
| Acceptance Method | How the proposal was accepted (e.g. email magic-link) |
| Accepted By (Contact) | Customer contact who accepted the proposal |
| Accepted By (Email) | Email address the proposal was accepted from |
| Chosen Deal | The option (deal) the customer chose when accepting a multi-option proposal |
| Accepted By (Name) | Name entered by the person who accepted the proposal |
| Authorised Confirmation | Whether the person accepting confirmed they were authorised to accept on behalf of the company |
| Accepted For (Company) | Company name shown in the authority confirmation at acceptance |
| Accepted | When the proposal was accepted |
| Accepted IP | IP address the proposal was accepted from |
| Accepted User Agent | Browser user agent recorded at acceptance |
| Decline Reason | Reason the customer gave for declining the proposal |
| Declined By (Contact) | Customer contact who declined the proposal |
| Declined By (Email) | Email address the proposal was declined from |
| Declined | When the proposal was declined |
| Declined IP | IP address the proposal was declined from |
| Declined User Agent | Browser user agent recorded at decline |
| Acceptance Confirmation | Generated acceptance confirmation PDF recording who accepted what and when |
System Information
Section titled “System Information”| Field | Description |
|---|---|
| Created By | User who created this proposal |
| Created | When this proposal was created |
| Last Modified | Timestamp of the most recent modification to this proposal |
| Last Updated By | User who last updated this proposal |