Variation is handled by copying
A deal needs different terms, so somebody duplicates the template and edits it. Do that eleven times and you have eleven documents to keep current when legal changes one clause.
Templates · Conditional Content · Branding Sixty templates is not a library.
Sixty templates is not a library.
It is six templates and a copy habit.
Template sprawl is the most common condition we find in a live PandaDoc workspace, and it always has the same cause: somebody needed a variation and copying was easier than making the original adapt. Customization is the work of making one template handle many cases — conditional content, variables that pull real data, pricing logic, locked branding. Fewer documents, each of which does more.
1
3
14
100%
Trusted by 500+ organizations — including revenue, sales operations and legal teams running document generation, quoting and e-signature on Salesforce and HubSpot with Twopir Consulting.
What We Customise
- Salesforce Partner
- HubSpot Partner
- Dynamic Templates
- Conditional Content
- Content Library
- Pricing Tables
- Brand Lock
- Variable Mapping
Why your template library keeps growing
Sprawl is a symptom. These six causes are what actually produce it, and each has a specific configuration fix. None of them needs custom code.
Fields are typed, not mapped
Templates built with placeholders a rep fills in by hand. The platform is automating the layout and nothing else, which is why nobody can explain what it saved.
Clause language drifts
Legal updated the liability clause. Four templates got the update, seven did not, and nobody can tell which version a given customer signed without opening the file.
Reps edit the layout
Fonts change, logos move, sections get deleted. Every document looks slightly different, which reads to a buyer as a company that is slightly disorganised.
Pricing is assembled by hand
Discounts, options and bundles typed into a table. Arithmetic errors reach customers, and the quote and the CRM disagree from the moment it is sent.
Regional and entity variants multiply
Different terms per country, per entity, per currency — each one another copy, and the matrix grows faster than anyone can maintain it.
What Customization Covers
Configuration that makes one template do the work of ten
PandaDoc customization is configuration work inside the platform's own surfaces: template structure, variables and roles that pull data from your CRM, Content Library items for reusable clauses, smart content blocks driven by IF/THEN rules, pricing tables and quote configuration, and brand-locked design. It produces no code and leaves nothing for your engineering team to maintain — which is exactly why it is the right first answer to most "can PandaDoc do X" questions.
The mechanism that does most of the work is conditional content. PandaDoc's smart content blocks populate Content Library items based on variable or pricing-table values, using IF/THEN rules with operators like equals, contains and is empty. If the deal's country is the United States, the US terms appear; if it is the United Kingdom, the UK terms appear. One template, both cases, no copy. Most template libraries can be reduced substantially by applying this properly.
Three things, kept separate. PandaDoc provides the template engine, the Content Library, the rules and the pricing tables. Your CRM remains the source of the data those rules act on. Twopir designs the template architecture and builds it, then hands over the conventions that stop sprawl returning. We implement PandaDoc; we do not make it.
Where this stops: if a document needs data the connector does not expose, arithmetic the pricing table cannot express, or assembly from a system PandaDoc cannot see, that is development work against the REST API rather than customization. We say so during scoping rather than building something fragile.
Customise, consolidate, or extend beyond the template engine
Three different problems, often described in the same words. Most teams need the second one.
Customise
Building or reworking a document family so it reflects how you actually sell — the standard customization engagement.
- Template structure designed from your real output
- Variables and roles mapped to CRM fields
- Conditional content for deal-type variation
- Pricing tables with options and discount logic
- Brand system applied and locked
- Content Library built with legal's current clauses
Consolidate
For workspaces where the library has already sprawled. Fewer templates, more capability, and conventions that hold.
- Usage analysis to find what is actually sent
- Near-duplicate templates merged behind conditional logic
- Clause set rationalised with legal
- Dead templates retired rather than archived and forgotten
- Naming, versioning and ownership conventions
- Change-control process handed to a named owner
Build On
Where the template engine genuinely cannot express the requirement. Development, scoped as development.
- Data the CRM connector does not expose
- Calculations beyond what pricing tables support
- Document assembly from external systems
- Generation from custom objects
- Bulk or scheduled generation runs
- Embedded document experiences in your own product
| Requirement | Mechanism | Engagement |
|---|---|---|
| Different terms by country or entity | Smart content block, IF/THEN on a variable | Customise |
| Customer details filled from the CRM | Variables mapped to CRM fields | Customise |
| Optional products the buyer selects | Pricing table with optional items | Customise |
| Volume or tiered discounting | Pricing rules on the quote | Customise |
| One clause set, used everywhere | Content Library item referenced by templates | Customise |
| Eleven near-identical templates | Merge behind conditional content | Consolidate |
| Pricing maths the table cannot do | API-side calculation | Build on |
| Content pulled from a non-CRM system | API-side assembly | Build on |
The first six rows cover the overwhelming majority of what teams ask for, and none of them produces code. That is the point of scoping properly before quoting a development project.
The boundary, in one sentence: customization covers anything expressible as a rule over data the platform can already see. It stops where the document needs data PandaDoc cannot reach or arithmetic the pricing table cannot perform — and that is an API project with a maintenance cost, which we will name rather than disguise.
The six layers of a document that maintains itself
Each one a deliverable with a convention attached, so it stays correct after we leave.
Template Structure & Document Families
The decision that determines everything else: what counts as one document in your business.
- Document families defined from real sent volume
- One template per family, not per variation
- Section and block structure that supports conditionals
- Reusable headers, footers and signature blocks
- Naming and versioning conventions agreed upfront
Variables, Roles & Field Mapping
Where documents stop being typed. Every value in a document should have a source record.
- Field-by-field mapping from CRM objects to variables
- Role design for signers, approvers and counter-signers
- Auto-filled recipient details from role variables
- Fallback behaviour when a source field is empty
- Validation against real records, not sample data
Conditional & Smart Content
The mechanism that collapses a sprawling library into a governed one.
- Smart content blocks driven by IF/THEN rules
- Rules on variable values or pricing-table contents
- Regional, entity and currency variants in one template
- Product-specific sections appearing only when relevant
- Rule documentation so the logic is auditable
Pricing Tables & Quote Logic
Commercial rules the document enforces rather than the rep remembers.
- Line items sourced from the product catalogue
- Optional and recommended products the buyer can select
- Volume breaks, tiers and discount guardrails
- Tax, currency and multi-year structures
- Totals that reconcile with the CRM deal value
Brand System & Design
Documents that look like they came from one company, regardless of who sent them.
- Typography, colour and spacing from your brand system
- Locked layouts that survive rep editing
- Cover pages, dividers and signature presentation
- Accessible contrast and readable type in the PDF output
- Mobile-legible documents, since most first views are on a phone
Clause Governance & Content Library
One current version of every clause, in one place, owned by someone.
- Content Library built with legal's approved language
- Templates referencing library items rather than copying them
- Update process so a clause change propagates once
- Locked clauses reps cannot edit
- Review cadence agreed with legal
Where a customised document gets its content from
Every value in a well-built document has a named source system and a direction.
Salesforce → document variables
Account, Contact, Opportunity and product data populates variables at creation time, so customer detail and pricing come from the record rather than a rep's recollection.
HubSpot → document variables
Deal, company and contact properties populate quote variables, with deal line items driving the pricing table's contents.
Content Library → smart blocks
Clauses, terms and standard sections stored once and referenced by every template, so a legal update propagates rather than needing eleven edits.
Product catalogue → pricing tables
SKUs, tiers and pricing sourced from the catalogue, with optional items exposed for the buyer to select during review.
Role definitions → recipients
Adding a role generates its variables — name, email, company, address — so recipient detail auto-fills instead of being retyped per document.
Deal attributes → conditional rules
Country, entity, product mix, deal value and contract term drive which content blocks appear, using the platform's IF/THEN operators.
Brand assets → locked layout
Logos, typography and colour applied as a system rather than per template, so a rebrand is one change rather than a library-wide edit.
REST API → external content
Where a document needs content from a system PandaDoc cannot see. Development work — covered on our PandaDoc API development page.
Five phases, starting with what you actually send
We work from sent volume rather than from the template list. The gap between the two is usually the finding that pays for the engagement.
Library Audit & Usage Analysis
We inventory every template and, more usefully, analyse what is actually being sent. Most libraries have a long tail of templates nobody has used in a year, and rebuilding those is money spent on nothing.
Document Family & Rule Design
We define the document families, design the conditional rules that collapse variants into them, and specify the field mapping. You approve the architecture before anything is built.
Build & Brand
Templates, Content Library items, conditional blocks and pricing logic built in a sandbox workspace, with the brand system applied and layouts locked.
Validation Against Real Records
We generate documents from real records across the range of cases — including the awkward ones — and compare output against what the old templates produced, line by line.
Rollout, Conventions & Handover
Old templates retired rather than left alongside the new ones, conventions documented, and a named owner briefed on the change process that keeps sprawl from returning.
What changes when templates carry the logic
Real engagements, with the scope each number was measured against.
Dynamic Template & Token Architecture
Four document types rebuilt as dynamic templates · 500+ documents per month
14
Data points mapped to auto-populate
3
Conditional content scenarios
100%
Transaction data auto-populated
<60s
To a branded, data-accurate document
Proposal creation used to take a rep 45 minutes of copying data, fixing formatting, and hoping nothing was wrong by the time it reached the customer. Now they click one button inside Salesforce and a fully accurate, branded document is ready to send in under a minute.
Contracts, Offer Letters & KYC Forms
Three document families on one branded, conditionally driven template standard
3
Document families on one standard
1
Branded template system
0
Re-keyed record data
Native
Generation from the CRM record
Engagement scope: contracts, offer letters and KYC onboarding forms generated from Salesforce records with conditional sections by document type, replacing manual assembly in Word. Outcome metrics for this engagement are being confirmed with the client before publication.
Teams whose documents are the constraint
If the platform is fine and the documents are the problem, this is the engagement.
Sales ops teams managing a sprawling library
Templates multiplied faster than anyone could govern them, and you need the count to go down without capability going down with it.
Legal teams losing control of clause language
You cannot say with confidence which version of a clause a given customer signed. That is a Content Library problem with a known fix.
Marketing owners of brand consistency
Documents are a customer touchpoint and yours look like eleven different companies. Locked layouts solve it permanently.
Teams selling into multiple regions
Different terms, currencies and entities, currently handled by a matrix of copies that nobody can keep current.
Teams whose reps still type customer data
The documents are automated and the data is not. Mapping variables to CRM fields is usually the highest-return work available.
Companies preparing for an audit or a raise
Somebody is about to ask which terms are in force across your customer base. You want a defensible answer rather than a file search.
We reduce the library and increase what it can do
The goal is never more templates. It is fewer templates that handle more cases, with conventions that hold after we leave.
We start from what you send, not what you have
Usage analysis before design. Rebuilding a template nobody has used in a year is the easiest money to waste in this kind of project.
We design conditional logic deliberately
Rules documented and auditable, not accumulated. A conditional library nobody can explain is the next sprawl problem wearing a different hat.
We validate against real records
Including the awkward ones: empty fields, long company names, multi-currency deals, the customer whose legal entity does not match their trading name.
We work with legal, not around them
Clause language belongs to legal. We build the mechanism that makes their updates propagate in one edit rather than eleven.
We map fields as CRM specialists
As a Salesforce Partner and HubSpot Partner, the field mapping — picklists, formula fields, cross-object lookups — is where we are strongest.
We hand over conventions, not just files
Naming, versioning, retirement and change control, owned by a named person. Without that, the library sprawls again within a year, and we have seen it happen.
What teams ask about customising their documents
The questions that decide whether this is configuration or development.
Yes, and it is the single most effective thing you can do to a sprawling library. PandaDoc's smart content blocks populate Content Library items based on IF/THEN rules over variable or pricing-table values, using operators such as equals, contains and is empty. If the deal's country is the United States the US terms appear; if it is the United Kingdom the UK terms appear. The same mechanism handles entity, product mix, contract term and deal size.
Brand-locked templates. Layout, typography, logo placement and standard sections are set at the template level and made non-editable, while the fields reps legitimately need to change stay open. Combined with locked clauses for legal language, this removes the two most common sources of document inconsistency without making the template unusable.
No, and the difference matters commercially. Customization is configuration inside PandaDoc's own surfaces — templates, variables, Content Library, conditional rules, pricing tables. It produces no code and nothing for your engineers to maintain. Custom development means writing against the REST API, and it carries an ongoing engineering cost. Most requirements that sound like development turn out to be configuration; we scope that honestly before quoting.
Far fewer than most teams do. The right number is one per document family — one proposal template, one MSA, one order form — with variation handled by conditional content rather than by copies. If you have more templates than you have genuinely distinct document types, the surplus is copy habit and it can be consolidated.
Not through template configuration alone. Variables populate from the connected CRM and from values entered in the document. Content from another system — an inventory database, a pricing engine, a customer portal — has to be brought in through the REST API, which is development work. We will tell you which category your requirement falls into before you budget for it.
They get analysed, consolidated and retired — not left sitting alongside the new ones, which is how teams end up with both libraries. We identify what is actually sent, merge the near-duplicates behind conditional logic, and deliberately retire the rest with a documented record of what was removed and why.
Conventions and an owner. A naming and versioning standard, a documented change process, one named person who approves new templates, and conditional content capable enough that copying is never the easier path. Sprawl is a governance outcome, so governance is the fix — the platform will happily let you make sixty templates if nobody says no.
Yes, and we would rather work from them than invent something. We apply your typography, colour and layout rules as a template-level system rather than per document, which means a future rebrand is one change to the system instead of an edit to every template.
Next Step
If your library keeps growing and your documents keep drifting
Send us your template list and a month of sent volume. We will show you how many document families you actually have, how much of the library is copy habit, and what a consolidated set would look like.
12+ years · 500+ clients · 40+ consultants · Salesforce Partner · HubSpot Partner
