The complete guide to reusable templates

Templates are the single highest-leverage feature in SignTheDoc, and the most under-used. Accounts that build templates send documents roughly four times faster than accounts that do not, and make dramatically fewer field-placement errors. This is how to build good ones.

Start with what you actually send

Do not begin by designing an ideal template library. Look at your last thirty sent documents and count. Almost every team finds that three or four document types account for the large majority of volume. Those are your first templates.

Resist the urge to template something you send twice a year. The maintenance cost is real, and a stale template is worse than no template — someone will eventually send an outdated version because it was conveniently there.

Use roles, never people

This is the mistake that undermines more template libraries than anything else. When you build a template, assign fields to roles — "Client", "Account Manager", "Approver" — not to individual email addresses.

A template with a specific person baked in has to be edited every time someone else uses it, which defeats the purpose and invites errors. A role-based template is filled in at send time by whoever is sending.

Decide what is locked

Every field in a template can be locked, prefilled, or open. Getting this right is what separates a template that enforces your process from one that merely saves typing.

• Lock anything legally reviewed — clause text, liability caps, governing law
• Prefill and lock anything derived from your systems — company entity name, registration number
• Prefill and leave open anything the sender legitimately varies — pricing, dates, scope
• Leave open anything only the signer can know — their address, their title

If your legal team has approved specific wording, lock it. The most common source of contractual surprises is a well-meaning salesperson editing a clause because it seemed reasonable in the moment.

Set the signing order deliberately

Sequential routing means each recipient signs in turn. Parallel means everyone gets it at once. Most teams default to sequential without thinking, and it often costs days.

Use sequential only where order genuinely matters — where an approver must review before it reaches the counterparty, or where one signature is conditional on another. Where two parties simply both need to sign, parallel is faster and nobody is blocked.

Build the reminder cadence in

Set reminders at the template level so every send inherits them. A reasonable default is a first reminder after three days, then every four days, expiring after thirty.

Adjust to the document. An offer letter to a candidate who is expecting it can nudge sooner. A cold contract to a large enterprise should be more patient — daily reminders to someone navigating internal procurement are actively counterproductive.

Share it properly

A template in your personal library helps one person. Move it to the team library and set permissions: who can send it, and who can edit it. Those should rarely be the same group.

Most teams want everyone able to send and a small group able to edit. That way the sales team can fire off contracts freely without anyone being able to quietly alter the indemnity clause.

Review on a schedule

1. 1Put a calendar reminder every six months per template
2. 2Check the clause text against whatever legal currently approves
3. 3Check field mappings still match your CRM or HRIS field names
4. 4Archive anything not sent in twelve months rather than leaving it available
5. 5Note the review date in the template description so the next person knows

Archiving is the step everyone skips. A library of sixty templates where eight are current is harder to use than a library of eight.

Version templates rather than editing them

When a clause changes, the instinct is to edit the existing template. That is usually wrong. Documents already in flight reference the version they were created from, but your team loses the ability to answer a question that comes up surprisingly often: what did the template say in March?

Create a new version and archive the old one. Keep the archived version accessible but unsendable. When a counterparty queries a clause in a contract signed eight months ago, you can point at exactly the wording that was in force, rather than reasoning from the current template and hoping.

Common failure modes

Patterns we see repeatedly when auditing template libraries that are not working:

• One person built every template and then left — nobody else knows how they are configured
• Templates named after internal project codes rather than what they are for
• Twelve near-identical templates because nobody knew the eleven others existed
• Every field left open because locking felt restrictive during setup
• Reminders configured on some templates and not others, with no reason for the difference
• A test template still in the team library, occasionally sent to real customers

That last one is more common than it should be, and it is why test templates belong in a personal library with an obvious name, never in the shared one.

Naming matters more than you expect

Name templates the way the person sending will think about them, not the way legal filed them. "Client contract — fixed fee" beats "MSA v3 (approved)". The sender is looking for a job to be done, not a document classification.

Put the review date in the description field. It costs nothing and it means anyone can see at a glance whether they are about to send something last checked two years ago.

A worked example

A typical services agreement template: roles for Client Signatory and Account Manager; locked clause text throughout; prefilled and locked company details; open fields for scope, fee, and start date; parallel signing; reminders at three days then every four; thirty-day expiry; sendable by the whole revenue team, editable by two people in legal.

Built once, that template turns a twenty-minute document assembly into a ninety-second send, and removes the possibility of the wrong liability cap going out.