The signer should not retype what you already know

Picture the worst version of a signature request: a blank contract lands in someone's inbox and they have to type their own name, today's date, the agreed amount, and the company address before they can even get to the signature line. Every one of those keystrokes is a chance to fat-finger a number, transpose a date, or quietly disagree with what you thought you'd agreed to. And it's slow — friction at the exact moment you want the signer to glide to "done."

Merge fields fix this. A merge field is a placeholder in your document that gets filled in automatically with a known value before the envelope reaches the signer — so the document arrives already populated with everything you know, and the signer is left with only the few things that are genuinely theirs to provide: a signature, an initial, maybe one decision. This is one of the highest-leverage habits in a reusable template, and it pairs naturally with getting your routing order right.

What a merge field actually is

It helps to separate two kinds of fields on a document:

  • Signer fields are filled by the recipient during signing — the signature, initials, a date-signed field that stamps automatically, a checkbox they tick, a text box they complete.
  • Merge fields are filled by you (or your system) before sending — the signer's name and title, the effective date, a dollar amount, a quantity, an address, a contract number. By the time the signer opens the envelope, these already read correctly.

The distinction matters because it draws the line between what the platform should hand the signer pre-answered and what only the signer can rightly supply. A good rule: if you already know it, merge it; if only the signer can say it, leave it as a signer field.

Where the values come from

Prefilled values reach a merge field in a few ways, from most manual to most automated:

  • Typed at send time. When you start an envelope from a template, the template can prompt you for its merge values — "Recipient name? Amount? Start date?" — and you fill a short form instead of editing the document. The rep fills four boxes; the contract assembles itself.
  • Carried from a CSV. When the same form goes to many people at once, bulk send from a CSV maps each column to a merge field, so every recipient gets a copy personalized with their own row — one name per envelope, no manual editing.
  • Passed by your system over the API. If signing is wired into your own product, the e-signature API can create an envelope from a template and supply the merge values programmatically — pulled straight from your CRM, billing record, or application form. The signer never sees a blank field your database already knows.

The same envelope can mix sources: a few values typed by the sender, the rest pulled from a record. What the signer sees is simply a document that already reads correctly.

Why prefilling earns its keep

Merge fields are not just a convenience; they remove two distinct kinds of risk.

They cut errors at the source. A value you merge from your own record is a value the signer can't mistype. The contract number, the legal entity name, the negotiated amount — these are exactly the fields where a typo is most expensive and a signer is least equipped to catch it. Prefilling them means the document the signer reviews is the document you intended, not an approximation they reconstructed from memory.

They cut turnaround. Every field you remove from the signer's plate is friction removed from the critical path — and friction is what kills completion. The techniques in reducing contract turnaround time all point the same direction: the fastest signature request is the one where the signer's only job is to confirm and sign. As we cover in signing on your phone, this matters double on mobile, where typing is the slowest part of the experience.

What still belongs to the signer

Prefilling has a limit, and it's a legal one as much as a practical one. The signer must still adopt the document with intent to sign — that's the heart of what makes an electronic signature binding under US ESIGN and UETA. So the signature, initials, and any genuine choices the signer is making (a checkbox accepting terms, a selection between options) must remain theirs to complete. Prefilling the boilerplate is good practice; prefilling the act of agreement would defeat the entire point.

There's a related discipline: a merge field is filled with data you assert, so prefill only what you can stand behind. If a value is wrong, the signer is being asked to sign over your mistake — which is exactly why the document should still be reviewed, and why getting it right before send matters (you can void and correct a sent envelope, but it's cleaner not to need to).

Putting it together

The pattern that scales is: build the document once as a template, mark every value you'll know as a merge field and every value only the signer can give as a signer field, then supply the merge values at send — typed, from a CSV, or over the API. The signer receives a document that already reads correctly and is asked only to do the part that's genuinely theirs. You get fewer errors, faster completion, and a sealed audit record of exactly what was presented and signed. Start a free trial and build your first prefilled template.

This article is general guidance, not legal advice; confirm what your specific documents require with your counsel.