Most Docusign accounts get switched on and never designed. Templates multiply, routing lives in people's heads, and the CRM never learns what was signed. We plan, configure and deliver Docusign — eSignature, CLM, Maestro and Navigator — as one agreement process wired into Salesforce, HubSpot and the systems around them.
Docusign consulting and implementation is the work of turning an agreement process into a configured system: deciding which Docusign products the process needs, designing the account, templates and routing to match it, connecting Docusign to the systems that hold the data, and handing over something the business can run without the consultant. It is a configuration and integration engagement, not a software installation — the account can be provisioned in an afternoon, and none of the above happens by provisioning it.
Twopir Consulting does the configuration, integration and delivery work. Docusign provides the platform. That line matters on this page: nothing below is a Twopir product. Where a capability is native to Docusign we say so, and where our work is designing, extending or connecting it, we say that instead.
Three situations account for most engagements. The first is a business buying Docusign for the first time and wanting the rollout designed rather than improvised. The second is an account that has been live for years, has accumulated a few hundred templates nobody owns, and produces signed PDFs that never reach the CRM. The third is a specific blockage — an integration that needs building, a contract repository that needs structure, an approval chain that runs on email.
We work with leaders and their operations, legal and technology teams: the people who own the process, the CRM managers who own the data it touches, and the engineers who will maintain whatever gets built. With 12+ years delivering Salesforce and HubSpot work, most of what we are asked to fix in Docusign turns out to be a question about the systems on either side of it.
If one team sends a handful of standard documents a month, signature routing is linear, and nothing needs to reach another system, Docusign's own setup and support material will get you there. Engagements earn their cost when agreements cross departments, when the data on the agreement has to match the data in the CRM, when legal needs control over what language leaves the building, or when volume makes manual template management untenable.
Agreement problems rarely present as agreement problems. They present as a forecast nobody trusts, a legal team that has become a bottleneck, or a renewal that nobody saw coming.
A deal is marked Closed Won by hand, days after the signature, because nothing writes the envelope result back to the opportunity. Forecast accuracy degrades quietly, and the signed document lives in an inbox.
Every team that needed a document made one. Nobody can say which version carries the current indemnity language, so legal reviews everything, and review time becomes the deal cycle.
Who signs after the regional director depends on the value, the region and the product — rules that exist, but only as knowledge. When the person who knows them is away, agreements stop.
Payment terms, auto-renewal windows and liability caps are in the PDFs. Answering "which contracts renew in Q3 and which of those auto-renew" means someone opening files one at a time.
Docusign produces a Certificate of Completion for every envelope. If the envelope was sent from a personal account, outside the process, against an unapproved template, that certificate proves the wrong thing rigorously.
A webhook listener written for one use case, a middleware recipe built by someone who has left, a scheduled job that silently stopped. Failures surface as "the contract never arrived", days later.
Docusign is a platform, not a product. Buyers usually arrive having been sold one part of it. The first deliverable of a scoping engagement is an honest answer about which parts the process actually needs — and which it does not.
| Capability | What it does | Reach for it when |
|---|---|---|
| eSignature | Sends documents for legally recognised electronic signature, controls recipient routing and identity checks, and records every action on a Certificate of Completion. | Signature is the bottleneck. This is the baseline for every other capability below. |
| CLM | Contract lifecycle management: a structured repository, generation from templates and a clause library, configurable review and approval workflows, and obligation tracking after signature. | Legal review is the bottleneck, third-party paper is common, or contract terms need to be findable after signing. |
| Maestro | Builds multi-step agreement workflows without code, combining Docusign steps with third-party applications. | The process has conditional steps before or after signature that currently run on email and memory. |
| Navigator | A repository that applies Docusign's AI to extract structured fields from agreements, including ones signed elsewhere, so they can be searched and reported on. | You need to answer portfolio questions about terms, renewals and obligations across a back catalogue. |
| Docusign Gen | Generates documents inside Salesforce from record data and a template, ready to send for signature. | Sales documents are assembled by hand from CRM data, with the transcription errors that implies. |
| Web Forms & PowerForms | Collects structured data from a signer through a form or a self-service link, then produces the agreement from it. | The agreement needs information you do not hold yet, or signers initiate the process themselves. |
| Developer APIs | The eSignature REST API and Connect webhooks, plus APIs for CLM, Navigator and administration. | The agreement step belongs inside your own product or an internal application rather than in Docusign's interface. |
Licensing follows this table, and it is worth being blunt about it: these are separately licensed capabilities, and buying the wrong combination is a common and expensive way to start. Docusign Gen does not include signature. Negotiate does not come with Gen. CLM is a different product from eSignature with a different implementation shape and a different timeline. Part of what a scoping engagement produces is a licence position you can take to procurement with reasoning attached.
Every engagement starts with the agreement, not the software. We map the document as it exists now — who raises it, who changes what, who has to approve, where it stalls — before opening a Docusign admin screen. That map is what the configuration is built against, and it is the thing that survives when the platform changes.
The phases below are the full shape. A first eSignature rollout compresses several of them; a CLM programme with legacy contract migration expands them. The implementation services page covers what each phase asks of your team and how long it typically runs.
Workshops with the people who raise, review, approve and chase agreements. We document the current path, the exceptions that actually occur, the systems that hold the data and the constraints legal and compliance impose.
Output — current-state process map and requirements registerWhich Docusign capabilities the process needs, how the account and permissions should be structured, what integrates with what and in which direction, and what it will cost to licence. Written down and agreed before anything is built.
Output — solution design document and licensing recommendationAccount structure, permission profiles, brands, templates, routing and field logic. Integration work against Salesforce, HubSpot or your own application. Custom development only where configuration genuinely cannot reach.
Output — configured environment with build documentationScripted test cases per agreement type, including the exceptions and the failure paths. Business users sign real test envelopes end to end, and the defects they find are fixed before rollout rather than after.
Output — executed test evidence and defect logPromotion to the production account, user provisioning, role-based training for senders and approvers, and administrator handover. Staged by team or agreement type where the change is large.
Output — live process, trained users, admin runbookA defined period of close support while real volume flows through, then a review against the original process map. What you learn in the first month of live use is usually the most valuable configuration input you will ever get.
Output — stabilised process and prioritised improvement backlogA signature that does not update anything is a PDF with extra steps. The value of an agreement platform is in what happens on either side of the signature — the data that populates the document, and the records that change once it is signed.
For each connection we define three things before building: what business problem it solves, what data moves, and in which direction. An integration without those three written down becomes the integration nobody can safely change two years later.
Send from the opportunity or a custom object with recipients and field values pulled from the record; envelope and recipient status, signed documents and signer-entered data are written back as the envelope progresses, so stage changes and reporting follow the agreement rather than trailing it. Detail on the Docusign Salesforce integration page.
Create and track envelopes from a contact, company or deal record, map HubSpot properties into the document, and trigger sends from deal-based workflows. Deal workflows constrain recipient counts to the contacts associated with the record, which shapes how the deal model has to be set up first — covered on the CRM and business systems page.
A countersigned order form is the trigger for provisioning, invoicing and revenue recognition. We pass the signed agreement and its structured values into NetSuite, SAP or the finance platform of record so billing starts from the executed terms rather than from a re-keyed summary.
Signed agreements and their certificates land in SharePoint, Box or Google Drive under a naming and folder convention derived from the record, so the retention policy applies automatically instead of depending on where an individual chose to file it.
Where the agreement belongs inside your product, we build against the eSignature REST API with JWT Grant service authentication and Connect webhooks for status, including the retry and idempotency handling that keeps a replayed event from creating a duplicate. See the API integration page.
This page covers practice scope and how we engage. Each page below goes to product depth on one part of the platform — and says plainly what it does not cover.
Related work elsewhere on this site: Conga Composer implementation and Nintex for Salesforce document generation cover the two document-generation tools most often weighed against Docusign Gen, and our Salesforce support practice picks up the CRM side of anything built here.
Twopir Consulting is a Salesforce Gold Partner and a HubSpot Gold Partner, and maintains 15+ technology partnerships across the CRM and automation ecosystem. Those relationships are what let us take responsibility for the systems on both sides of an agreement, not just the signature in the middle.
Configuration debt accumulates in every Docusign account. Templates outlive their owners, permissions get granted and never reviewed, and integrations built for one use case quietly become load-bearing. The signals on the right are the ones we most often find at the start of an engagement.
If more than two of them are familiar, a structured review will tell you which are symptoms and which are causes. Bring your account and your agreement process — we will tell you what we would change and in what order.
