High Volume E-Signature

SwiftCloud e-Signature contains 2 modes of operation:

  • High Speed “Simple” Mode. This is best for high volume simple docs like liability waivers. It was originally designed for a waterpark that needed 1,000 e-signatures per day, though of course you can use it for any document.
  • Social Mode. This is best for higher value docs like sales contracts, job applications, worker onboarding HR docs, etc. SwiftCloud will create another user, social-style, link the accounts (as a true social network), and allow you to chat, share docs back and forth, etc.

Which is right for you depends on whether you need any kind of on-going data about this person. If it’s purely a one-off transaction in 99% of cases, then high speed simple mode is best for you.

Heads up! These settings affect payment plan quotas.

To change the setting for any doc, click the setting in the … More Options section at the bottom, like so:

High Volume e-Signature

Which one is right for you depends on your needs.


This just captures the e-signature and nothing else. You’ll get an email or API push with the captured data, but we won’t actually generate the PDF unless you need it – usually clients just need confirmation we’ve captured it, not the actual PDF, though they want to know the PDF is available anytime.

Note this also applies to Web Forms and e-Commerce Receipts that don’t have any e-signature within them. This allows you to pick and choose which submissions to “escalate”.

As of version 2.4, SwiftCloud saves all possible versions of an e-sign doc that has been published, and thus we can use the correct version for an e-signature even if the PDF was generated a year after capture. It is not possible to delete any version of an e-signable doc, as we need to be able to guarantee in court (if needed) that the signor intent matches the document generated. The e-sign session is “locked” to the document using a hashed token, as well as other proprietary behind-the-scenes “fingerprinting” comparing the doc loaded vs submitted. All of this is part of our audit trail system.

From a programming perspective, we will not create each signor as a user, we just store a bit of data of the e-signature doc and audit trail, and that’s it. If you need to escalate that signor (say, for people who buy a season pass, or get hired by your company, etc), or you need more data (a full job application with documents like a driver’s license, etc) then high speed simple mode may be best for you.

Naturally, it’s also faster for our servers to process these. It’s not a big deal, but seconds matter in some businesses, and every bit helps.

SOCIAL MODE, a.k.a. Higher Value Mode

This is best for higher value submissions as the name indicates, and it will allow you a lot more options. It is best for…

  • More complex docs – say, a job application involving multiple docs including uploads of a driver’s license and social security card or passport, or a sales proposal that combines invoices with docs with e-sign PDFs, or docs with a lot of data specific to that signor… real estate and mortgage are further examples.OR
  • Anything requiring an on-going relationship with that other person – say, a Yoga Studio in which you have memberships, HR docs in which you may want to store performance notes, pay rate notes, use our timeclock systems, etc., or sales in which after the buyer signs a contract you have fulfillment work (i.e. a mortgage, real estate transaction), recurring invoices (i.e. insurance), upsell or cross-sell is likely, etc.

For these, we actually create the other user(s) (i.e. signors, invoice payor, employer or employee, etc) as users, then link the accounts (similar to other social networks), and this allows you to store notes, chat, interact back and forth, share files (say, a driver’s license, W9 updated for each tax year, etc).

As always, if you have further questions, drop us a line and we’ll update this entry.


Was this article helpful?YesNo
Ah, sorry to hear this. We'll look into updating this item.
What could we do to improve this?