How to Get Signed Contracts Back From Clients

You sent the contract a week ago. The client says they signed it. It is not in your inbox, not in the shared folder, and the last message in the thread is "will send shortly." Getting a signed contract back from a client is rarely about the signature - it is about the return trip.

Quick answer (TLDR)

• Send the contract to one private link per client - not an email attachment that gets buried
• The client taps Sign and types, draws, or uploads a signature right on the PDF, in-browser - no printing, no separate e-signature tool
• Already have a signed paper copy? Upload it or photograph it with a phone instead - no scanner
• Either way, the signed document is filed under their name, timestamped, and (for in-browser signing) carries a verification ID and QR code anyone can check

Why signed documents get stuck on the way back

Sending a contract is easy. Getting the signed copy back is where it stalls, and almost always for the same reasons:

• The contract is buried in an email thread, so the client re-signs an old version.
• The client is asked to print, sign, scan, and email it back - and half the time there's no scanner, so it arrives as a blurry phone photo, or never arrives at all.
• The signed copy comes back as one attachment on one email, separate from every other document, with no record of when it arrived.

The signature itself takes ten seconds. The friction is in the round trip: which document, which version, and how the client gets a signed copy back to you without printing anything.

Give the return trip one destination

The fix is to stop treating each signed document as a loose attachment and give it one place to land. When a client has a private portal link:

You upload the contract there and leave a short note - "please sign page 4." The client opens the link, taps Sign on the PDF, types, draws, or uploads their signature, drags it into place, and saves. A new file - {name} (signed).pdf - appears in their portal seconds later, next to the original. No printing, no scanning, no separate tool.

If the client already has a paper document signed the old-fashioned way - a wet signature from an in-person meeting, say - they don't need to do anything differently: they upload the signed PDF, or tap Take Photo to photograph the signed page with their phone.

Either way the signed copy lands in their portal, under their name, timestamped. You do not have to ask whether they sent it. It is not competing with forty other emails. When you next need it - a query, an audit, a dispute - it is filed exactly where it should be.

This is the same mechanic that makes it easy to collect any document from a client without a scanner; a signed contract is just the version where the record matters most.

What in-browser signing actually records - and what it does not

It is worth being precise about what this is and is not.

When someone signs in-browser, Droplana does not just stamp a picture onto the PDF. It records, server-side, who signed, a timestamp, and the IP address the signature came from - never anything the browser claims about itself. The signed PDF carries a caption and a scannable QR code linking to a public page at droplana.com/verify/{id}, where anyone - a signer, an auditor, a client's own lawyer months later - can confirm who signed and when, and check that their copy of the file matches what was actually signed.

What it is not: a certified or qualified electronic signature. There is no digital certificate, no identity verification beyond being logged into the portal, and no notarization. The product's own language reflects the limit - a document is "marked as signed," not certified or notarized.

For a great many contracts, a recorded, verifiable signed copy is completely sufficient. A signed engagement letter, a service agreement, a consent form, an intake declaration - these need a clean, retrievable signed copy, which is exactly what most professionals have always relied on. If a document has a hard legal requirement for a qualified electronic signature - as defined under frameworks like the EU's eIDAS regulation - pair Droplana with a dedicated e-signature product for that one document, and use Droplana for everything else.

Real example

A law office sends a client an engagement letter and a data-consent form. In the old flow, the client would print both, sign them, hit the scanner problem, and a paralegal would spend two days chasing the copy that never arrived.

With a portal, the client opens one link, taps Sign on each page, types their name, and saves. Both signed copies sit under that client's name before the end of the day, timestamped, each with its own verification ID. When the matter is reviewed months later, the signed forms - and their verification pages - are in the file, not in someone's inbox.

The same pattern holds for a mortgage broker collecting signed disclosures alongside payslips and bank statements: every signed document returns to the same private portal as the rest of the application.

Where Droplana fits

Droplana gives each client their own private portal - no account, no app. They verify by email the first time, which is also what identifies them as the signer. You upload the contract, they sign it in-browser (or upload an already-signed copy), and it's filed under their name, timestamped, with a public verification record for anything signed in-browser. Everything sits in one place, with per-file comments if a page is unreadable or the wrong version comes back.

What Droplana's signing is not: a certified, qualified electronic signature with identity verification or notarization. If your document needs that, pair a dedicated tool with it for that one document. If it needs a signed copy, done in-browser or returned from paper, filed cleanly and kept on record, the portal is the whole answer. See the full in-browser PDF signing page for details.

How to do it, step by step

1. Send the contract into the client's portal

Upload the contract to the client's private portal and add a comment naming exactly what you need signed and which page.

2. The client signs it in-browser - or returns an already-signed copy

They open their link, tap Sign on the PDF, and type, draw, or upload a signature directly on the page. If they already have a paper copy signed the old way, they upload the signed PDF or tap Take Photo instead.

3. In-browser signatures are saved with a verification record

Saving creates a new (signed).pdf file and records who signed, when, and from where, with a verification ID and QR code linking to a public check page.

4. The signed copy is filed and timestamped

It lands in their portal under their name, timestamped and visible to you immediately. Leave a comment if a page is missing or unclear - they see it next time they open the link.

Conclusion

Getting a signed contract back is not a signature problem, it is a return-trip problem. Let the client sign right in the browser, or return an already-signed copy from their phone, and the week of follow-ups disappears. Match the tool to the document: most signed paperwork just needs a clean, verifiable way home.

If you are still running this over email threads, the difference is that every signed copy is filed under the client - and independently verifiable - instead of buried in an inbox.

Start using Droplana for free - your first client portal is ready in under a minute.