"We will send it to your email"
A customer walks into a branch. They have chosen the plan, asked their questions, agreed the price. The staff member finishes the form and says: we will email you the contract, please sign it there.
The customer leaves. The email arrives while they are driving, under a delivery notification and two newsletters. That evening they think about it, then they do not. A week later somebody pulls a list of unsigned envelopes and starts calling. The staff member knew, and watched a signed deal walk out of the door.
Nothing there is a signature problem. The document was ready, the person was willing, and both were in the same room. The tool assumed the signer was somewhere else, as most do: a signer at a distance, reachable by email, opening a link when it suits them. Right for a supplier contract crossing three companies. Wrong for a counter, where there is no distance to bridge. The notification inserts a delay, a device change and a chance to forget into the one moment the customer is ready to act.
An in person signer does not need an email address
A signer routed to a counter station is created with notificationType: 'application', and no email address is recorded. None. Email is required only when a signer is notified by email, and someone signing at the station in front of them has nothing to be notified about.
Two things follow. The first is conversion: the document is signed before the customer leaves, so there is no window in which they can be lost.
The second is data minimisation. If you do not need a contact detail to complete the transaction, you should not collect one. Many counter processes ask for an email address only because the signing tool insists, and it is then stored, backed up and eventually breached for no operational reason. That matters most at a clinic front desk, where the form is a consent and the signer a patient, a case covered in patient consent forms and electronic signature under GDPR.
SignOnSite: the device is the station, not a browser tab
The counter application is SignOnSite, a touch optimised interface separate from the staff dashboard and bound to a station. The staff term is "posto". A member of staff picks which application, meaning which station, the device serves, and the tablet lists only the signers waiting there. Staff can switch station or end the session.
The binding is not cosmetic. A shared tablet is a genuine risk surface. If the device runs as an ordinary browser session, one customer finishes and the next picks it up and reaches back into what the previous person was signing. An identity number, handed over by the furniture. Tying the device to a station gives one session at a time, closed before the next person is called forward.
The station listing is deliberately narrow: it shows the stations and never the destination credentials configured behind them. The server enforces the same boundary, returning only that station's waiting signers after verifying it belongs to the calling organisation.
What keeps the queue moving is templates: a document prepared once with its fields positioned (signature, text, date, checkbox, name, datetime) and signer roles either fixed or left as placeholders, the person chosen at the moment of use. Nobody drags signature boxes onto a PDF while a customer waits. The form is built in advance, the person filled in at the counter.
Remote signing versus counter signing
| Remote, by email | At the counter | |
|---|---|---|
| Who is present | Nobody. The signer is elsewhere | Signer and staff member, same room |
| Identity evidence | Whatever can be verified at a distance | A person present, plus the verification you configure |
| What the customer needs | Email or phone, inbox access, a device | Nothing. They sign on the station tablet |
| Where drop off happens | Between the email going out and the link being opened | Nowhere. Signed before they leave |
| Delivery of the signed file | Whenever the signer completes | On signing, to that station's destination |
Where the signed document goes
In our platform an application is a named destination attached to a station: once signed, the completed file goes to an email address, a webhook, or an FTP location, configured per station. Credentials are stored encrypted.
Here the decisions get specific to you. A dealership with four sites and one central back office is a different shape from a utility with sixty stores and regional processing. Which stations exist, where each delivers, and whether the receiving system wants a file or a callback: a generic article cannot answer that for you.
What the record has to hold
Presence at a counter is not evidence by itself. It has to be in the file. Per signer, the envelope keeps firstViewedAt, lastViewedAt, linkAccessCount, signedAt, the IP address, the user agent, and a SHA-256 hash of both the original and the signed document. A signed PDF can then be looked up by its hash to find its envelope, proving the file in front of you is the one that was signed. That is the check you want when somebody produces a copy two years on.
Choosing the signature level
Two signature options matter at a counter. A simple signature is applied server side, produces PAdES-B-B, and closes the envelope with a cryptographic seal. Quick is what a queue needs. An advanced option adds identity verification first: an ID document, plus a face and liveness check. It costs a minute, and changes what the record shows about who signed.
The law does not settle the choice in the abstract. eIDAS Regulation (EU) 910/2014, Article 25(1), states that "An electronic signature shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form or that it does not meet the requirements for qualified electronic signatures." Article 25(2) adds that "A qualified electronic signature shall have the equivalent legal effect of a handwritten signature."
Article 26 sets out what an advanced electronic signature must satisfy: it is uniquely linked to the signatory; it is capable of identifying the signatory; it is created using electronic signature creation data that the signatory can, with a high level of confidence, use under his sole control; and it is linked to the data signed therewith in such a way that any subsequent change in the data is detectable.
Which level a document needs depends on the document and the applicable national law. A service activation form and a credit agreement are not the same question. Mixing levels within one envelope is supported, which matters when a counter document also needs a signature from head office, a case covered in multi party contract signing order.
Frequently asked questions
Can someone sign a document electronically without an email address? Yes. A signer routed to a counter station is created with no email address recorded, because email is only needed to notify a signer who is elsewhere. The person signs on the station tablet in front of them.
How does signing on a tablet at a branch work? The tablet runs SignOnSite, a touch optimised interface bound to a station. Staff select the station the device serves, the tablet lists the signers waiting at it, and the customer signs there. One session at a time, closed before the next customer.
Is an in person electronic signature legally valid in the EU? eIDAS Article 25(1) provides that an electronic signature cannot be denied legal effect or admissibility solely for being electronic or not qualified, and Article 25(2) gives a qualified electronic signature the equivalent legal effect of a handwritten one. Which level a document requires depends on that document and the applicable national law.
Can we verify later that a signed file was not altered? Yes. The audit trail stores a SHA-256 hash of the original and of the signed document, and a signed PDF can be looked up by its hash to find its envelope. If the file was changed, the hash does not match.
Can documents be created at the counter from our own systems?
Yes. Documents can be created and sent through our API with an x-api-key header, and webhooks tell your systems when a signer signs (signer.signed) and when an envelope completes (envelope.completed), signed with HMAC-SHA256 and retried on failure.
Working out which stations your branch network needs, and where each should deliver? Talk to us.