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.
Design and acceptance:
- Proposal Design - the layout. New proposals use your platform’s default design, which is an order form unless your administrator has changed it. The design is fixed once the proposal is sent.
- Acceptance Route - how the customer accepts. See Order forms and acceptance routes.
Optional content fields:
- Introduction, Scope Notes, Pricing 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.
Order forms and acceptance routes
Section titled “Order forms and acceptance routes”An order-form design produces a numbered order form that the customer can sign and return, as well as the web page. Each proposal’s Acceptance Route sets how the customer accepts:
| Acceptance Route | How the customer accepts |
|---|---|
| Accept online | On the proposal web page, by typing their name |
| Return a signed order form (fillable PDF) | By completing and returning the order form |
| Return a hand-signed printed order form | By printing, signing and returning the order form |
| Accept online or return a signed order form | Either way |
Online acceptance suits quick orders. A returned form suits larger orders, such as hardware, and the printed form suits orders that need a handwritten signature. The returned-form routes need an order-form design.
When a form comes back
Section titled “When a form comes back”A customer can return the form through MyAccount or by email. A returned form:
- raises a TODO for the deal owner
- shows the proposal under Returned forms to review on the Proposals page, and the deal as Returned form to review on Deals
- appears in the Customer Uploads panel, tagged Returned form
Uploading a form does not accept the proposal. Review it, then record the customer’s choices with Mark Accepted.
Upload a returned form for the customer
Section titled “Upload a returned form for the customer”Use Upload Returned Form on the proposal when the form reaches you another way, for example by post. Upload the completed form for this proposal version, up to 10 MB.
What you need: the CRM Proposals add or edit permission, or Accept on Customer’s Behalf. The proposal must have been sent and use a design that allows returned forms.
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 Acceptance Route asks for a returned order form, the customer returns the signed form through MyAccount or by email instead. See When a form comes back.
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 |
|---|---|
| Needs attention (default) | Proposals that need someone to act |
| Awaiting sending | Prepared proposals not yet sent |
| Returned forms to review | Returned order forms waiting for Mark Accepted |
| With the customer | 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.
Edit Proposal
Section titled “Edit Proposal”Choose Edit Proposal to change permitted draft details. The form protects customer identity, pricing evidence and system-managed states.
The Primary Contact list offers the customer’s contacts, and saving keeps the contact already chosen unless you change it.
Edit supporting attachments where their action is available. Sent or locked content remains subject to the proposal’s state and your permissions.
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, on paper, or on a returned order form.
Required:
- Agreed by (name).
- The customer’s choice for each family. For a required family, choose the accepted option. For an optional family, choose whether it is included.
Optional: Customer confirmed authority to accept, and How they agreed / notes.
Returned forms: where a form has come back, choose it as the Reviewed acceptance evidence and record the choices it shows. Where the proposal needs a returned form but none has arrived, tick Accept without returned form and explain why in the notes.
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 |
| Proposal Design | Configured proposal design; drafts follow the current design settings and the design is fixed once sent |
| Acceptance Route | How the customer accepts: online, by returning a signed order form (fillable or printed for a hand signature), or either; returned forms need an order-form design |
| Supersedes | Earlier proposal version this one replaces |
| Expired | When the proposal was automatically marked expired |
| Included Deals | Deals covered by every family on this proposal, 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 |
| Pricing Notes | Commercial qualifications and pricing 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 selected Deal when acceptance contains exactly one selected Deal; empty for multiple selections |
| 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 |
| Acceptance Evidence | Reviewed returned form or email attachment retained as evidence for this proposal version |
| 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 |
| Returned Form Override Reason | Reason an authorised operator recorded acceptance without a returned form |
| 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 |
Choose proposal recipients
Section titled “Choose proposal recipients”For a first send, copy or reminder, check the recipients offered for that action. Suggestions include eligible customer, contact, internal-team and previous addresses.
Proposal emails also allow other valid addresses without Expert Mode. Enter them on separate lines, or separate them with commas or semicolons.
Leaving the recipient selections blank uses the proposal’s default recipient path. Invalid explicit selections stop the send instead of silently changing recipients.
Confirmation emails have their own recipient requirement; the proposal exception does not apply to them.
What Viewed means
Section titled “What Viewed means”Viewed indicates that the customer has engaged with the proposal page. It does not mean they have accepted the proposal.
Acceptance and decline are recorded separately.