---
title: "How to Fix a PandaDoc Setup That Is Not Working: 7 Problems and Their Fixes"
description: "A diagnostic guide to fixing a stalled PandaDoc setup: empty merge fields, unused templates, hand-typed pricing, half-wired CRM integrations, and the repair for each."
canonical: https://pureproposals.com/pandadoc-setup-problems-and-fixes/
published: 2026-09-24
image: https://pureproposals.com/images/blog/pandadoc-setup-problems-and-fixes/0.png
site: Pure Proposals
type: article
---

# How to Fix a PandaDoc Setup That Is Not Working: 7 Problems and Their Fixes

> A diagnostic guide to fixing a stalled PandaDoc setup: empty merge fields, unused templates, hand-typed pricing, half-wired CRM integrations, and the repair for each.

_Source of truth: https://pureproposals.com/pandadoc-setup-problems-and-fixes/_

To fix a PandaDoc setup that is not working, find where your team falls back to the old way of making documents: that fallback point is almost always one of seven problems, and each has a specific repair. The most common are merge fields that arrive empty, templates nobody uses, pricing typed by hand, a CRM integration that is connected but not wired to anything, and an old Word or PDF route that was never closed.

This guide is for teams that already own PandaDoc and are not getting value from it. That situation is the norm, not the exception: most of the teams that contact us already own the software, and more than half of the companies across the 129 sales calls we analysed already owned HubSpot as well. If you are still planning a first build, start with the build-order guide to [PandaDoc implementation mistakes](/pandadoc-implementation-mistakes/) instead; this post is about diagnosing and repairing a setup that is already live and already broken.

## Key takeaways

- A broken PandaDoc setup shows up as a behaviour, not an error message: reps quietly go back to Word, duplicated templates, copy-paste from the CRM. Diagnose from the behaviour backwards.
- The seven problems below cover almost every stalled setup we are asked to rescue. Each has a symptom you can spot in five minutes and a fix that does not require starting over.
- Repairing an existing setup is usually faster than the original build, because the failure points are visible. You are not guessing what the team needs; the workarounds tell you.
- The test for "fixed" is a number: minutes from a verbal yes to a sent document. Manual creation time was the top pain in 82 of the 129 calls we analysed, with 45 to 50 minutes per proposal typical before repair.

## Diagnose from the workaround, not the settings screen

PandaDoc rarely fails loudly. What fails is adoption, and adoption failure always leaves a trail of workarounds: a rep who exports to Word "just for this one deal", an ops person who re-types deal data because the fields never fill themselves, a founder who still builds every proposal personally because nobody trusts the templates.

So start the diagnosis away from the admin panel. Ask each person who sends documents two questions: what did you send last week, and how did you actually make it? The gap between the official process and the honest answer is your problem list. Then match each workaround to the problems below.

## Problem 1: Merge fields come through empty

**Symptom:** documents generate with blanks, raw tokens like `{{Client.FirstName}}`, or stale placeholder text, so reps stop trusting generation and type everything manually.

**Cause:** the template's variables were never mapped to CRM properties, or they were mapped to properties your team does not consistently fill in. A mapping to an empty field is indistinguishable from no mapping at all.

**Fix:** open your most-used template and list every variable it contains. For each, confirm three things: it is mapped to a CRM property, that property is actually populated on real records, and the property is filled in before the stage where documents get created. Where a property is usually empty, either make it required at an earlier deal stage or remove the variable and accept a manual field. A template with 8 reliable variables beats one with 25 theoretical ones. If fields still refuse to populate after the mappings check out, the specific failure modes are covered in our guide to [PandaDoc merge variables not populating](/pandadoc-merge-variables-not-populating/).

## Problem 2: Templates exist but nobody uses them

**Symptom:** the template library has real content in it, yet documents keep being created from scratch, from duplicated old documents, or outside PandaDoc entirely.

**Cause:** the templates were built as one-off showpieces rather than working tools. Usually they mirror one specific past deal, so every new deal needs enough editing that starting fresh feels easier. Sometimes they were built by someone who has since left, and nobody knows which of six similar templates is current.

**Fix:** consolidate before you improve. Pick the one document type your team sends most, nominate a single template as canonical, and archive the rest so the choice disappears. Then rebuild that template around what changes per deal: variables and pricing tables for deal specifics, locked content blocks for everything else. A rep should only ever touch the parts that are genuinely deal-specific. That is the difference between a template and a sample document, and it is the core of a proper [PandaDoc template build](/pandadoc-services/pandadoc-templates/). Off-brand output is not a side issue here either: looking unprofessional was the second most common pain in our dataset, raised in 44 of 129 calls, and locked blocks are what stop each send drifting further from the brand.

## Problem 3: Pricing is still typed by hand

**Symptom:** every proposal involves someone looking up prices in a spreadsheet, calculating totals outside PandaDoc, and typing the results into the document. Pricing errors get caught late or not at all.

**Cause:** the pricing table was placed in the template but never connected to a catalog, so it is a formatted grid rather than a pricing system. Fear of pricing errors came up in 28 of the 129 calls we analysed, and hand-typed tables are where those errors come from.

**Fix:** move your products into PandaDoc's catalog so line items are picked, not typed, with list prices attached. Set quantity and discount permissions so reps can adjust what they should and nothing else. If your pricing has real structure, tiers, bundles, multi-year terms, or rules that depend on region or tax status, a catalog alone will not hold it and you are into [PandaDoc CPQ](/pandadoc-services/pandadoc-cpq/) territory, where the rules live in the system instead of in one person's head. One team we spoke to was assembling 60-month pricing models from Excel and CRM data by hand for every deal; that is not a template problem, it is a missing pricing engine.

## Problem 4: The CRM integration is connected but nothing flows

**Symptom:** the integration shows as installed and healthy, yet reps still copy contact names, addresses, and deal values from the CRM into documents, and document status never appears back on the deal.

**Cause:** "connected" is the start of an integration, not the end. The connection gives you the pipes; someone still has to decide which objects create which documents, which fields fill which variables, and what writes back. Skip that and you get the pattern we see constantly: a person becomes the integration, re-keying data between two systems that are nominally linked. In one company we analysed, a team member manually re-added product data between systems every few days as a standing workaround.

**Fix:** wire the three flows that matter, in order. First, document creation from the CRM record, so a proposal starts from the deal and inherits its data. Second, field population, which is Problem 1's mapping work done against real CRM properties. Third, status writeback, so sent, viewed, and signed appear on the deal without anyone asking. For the majority of the teams we work with that means the [PandaDoc HubSpot integration](/pandadoc-integrations/hubspot/), and the same three flows apply on Salesforce or any other CRM.

## Problem 5: The old route was never closed

**Symptom:** the setup works when people use it, but half the team still sends from Word, PowerPoint, or a shared drive of old PDFs. Usage graphs sag a few weeks after launch and never recover.

**Cause:** go-live happened without a cutover. The new system was introduced as an option, the old files stayed exactly where they were, and under deadline pressure every rep chooses the route they already know. No tool survives competing with its predecessor at zero switching cost.

**Fix:** retire the old route deliberately. Archive the old template files somewhere read-only, announce a date after which proposals only go out through PandaDoc, and have managers route stragglers back rather than accepting exceptions. Pair the cutover with a first-week sending target per rep, because the fastest way to make the new route the default is to make everyone use it while help is on hand. This is a rollout problem rather than a software problem, and it is most of what structured [PandaDoc onboarding](/pandadoc-services/pandadoc-onboarding/) exists to prevent.

## Problem 6: Documents go out, then problems start

**Symptom:** creation works, but delivery and signing leak: clients say they never received the document, signature requests stall, or signed data never makes it back into your systems.

**Cause:** the last mile was never tested from the client's side. Sending domains were left unauthenticated so emails land in spam, signature fields were placed on some templates and not others, and nobody defined where signed-document data should land.

**Fix:** send a test document to an outside address and walk it end to end as if you were the client. Fix deliverability first, since a proposal in a spam folder undoes everything upstream; our [PandaDoc emails going to spam](/pandadoc-emails-going-to-spam-fix/) guide covers domain authentication step by step. Then confirm every template that needs a signature actually carries assigned signature fields, and decide where completed-document data flows so the deal record, not an inbox, is the source of truth.

## Problem 7: It works, but only one person can run it

**Symptom:** documents go out fine as long as a specific person is available. When they are on holiday, proposals wait.

**Cause:** the setup was built around a person instead of a process. One admin holds the knowledge of which template to use, what pricing applies, and how to handle exceptions, so every document routes through them. This is founder-dependency rebuilt inside a new tool, and it caps output: one company we analysed was sending only around 5 proposals a month because creation was so cumbersome, and said openly they would send more if it were easier.

**Fix:** move the knowledge from the person into the system. Exception rules become approval workflows, pricing knowledge becomes the catalog and its permission settings, template choice becomes a one-template-per-document-type library. Then measure the result: reps creating and sending documents end to end, unassisted. Teams that make this shift see creation time collapse, with around an hour per document dropping to 5 to 10 minutes in the best documented case in our dataset.

## Repair or rebuild: how to decide

Most stalled setups need repair, not replacement. The rule of thumb: if the account structure is sound, meaning the right plan, a sensible workspace, and templates built natively rather than as PDF backgrounds, then fix the problems above in place, starting with whichever one your team's workarounds point at. Repair is usually faster than the original build, because the evidence of what the team actually needs is sitting in their workarounds.

A rebuild is worth considering in two cases. First, when the templates were built as PDF backgrounds on top of old Word exports, because there is no incremental path from a static background to a variable-driven template. Second, when the document map has genuinely changed, for example after a rebrand, an acquisition, or a move to a new CRM, so the old structure no longer matches the business. Even then, the rebuild follows the same sequence as a first [PandaDoc implementation](/pandadoc-implementation/), just with better information.

## When to bring in a PandaDoc expert

Run the diagnosis above and fix what you can in place; much of it is configuration work any careful admin can do. Bring in outside help when the fixes cross systems: pricing logic that needs CPQ, CRM wiring across objects and pipelines, or a template architecture that has to survive dozens of reps. That combination is where DIY repairs stall, usually because the person who could do the work is also the person whose calendar the whole document process already runs through.

That rescue work is most of what we do. Pure Proposals is a Certified PandaDoc Premier Partner, and the most common project we take on is not a fresh implementation but exactly this: a team that owns PandaDoc and a CRM, has had them "set up" for months, and needs someone to [fix their PandaDoc setup](/get-pandadoc-help/) so the tools they are already paying for start paying them back. We work inside your account, on your subscription, and everything we build stays yours.

## FAQ

### How do I know if my PandaDoc setup is broken or just underused?

Underuse is a symptom, so trace it to a cause. Ask the reps who avoid the system what they do instead and why; if the answer involves empty fields, wrong pricing, or "it is faster in Word", the setup is broken in one of the seven ways above. If the answer is "I did not know we had it", you have a rollout gap, not a configuration one.

### Can I fix a stalled PandaDoc setup without starting over?

Usually, yes. Empty merge fields, unused templates, hand-typed pricing, half-wired integrations, and missing cutovers are all repairable in place. The main exception is templates built as PDF backgrounds from old Word documents, which need rebuilding natively before variables and pricing tables can work.

### How long does it take to fix a broken PandaDoc setup?

Single problems, such as remapping variables or authenticating a sending domain, are hours of work. A full repair covering templates, catalog pricing, and CRM wiring typically lands in the 2 to 4 week range, faster than a from-scratch build because the diagnosis is already done by the team's workarounds.

### Why do my PandaDoc merge fields keep coming through empty?

Either the variable is not mapped to a CRM property, or it is mapped to a property your team does not fill in reliably. Audit the mappings on your most-used template first, then make the source properties required at an earlier pipeline stage so the data exists before the document does.

### Do I need a PandaDoc expert or can my team do this internally?

Configuration-level fixes are realistic internally if someone owns them. The cases that justify outside help are structural: CPQ-grade pricing rules, multi-object CRM integrations, and template architectures for larger teams. The deciding factor is usually not skill but time; if the only person who could fix the system is also the busiest person in it, the repair will keep losing to the day job.