Most Docusign accounts are owned by somebody with another full-time job. It works, because the platform mostly runs itself — right up until a listener stops accepting events, a template breaks after a content edit, or a licence audit finds forty accounts belonging to people who left. We run it as a service instead.
Docusign support and managed services means taking ongoing ownership of a live Docusign estate: the day-to-day administration, the template library, the integrations and their monitoring, the response when something fails, and the periodic review that keeps the configuration matching the process it was built for. It is a standing responsibility rather than an arrangement to answer questions when asked.
The distinction matters because of what the reactive model misses. A queue answers questions users know to ask. It does not notice that a webhook listener stopped receiving events on Tuesday, that a template has drifted from the current legal language, or that licence consumption has quietly grown past what anyone budgeted. Those are the failures that cost real money, and none of them arrive as a ticket.
Organisations where Docusign is genuinely load-bearing but does not justify a dedicated hire. Typically the account is administered by a Salesforce administrator, an operations manager or someone in legal operations who inherited it, alongside their actual role. That arrangement works until it does not, and the point at which it stops working is usually an incident.
It also suits the period immediately after an implementation. Hypercare ends, the project team disbands, and the knowledge either transferred or it did not. Where you would rather it did not all rest on one internal person from day one, this is how that is covered.
Joiners, movers and leavers processed against the permission model rather than by copying an existing user. Licence consumption tracked against what you pay for, so renewal is a decision with numbers behind it instead of a surprise.
Changes made properly and tested before release, reviews chased on the cycle each template's risk warrants, and retirement actually carried out. The library stops growing monotonically, which is the only way it stays trustworthy.
"The contract never arrived" has perhaps eight causes, ranging from a mistyped address to a listener that stopped acknowledging. We diagnose from the audit trail and the logs rather than by asking the user to try again.
Webhook listeners are monitored for silence, not only for errors — an endpoint that has stopped receiving events looks exactly like a quiet week until someone checks. Alerting is on absence against an expected baseline.
Docusign ships changes on a regular cadence, and connected platforms have their own. We read the release notes against your configuration and integrations, flag what is relevant and test ahead of it, rather than finding out from a user.
A periodic look at what the usage data says: where envelopes stall, which templates are never used, which exceptions have become common enough to deserve a path of their own. Output is a short prioritised list, not a dashboard nobody opens.
Managed service arrangements fail on ambiguity far more often than on capability. This is the split we work to; it is agreed and written down before the service starts, and the third column is the part people usually forget to assign.
| Area | Twopir Consulting | Your team |
|---|---|---|
| User administration | Execute provisioning and removal against the agreed permission model; report on the licence position. | Tell us who joins, moves and leaves — or give us access to the system that already knows. |
| Document content | Build and test the template; confirm the fields, routing and logic behave as specified. | Own the words. Legal approves content; we do not author or approve contractual language. |
| Process decisions | Advise on options and consequences; implement what is decided. | Decide. Approval thresholds and identity requirements are business decisions, not configuration ones. |
| Incidents | Diagnose, resolve what is within the configuration and integrations, and escalate to Docusign where the platform is at fault. | Report user-visible symptoms with the envelope reference, and hold the relationship with Docusign support. |
| Platform availability | Monitor our integrations and listeners; confirm whether an incident is yours or the platform's. | Nothing — availability of the Docusign service itself is Docusign's responsibility under your agreement with them. |
| Change requests | Estimate, build, test and release within the agreed allowance; flag anything that warrants a project. | Prioritise. Where requests exceed the allowance, you choose what happens first. |
The useful test is not whether Docusign is working. It is what would happen if the person who understands it gave notice on Friday. If the honest answer involves a period of finding out, that gap is worth closing before it is tested.
We will review the account and the integrations, document what we find, and tell you what a support arrangement would need to cover. That review stands on its own even if you decide to keep it in-house.
