This post is not legal advice. Whether a particular signature is valid for a particular document in your jurisdiction is a question for your attorney, your insurer, and — if you're a franchisee — your franchisor. What follows is about the operational design of a document system, not the enforceability of electronic signatures.
Why the all-digital packet doesn't exist
Picture a new hire's first day at a multi-location retail business. The packet holds a handbook acknowledgement, a cash-handling policy, a direct-deposit form, a confidentiality agreement, a food-handler certificate, a driver's licence copy, a state tax form, and a safety acknowledgement. Eight documents, three genuinely different kinds of thing.
The acknowledgements are plain: the employee reads something and attests they read it. Those sign perfectly well on a phone, and forcing them onto paper wastes everyone's afternoon.
Some of the others have a wet-ink requirement — and here's the part software vendors gloss over: the requirement is often not legal at all. The insurer wants an original on file. The franchisor's operations manual says the form is signed in pen and scanned into their system. The bank processing payroll wants a physical direct-deposit authorisation. You can argue with those requirements, and you will lose, and losing is more expensive than accommodating them.
Then the third kind, which is not a signature at all. A food-handler certificate, a forklift card, a licence, a subcontractor's insurance certificate — the employee attests to nothing. They are handing you a document. The correct completion is a photo or a PDF plus an expiry date you will care about in eleven months.
A system that handles only one of the three has a predictable failure mode. Sign-only tools push the wet-ink and certificate documents out into email, a shared drive, and a filing cabinet — so you have two systems, the one that says "onboarding complete" and the real one in the cabinet, and only one is correct. Once a manager has two places to check, they check the easy one.
The three completion modes
The design that holds up makes the completion mode a property of each document, set once when you add it, with all three modes producing the same thing at the end: a completion record on that employee's file that satisfies the requirement.
That's how ours is built: every document carries a mode of digital, wet, or upload, and each mode writes the same kind of completion record. The benefit isn't elegance — it's that the "who hasn't finished onboarding" list is trustworthy, because no requirement lives outside it.
Making wet ink a tracked state, not a gap
The trap with wet-ink documents isn't the printing. It's the two weeks between printing and filing, when the document exists only on a manager's desk and nothing in any system knows it's outstanding. So model it with a visible middle state:
- Printed. The system renders the document with the employee's details already merged in — name, hire date, location, whatever the form needs — and records that a copy was printed for that person. A pre-filled form gets signed correctly far more often than a blank one handed over with "fill this in."
- Awaiting scan-back. The state that matters, and it needs to be a list someone looks at: every wet document printed and not yet returned, by person.
- Filed. Someone photographs the signed page, uploads it against that document, and the completion record is written with the image attached and the method marked as a wet signature.
Marking the method matters. Two years later, when an insurer or franchise auditor asks how a form was signed, "signed in pen, scanned on this date, here's the image" and "clicked a button on a phone" are different answers, and the record should tell you which.
Name the cost honestly: wet ink is slower and always will be. The goal isn't to make paper fast — it's to stop paper being invisible, and to keep it from dragging the documents that could have been digital back onto the printer with it.
Upload mode: when the artifact isn't a signature
Most systems get this one wrong by forcing it into a signature flow — the employee "signs" a document saying "I have a food handler card," which proves nothing, while the actual card lives in a text message on a manager's personal phone. Treat it as what it is: a file the person owes you. Same link on their phone, photo of the card, file lands on their record as a completed requirement. Three details decide whether it works:
- The employee uploads it. They have the card and a camera. Any design where a manager collects images and files them later has a queue in it, and queues in onboarding are where things get lost.
- Capture the expiry date at upload. A certificate with no expiry date on the record is one you'll find out about on the day it matters.
- Accept a bad photo. A crooked, dim photo of a real card beats a rejected upload and an employee who gives up. Review it later; don't block the capture.
This mode extends past employees too — subcontractor insurance certificates, vendor W-9s, vehicle registrations: same shape, same expiry problem. That's why workforce and store ops treats documents and compliance as one system rather than two.
Got a packet with all three kinds in it? If you want to see your own onboarding packet mapped across the three modes — including the wet-ink ones you can't get rid of — book a demo and bring the packet.
The snapshot matters more than the signature image
Here's the point that separates a document system from a signature widget: the valuable thing to store is not the signature. It's exactly what the person saw when they signed.
You add a handbook acknowledgement in January and thirty people sign it. In June you revise the cash-handling section. In October an incident happens and you need to know what the policy said when a particular employee acknowledged it.
If the record stores a signature plus a pointer to "the handbook acknowledgement document," you cannot answer that: the pointer resolves to the June text for all thirty people, and one of them signed something else. A signature image proves somebody signed; it doesn't prove what.
The fix is to store the rendered body — the full merged text as presented, with that employee's details filled in — alongside each signature, and to be able to open exactly that. Then the record is self-contained: this person, this text, this date, this method. It survives you editing the template, reorganising the document list, or changing platforms. Two things follow:
- Merge fields earn their keep. A document rendered with the person's name, hire date, location and role already in place is a complete artifact rather than a template with gaps — and it removes the commonest source of an unusable signed form, the blanks nobody filled in.
- Re-signing is normal. When a policy changes materially you don't edit history; the affected people sign the new version and both records exist. That's a feature, not churn.
Signing links should expire
The convenient way to send a document to someone's phone is a link that needs no password. That convenience is the risk: an unexpired link in a text thread is a standing invitation to sign as that person, for anyone holding the phone or the forwarded message.
So time-box it. Ours are single-use batches valid for seven days; if one lapses a manager reissues it in a click. Small, boring friction that removes a whole class of problem — the link still working eight months after someone left, or the one forwarded to a spouse who signed it to be helpful. Three adjacent details:
- Send the batch, not one link per document. One link that walks a person through everything they owe you gets finished. Eight links get half finished.
- Expect delivery to fail. Some consumer email providers quietly junk transactional mail, and a system that says "sent" and nothing else leaves a manager convinced the employee is ignoring them. Give the manager the link itself so they can hand it over directly.
- Make chasing cheap. One action that emails a fresh link to everyone still unsigned beats a manager working down a list — a week of nagging becomes a Monday morning task.
Expiry reminders have to fire early
Expiring documents are where this stops being administrative and starts costing money: a lapsed certification can mean a person cannot legally do their job, an insurer has a gap, or a job site turns a crew away at the gate.
The instinct is to remind on the expiry date. That's useless. Renewing a certification means booking a class, sitting an exam, or waiting on an issuing body — days or weeks of lead time. A reminder on the day announces a problem that has already happened.
Reminders need a ladder starting well before the date. Ours sends at 60, 30, and 7 days out, once each, at a sane hour of the morning. Three properties make it work:
- Once each. A reminder that repeats daily gets filtered, and then the 7-day one is invisible too.
- Recorded before sending. The system marks a reminder sent before it sends, so a retry after a hiccup can't deliver four copies. Boring, and it's why people keep reading them.
- A kill switch. One setting that stops all of it. If reminders go wrong at scale you want an off switch, not a support ticket.
Who gets the reminder is a real choice. The employee can act on it; the manager builds the schedule around it. Default to both, and give the manager a standing view of what expires in the next 60 days so it's a planning input rather than an interruption.
Not legal advice — and when you don't need software
To repeat the opening: nothing here tells you whether an electronic signature is valid for a given document. Ask your attorney, insurer, and franchisor. If any of them say pen, use pen — and pick a system that treats that answer as normal rather than as a workaround.
Then be honest about scale. Six employees and one hire a year? A folder and a calendar reminder are a complete solution. Test the threshold with your own numbers: an eight-location business with 32 employees and thirteen hires a year, a dozen documents per packet, 45 minutes of manager time per hire printing, chasing, scanning and filing — about ten hours a year. Real, but not on its own an argument for a purchase. The argument is the other column: the certificate that lapsed unnoticed, the wet-ink form the insurer wanted that was never scanned back, the acknowledgement nobody can produce in the version the employee actually signed.
So if your six-person shop is fine on paper, stay on paper. If documents, expiry dates, rosters and schedules all have to agree with each other, that's the case for one place — the argument behind our document signing and staff management features, and what a multi-location franchise workforce setup looks like in practice.