Proposals

Proposals is Foundaro's client proposal pipeline. It gives you a template system for pricing and scope, a proposal builder that draws on those templates, and a tracking layer for internal approvals and e-signature status.

The module is built around the idea that proposal work fails when pricing, scope, and client communication are handled in separate tools. When everything lives in one place, you can see what is pending, what has been approved, and how much pipeline value is at risk — without chasing individual documents across email threads and shared drives.

Overview

The Proposals overview shows your templates and active proposals side by side.

Stat bar — Four key metrics:

• Templates — Total pricing and scope templates in your library.
• Proposals — Total proposals across all statuses.
• Sent / In review — Proposals that are actively in the client's hands.
• Pipeline value — Total value of proposals that are not declined or archived. This is the revenue at stake in your current proposal pipeline.

Templates panel — Your pricing and scope templates. Each shows the template name, kind (pricing or scope), a description, and the count of line items or scope sections. Edit or delete templates from this panel, or create new ones from the header buttons.

Proposals panel — Your active proposals, filterable by status. Each proposal card shows the title, client name, total value, number of line items, and valid-until date. Below each proposal, the approvals section and e-sign section are shown inline so you can take action without navigating away.

Tips:

• Build pricing and scope templates before you need them — proposals assemble faster when the building blocks are already defined.
• Set a valid-until date on every proposal to create urgency and keep your pipeline value calculation accurate.
• The pipeline value stat is most meaningful when proposals with no realistic path to closing are moved to declined or archived rather than left in draft or sent.
• Use the status filter to focus your view — filter to "sent" and "in review" to see what needs follow-up, and to "signed" to track closed business.

Templates

Templates are reusable building blocks for proposals. There are two kinds:

Pricing templates — Define a standard set of line items with descriptions and unit prices. Proposals built from a pricing template inherit these line items, which can then be customised for the specific client and engagement.

Scope templates — Define a standard set of scope sections describing what is included in the engagement. These provide the narrative layer that pricing templates do not cover.

A single proposal can draw from both a pricing template and a scope template to combine structured pricing with a defined scope narrative.

Template fields:

• Name — Required. The template name used when selecting it during proposal creation.
• Kind — Pricing or scope. This determines how the template is used and displayed.
• Description — A short description of when to use this template (e.g. "Standard monthly retainer" or "Full implementation scope").
• Line items (pricing templates) — Each line item has a description, quantity, unit price, and total.
• Scope sections (scope templates) — Each section has a title and body text describing what is included.

Tips:

• Create one pricing template per standard engagement type rather than one generic template for everything.
• Keep scope sections specific enough that clients can understand what they are agreeing to. Vague scope is the most common source of proposal disputes.
• Update templates when your pricing or scope changes — proposals assembled from outdated templates create inconsistency.

Proposals

Proposals are the client-facing documents assembled from your templates. Each proposal captures the full commercial and scope picture for a specific client engagement.

Proposal fields:

• Title — The proposal name (e.g. "Q2 Retainer — Acme Corp").
• Client name — Who the proposal is for.
• Status — Draft, sent, in review, approved, signed, declined, or archived. Update status as the proposal moves through the process.
• Total — The total value of the proposal, calculated from line items.
• Currency — The currency for the engagement.
• Valid until — The date after which the proposal is no longer valid. Used in the pipeline value calculation.
• Scope summary — A short narrative summary of what is in scope.
• Line items — The individual pricing rows making up the total.
• Approvals — Internal sign-off steps (see Approvals section).
• E-sign — Electronic signature tracking (see E-Sign section).

Tips:

• Move proposals through status stages as they progress — a proposal that sits in draft for weeks without moving to sent is usually a sign that something needs to be resolved before it goes to the client.
• Use the scope summary field as the tldr for the client — it should capture the most important thing they are agreeing to in one paragraph.

Approvals

Approval steps are internal sign-off checkpoints that a proposal must pass before it is sent or finalised. Each step has a label, an approver name, and a status (pending, approved, or rejected).

Approval workflow:

• Add approval steps when creating or editing a proposal.
• Each step starts as pending.
• Mark a step as approved or rejected from the proposal card in the overview.
• All steps must be approved before the proposal is considered internally cleared.

Tips:

• Add approval steps before the proposal is sent — approval workflows set up after the fact are rarely followed.
• Keep the step count small. Two or three sign-offs is a process. Eight sign-offs is a bottleneck.
• Use the approver field to name a specific person, not a generic role, so accountability is clear.

E-Sign Tracking

E-sign tracking records the electronic signature status for a proposal. It does not integrate with a specific e-sign provider — it is a manual status tracker that keeps the proposal record current with what is happening in your external e-sign tool.

E-sign statuses:

• Not sent — The signing request has not been sent yet.
• Sent — The client has been sent the document for signing.
• Viewed — The client has opened the document.
• Signed — The client has signed. Marking a proposal as signed also updates the proposal status to signed.
• Voided — The signing request was cancelled or voided.

Fields:

• Provider — The e-sign tool being used (e.g. DocuSign, HelloSign, PandaDoc).
• External ID — The document or envelope ID from the provider, for cross-reference.
• Signing URL — A direct link to the signing page if provided by the tool.

Tips:

• Update e-sign status as it changes so the proposal record stays accurate. Stale status creates confusion when reviewing the pipeline.
• Use the signing URL field to give the team a direct link to the document without searching for it in the e-sign tool.
• If a signing request is voided, update the status promptly so the proposal does not appear as pending in your pipeline view.

Activity

The Activity tab is an audit log of every action taken on your proposals — created, updated, deleted, and restored. It also supports version comparison and restoration.

Compare — For updated proposals, click Compare to see a side-by-side diff of what changed between a previous version and the current record. Fields compared include title, client, status, total, valid-until date, scope summary, and line item count.

Restore Version — Roll a proposal back to a previous version. Useful when an edit went in the wrong direction or overwritten pricing needs to be recovered.

Restore Proposal — Recover a deleted proposal. Deleted proposals remain in the audit log and can be fully restored.

Tips:

• Use version comparison before making a significant edit to understand what has already changed.
• Restore is non-destructive — restoring a version creates a new audit entry rather than silently overwriting history.
• Keep the activity tab in mind when a client disputes a previously quoted price — the log shows the exact version history.