Most teams don't have a document problem — they have a data problem. Quotes, proposals and contracts get rebuilt by hand because CRM data never reaches the template, and the signed version never makes it back to the record. Twopir designs, configures and integrates PandaDoc so documents generate from Salesforce data, route through the approvals your business actually requires, and report their own status. Implementation, customization, integration and support from one team.
Trusted by 500+ organizations — including real estate, professional services and technology teams running document generation on Salesforce and HubSpot with Twopir Consulting.
PandaDoc Delivery Capabilities
Document problems are rarely about the document. They are about where the data lives, who is allowed to change it, and what happens after the file is sent. Every manual step is a place where accuracy and speed leak out.
A rep copies last quarter's proposal, edits the client name, re-types pricing from the opportunity, and hopes nothing was missed. The work is repeated in full for every deal, and the quality depends entirely on who did it.
Regions, product lines and legal revisions each spawn another version. Without a governed template and content library, teams choose the wrong one — and the wrong terms go out under your brand.
Account details, contract terms, line items and pricing exist in Salesforce, then get re-keyed into a file. Re-keying is where the errors come from, and it is also why the CRM and the signed agreement disagree a month later.
Discount sign-off, legal review and executive approval run through inboxes and chat threads. There is no enforced sequence, no record of who approved which version, and no way to report on how long approval really takes.
The agreement is executed, then lives in a personal drive or an email thread. Renewal dates, negotiated terms and the executed PDF are invisible to the team that has to service the account next year.
A process that works for one team of five collapses at fifty users, several entities or multiple currencies. New hires are trained on tribal knowledge, and leadership has no data on where documents stall.
PandaDoc is a document generation and automation platform. Teams build reusable templates with variables, conditional content and a shared content library; documents are then generated by merging live data — from a CRM, an ERP or an API call — into those templates, routed through approval workflows, sent for electronic signature, and tracked to completion. PandaDoc connects to Salesforce through a native AppExchange integration, and to HubSpot and other systems through published connectors and a document generation API.
What PandaDoc does not do is decide what your documents should contain, which fields they should pull from, or who has to approve them. That is the implementation work — and it is where most disappointing rollouts are decided. A template built on an unreliable field produces a confident, professional-looking document with the wrong number in it.
We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges. For PandaDoc specifically, the fit is strongest where documents carry commercial terms and are produced at volume: real estate transaction packets, professional services proposals and statements of work, subscription renewals, quotes generated from Salesforce opportunities, and client onboarding paperwork. If you are still weighing up the platform itself, our guide to PandaDoc and workflow automation covers the product side; this page covers what it takes to make it work in your stack.
Most PandaDoc work falls into three distinct engagements. The boundary between them is simple: if the behaviour you need can be expressed through templates, variables, conditional content, roles and approval rules, it is configuration. If it requires generating or changing documents from code — Salesforce Flow, Apex, or the PandaDoc API — it is development. We do both, and we will tell you which one your requirement actually needs before you buy either.
A first rollout, or a replacement for an e-signature tool that never became a document system. We take it from requirements through live use.
You already own PandaDoc, and it is under-used, mis-mapped or quietly generating documents nobody trusts. We audit what exists and rebuild the parts that are failing.
When the requirement is past configuration — multi-document packets, generation triggered by a business rule, or data assembled from more than one system before the template ever runs.
These are platform capabilities applied to a specific business problem — not a feature list. Each one exists on the page because it changes what a team has to do by hand.
Generating a quote, proposal or agreement directly from the Salesforce record it belongs to, with the record's own values already in it.
One governed set of templates and reusable blocks, so the current legal language is the only language anyone can reach for.
One template that adapts, instead of eleven templates that drift. Sections appear, disappear or change based on the data in the record.
Who approves what, in which order, before anything reaches the client — enforced by the system rather than remembered by a manager.
Quote documents that agree with the pricing system that produced them, including where Salesforce CPQ is the source of the configuration.
Document status as operating data: what was sent, what was opened, what is stuck in approval, and how long any of it actually takes.
A document integration is a data contract. These are the flows we design and test — what moves, in which direction, and what the business depends on it for.
Record data out: account, contact, opportunity, line items and custom fields merged into the template at generation time, so the document is built from the system of record rather than from memory.
Status back in: sent, viewed, approved, signed and declined events written to the record, with the executed file attached — so pipeline reporting reflects document reality without anyone updating a field.
Configured pricing out: CPQ quote data pushed into a PandaDoc pricing table or generated document, so the customer-facing quote matches the configuration that was approved internally.
For teams running revenue on HubSpot: deal and company data into the document, document activity back onto the deal timeline. Detailed in our PandaDoc and HubSpot implementation guide.
Where a connector isn't enough: documents created from a template by API call, and webhook events on created, sent, completed or declined driving downstream automation in your own systems.
Executed commercial terms handed downstream: signed values and effective dates passed to billing or ERP so invoicing starts from the agreement rather than a re-typed summary of it.
Where the executed file finally lives: Salesforce Files against the record, or a governed folder structure in SharePoint or Google Drive, with the naming and retention rules your compliance team asked for.
Who can generate, edit, approve and send — mapped across PandaDoc roles and Salesforce profiles and permission sets, with the per-document audit trail your reviewers will eventually ask to see.
Six phases, one continuous engagement. A focused rollout on a single document type is usually a matter of weeks; a multi-team programme with CPQ, custom objects and API work runs longer. We scope it honestly at the end of phase one, not before.
We inventory every document you send, who builds it, how long it takes and where it stalls. We read the existing templates and the last few executed agreements, because that is where undocumented practice shows up. The output is a ranked list of what to automate first — and what is not worth automating at all.
We map each document field to a source: an existing Salesforce field, a new one, a calculation, or a value a person genuinely has to supply. Gaps and data-quality problems surface here rather than in UAT. This phase also settles object relationships, security model and where the document process should live.
Workspace setup, roles and permissions, then the templates themselves: tokens, variables, conditional sections, pricing tables and the shared content library. We build layouts that hold up when a client name runs long or a line-item table runs to three pages — the failure mode nobody tests for.
Connecting PandaDoc to Salesforce or HubSpot, wiring field mapping in both directions, and building the automation around it — Flow-triggered generation, approval routing, signing order, reminders and status write-back. Custom API work lands here when configuration cannot express the requirement.
We test against real records, not tidy sample data: edge-case accounts, missing fields, unusual currencies, the largest quote anyone has ever built. Then role-based training, a sandbox-to-production deployment, and a controlled first wave of users before the whole team switches over.
After go-live we watch what actually happens: which templates get used, which get edited before sending, where approvals sit. Documents that are always hand-edited point at a mapping gap. We keep tuning templates, rules and integrations as products, pricing and legal terms change.
Two documented examples — one from a Twopir engagement, one published by PandaDoc about its own customer. Both figures stay scoped to what they measured.
Reps were spending 6–8 hours a week assembling proposals and chasing signatures. We implemented PandaDoc against their CRM, with templates mapped to deal data and approval routing replacing the email thread.
Wizehire had moved to another e-signature tool and hit exactly the failure this page describes: Salesforce fields not mapping correctly, and staff re-entering data into documents by hand. PandaDoc's own case study reports the result after returning to the platform.
PandaDoc implementations fail on data, process and adoption far more often than on the platform itself. That is the work we have been doing for more than a decade.
The hard part of document automation is the data model underneath it — objects, relationships, field quality, permissions. We bring that expertise to the document project instead of treating the CRM as someone else's problem.
Some requirements are a template change; some need Flow, Apex or the API. Knowing which is which before the estimate is the difference between a clean project and a rebuild. We put that boundary in writing at architecture stage.
Missing fields, long names, unusual currencies, a line-item table that runs to three pages. We test against your real records, including the awkward ones, because that is what produces the embarrassing document.
If people still build documents by hand after go-live, the project failed regardless of the configuration. We watch which templates get edited before sending and fix the mapping gap those edits are working around.
Documents connect to quoting, billing, ERP and reporting. We build across those systems every day — see our client success stories for how those integrations hold up in production.
Six things, in order: auditing the documents you send today and where they stall; mapping every field in those documents to a reliable source in your CRM; configuring the PandaDoc workspace, roles and permissions; building templates with tokens, conditional content and pricing tables; integrating with Salesforce or HubSpot including status write-back; and then testing, training and post-launch optimization. The template build is the visible part, but the field mapping is where the project is won or lost.
PandaDoc installs into Salesforce as a managed package from the AppExchange. An administrator maps Salesforce fields to PandaDoc template tokens, and a user generates a document from the record — Opportunity, Account, Contact, Lead or a custom object — with those values merged in automatically. Document status can then sync back to the record. Two-way sync requires a Salesforce edition with API access; we confirm edition and licensing during architecture rather than after.
If the behaviour can be expressed through templates, variables, conditional content, recipient roles and approval rules, it is configuration — no code, and your admin can maintain it. If it needs generation triggered by a business rule, data assembled from several systems before the template runs, multi-document packages, or bulk generation, it crosses into development using Salesforce Flow, Apex or the PandaDoc document generation API. We make that call at architecture stage and tell you which side your requirement sits on before you commit budget.
They solve different halves of the problem. Salesforce CPQ decides what the customer is being sold and at what price; PandaDoc produces the customer-facing document, routes it for approval and captures the signature. PandaDoc supports integration with Salesforce CPQ, including pushing quote data into a PandaDoc document. Whether you need both depends on how much your documents differ from a standard quote output — proposals with narrative sections, negotiated terms or multi-party signing usually justify it, a simple price list often does not.
A focused rollout — one document type, one team, clean CRM data, standard Salesforce integration — is typically a matter of weeks. Timelines extend when templates carry heavy conditional logic, when CPQ or custom objects are involved, when several teams each want their own documents, or when the underlying data needs cleaning first. Poor field quality is the most common cause of slippage, which is why we assess it in phase one and scope the work after that, not before.
That is a common starting point, and it rarely needs a rebuild. Low adoption usually traces to a small number of causes: templates that do not match how the team actually sells, field mapping that was never completed so people edit every document before sending, approval rules that nobody can satisfy, or a rollout with no training. We audit the existing configuration, identify which of those is happening, and rebuild only the parts that are failing.
Yes. Documents change whenever pricing, products, legal terms or the sales process change, so templates and mapping need an owner. We support clients on a retainer basis covering template and content-library updates, new document types, integration changes as the CRM evolves, and periodic reviews of where documents are stalling. This can run alongside our broader Salesforce support services.
A first conversation is a working session, not a pitch. Bring one real document and the record it should be generated from, and we will walk through the field mapping, the approval path and where the effort actually is.
Salesforce architecture, document automation & integration — one team
