Skip to content

Pitch / Proposal Builder

Part of: ClientVerse Core (every client).

What it is

A workspace for assembling a pitch or proposal from material the firm has already described, rather than rebuilding it from scratch each time. A Pitch_Proposal_Builder__c record is one pursuit's assembly; Pitch_Element__c records are the pieces pulled into it — experience, bios, credentials, and other reusable content.

The premise is that the expensive part of a proposal is not the writing but the finding: which of the firm's several thousand matters are the right three to cite, and who worked on them. The Builder is where that lookup pays off.

Who it's for

  • BD assembles the proposal.
  • Attorneys supply and validate the experience being cited.
  • Marketing maintains the reusable content — bios, credentials, boilerplate.

How it works

  1. A builder record is created for a pursuit, either empty or seeded from a pitch template.
  2. Relevant Experience is pulled in, filtered by practice area, industry, or other classification.
  3. Bios and credentials for the named lawyers are added.
  4. Supporting firm content is attached.
  5. The assembled set is exported for the client-facing document.

Each pulled-in item becomes a Pitch_Element__c. Since Core 1.1.10 an element snapshots its content when it is added, so a delivered pitch no longer changes when someone later edits a bio or an Experience. The same experience can still be cited across many pursuits; editing the source changes what new pitches pick up, not what existing ones already hold.

Lifecycle (since 1.1.10)

A pitch moves through Draft, In Review, Approved, Delivered and Archived. The pitch lock that protects Delivered and Archived pitches is CV automation, which ships switched off (CV_Trigger_Setting.Org_Default.Triggers_Enabled__c is false), so it does nothing until automation is enabled for the object.

PDF output (since 1.1.10)

A PDF can be generated from the element snapshots and stored as a versioned File, but no button for it ships yet. Pitch queries enforce field-level security, so restricted fields don't reach a pitch or its PDF.

Bio elements need field access

Bio elements read Professional Profile fields: Headline, Biography, Primary Image, Representative Matters, and the contact's email, phone and title. Grant read access to them through a profile or your own permission set; no packaged permission set grants it. Without it, Bio elements are skipped.

Upgrading from 1.1.7. The builder now reads only Sort_Order__c and Element_Type__c. On existing pitches, copy Element_Order__c into Sort_Order__c and fill in Element_Type__c, or those pitches lose their order.

This depends on upstream quality

The Builder is only as good as what it can find. Two upstream dependencies determine whether it works:

  • Experience must be captured. Work never described cannot be cited.
  • Experience must be classified. An unclassified Experience will not surface in the filters BD searches by, so it is functionally invisible even though the record exists.

If proposals are slow to assemble, the problem is almost always one of these rather than the Builder itself.

Opportunities vs pitches

Pre-engagement pursuits are often tracked as standard Salesforce Opportunities under the firm's naming convention, with the Builder handling the document assembly for that pursuit. The two are complementary: the Opportunity tracks the pursuit's lifecycle and value; the Builder produces the artifact sent to the client. How your firm relates them is a process decision — see the business-process library and the Glossary.

How to use it

  1. Open the Pitch / Proposal Builder in CV_BD.
  2. Create a builder record for the pursuit, or seed an empty one from a template.
  3. Filter Experience by the practice area or industry the pitch is about, and pull in the strongest matches.
  4. Add the bios of the lawyers being proposed.
  5. Add credentials and supporting content.
  6. Export for the client-facing document.