In the web application and subscription software world, sometimes a simple "check this box to agree to terms" becomes insufficient. With the move toward more online offerings being delivered as an ongoing service, SaaS companies begin to bump up against legal principles that require more thoughtful solutions. When this is necessary, an Electronic Signature ("e-Signature") tool is a great way to help automate the transaction process while still meeting the legal requirements of agreement to terms.
Consider your typical Business to Consumer (B2C) ecommerce transaction: I'm shopping for my niece for Christmas. She's really excited about stuffed animals (she's only 11 months old) so I navigate to Acme's Stuffed Animals Emporium to find the BEST fluffy critter on the web. I find what I'm looking for-- a blue alligator with a bell in the tail-- add it to my cart, and enter my payment info. Before my order is placed I'm prompted with a message: "Please carefully review your order. All returns require a 15% restocking fee." Being the diligent shopper I am I take a moment to ponder this fuzzy blue toy with playfully menacing teeth, decide I still like it, and place my order.
My transaction was simple. It's a basic ONE TIME exchange of goods for money, with a clearly defined start and end point, and a tangible action to be performed and received by both parties.
Some online transactions aren't that simple. In some cases the nature of the transaction itself is more complex. Consider, for example, signing up for a service delivered online that has multiple potential add-on features, and adding/removing those features from your subscription has implications for the next billing date, amount, and overall duration of your subscription term. Leaving aside the fact that you should make your offerings more easily understood (see my previous post on subscription based revenue opportunities), the complex, and potentially confusing nature of this arrangement should be spelled out and clearly agreed to by the Customer.
In other cases, legal statutes require more formality in the purchase and sale agreement. Think about the purchase of a house, for example: when I was negotiating the purchase of my house this summer, there were at least 20 pages in each offer/counter-offer package, each required by law. Even if the seller and I had wanted to eliminate the paperwork from the process we couldn't because various state statutes required the presence of those signed and initialed documents.
However, rather than needing to interrupt my day to travel to the realtor's office, or print, sign, and fax paperwork, I signed electronically for every painful revision. In these more complex scenarios, when it's either prudent or required to present the buyer with more details, and confirm their assent to the terms via initials, signatures, and dates, an e-signature platform is the way to go.
At its core, an e-signature platform allows you to present information for signature electronically. Where the more basic "agree to terms" checkbox also allows you to simply display content to a customer and require they "agree" before moving on, the e-signature tool requires that customer to digitally "sign" the document. This signature can take several formats: This might be a simple signature; it could be initialing specific terms or elements of the contract; sometimes there may be an email verification step to confirm the user is who they say they are. Regardless, the core idea is that you're gaining a greater degree of certainty that (1) the user is who they say they are, and (2) they are acknowledging and agreeing to the terms by way of taking these additional proactive steps to complete the purchase.
There are a LOT of options on the market that provide e-signature functionality. I recently created an evaluation matrix for a client in which I compared what I deemed to be the top eight e-signature tools. I compared these eight tools on a combination of feature set, pricing, API/Integration access, clarity of documentation for using the tools, and online evaluations and user feedback for each tool. Through this process, I found that there are really four key factors that separate the various options.
1. Features
Obviously, right? At their core, each one of these tools is doing the same thing. They're presenting a document for signature. So I was surprised at how well, and how poorly, some of them were able to accomplish this core goal. For example: most of the platforms allowed you to present a form to users, identify where on that form they should sign, and capture their email signature for your records. However, not all of the services allow you to brand that page with your own logo and colors to fit within your website; not all of the solutions allow you to have the customer sign multiple documents; and not all of the solutions allowed you to pull customer-specific data into the document (ie: name, address, etc) to personalize the document being signed.
The valuable lesson learned here is to think carefully about what you need out of your e-signature tool. Don't assume that all tools offer the same experience, or that any tool will give you the flexibility you need. Walk carefully through the steps in the customer signature process, giving special thought to what data you need to present, if there are multiple people who need to sign, what notifications you want to have sent to your team or the customer, and what the look & feel of the experience should be. Once you have this picture in your mind, evaluate the tools by determining which one(s) can meet those requirements and provide the desired experience.
2. Pricing Model
It's not coincidence that I list Pricing Model after Features. In most cases, the basic plans of the services are all pretty comparable, and the real question becomes how far up their pricing plan structure you need to travel before you find the feature set you're looking for. Things like API Access (discussed below), branding the forms, multiple signers, etc. CAN all impact price. However, the single biggest factor for pricing is the number of signed documents you're allowed per month/year. Most of the plans have an explicit cap on the number of documents you can sign through the platform at a given subscription level. For example: You might be able to have 500 documents per month for $199, or 1200 documents per year for $2400 (two different products, two different price models and payment structures, but the same per-document price). Some use a tiered table (ie: $2.35/document up to 1000 documents, and then $1.95/document from 1001-5000 documents, etc.).
The alternative is the number of "users." Users are those that have the permission to send contracts for signature. In this world, the number of documents you sign is less important than how many employees you'll have sending documents for signature.
The key here is to attempt to accurately project how many documents you'll have signed per month, and how many users from your company you'll need to be interacting with those documents through the e-signature tool. If all documents are sent electronically through an automated system (ie: 1 user), then a per-user model might be really compelling. If you have many users who need to interact with documents for signature and a relatively low volume of documents to be signed, then the per-document model might make more sense. The key that I found here is ensuring you find the "break points" in the pricing model. At what level do the rules change such that we have to pay under a different structure? Understanding that question helps you plan out how well this tool with scale cost-wise as your business grows is really important to being able to project cash flows and the ROI on each of the e-signature options.
3. Documentation
While none of these tools is incredibly complex, they each have nuances for initial setup, configuration, and management. The (1) availability and (2) extent of documentation varies quite a bit. When reviewing the various options, one thing that really stood out was the ability to access their online documentation, and then to easily find relevant information. For some providers, the documentation information can only be accessed after you have an account. For others, you can clearly access their online help without a login to get a better feel for the degree of "self help" you'll be able to achieve. The bottom line: determine what you can from the public side of their websites. If the answers are inconclusive, push one of their sales reps for a demo account that will give you access to their online documentation. Once you have access to this content, ask yourself a question you anticipate needing to answer, such as "how do I merge Customer names into the Contract?" Try to find the answers to this and other basic questions, and see how easy (or difficult) it is to find those answers. That should give a good representation of how your experience will be with the provider's help documentation.
4. API Access
While API access is likely only needed for the more automated end of the spectrum, I include it here because almost all of the client requirements for which I reviewed these solutions ended up needing this feature set. There were several really key pieces of information that relate to this aspect of the review process:
- What process are you looking to achieve? Do you plan to have an employee monitoring an inbox for notifications that a contract has been signed? Or do you want the signature of the contract to automatically update and progress that customer's record in your CRM or Website? If you want automated actions to take place, you'll need API access.
- What information do you want in the Document? While some of the solutions allow you to merge basic information into the Document, most require API access (or a higher tier plan) to make sure each document is specific to the customer, including address, name, and other attributes specific to the transaction like monthly rates or SKUs.
- How do I use their API access? The documentation for the various systems comes in greater and lesser degrees of completeness and clarity. If your requirements necessitate programmatic access via their API, have your developer review their API documentation first to make sure it will meet all of your technical requirements.