Start designing your contracts for high velocity.

Brian Powers
Feb 14 · 3 min read

Facebook has just over 2 billion active daily users. No news there, but think for a moment about the challenges associated with that scale, particularly as it relates to contracts. Every time someone signs up for Facebook, they are required to accept a Terms of Service (a contract), a Data Policy (a quasi-contract), and Cookie Policy (a quasi-contract). Imagine this ridiculous scenario:

This is not high-velocity. Not even close.

Do you think Facebook becomes Facebook by employing this clunky method for getting all of its contracts accepted? Not likely. Too much friction, horrible experience, and just a bad idea. So, what did they do? They made acceptance a seamless part of the experience:

Checking a box = pure high velocity contract acceptance.

That is what high velocity contract acceptance is all about: maintaining transaction speed and providing a good customer experience by tailoring contract acceptance to the nuances of a business and its customers. Our preferences as consumers and businesses have changed so much over the last 15 years that speed and experience are no longer optional when it comes to most transactions — specifically buying experiences. As consumers, we want what we want WHEN we want it; now, more and more, business models are premised on the flip side of that: providing what consumers want WHEN they want it. Rigid signature methods of the past simply don’t always cut it anymore.

Like in the Facebook example, how would an eSignature (or, *gulp* a paper and ink contract) possibly work for anything like this:

  • Terms acceptance in ecommerce checkout flows
  • Terms acceptance for SaaS registration flows
  • Contract acceptance initiated by high volume contact centers?

Here’s a hint: it doesn’t. Neither does paper. Beyond examples where eSignatures flat out fail, there are even more examples of it working, but in less than optimal way:

  • High volume sales order forms
  • Standardized NDAs in large organizations
  • Consent to reproduce large volumes of user generated content.

The solution is a fundamentally simple one if you approach contract acceptance as something to DESIGN rather than just something that requires the replication of a handwritten signature. Of course, that can be tricky if you don’t understand the nuances of what is required to create a binding electronic contract. But once you have that understanding, you can do some pretty amazing things from a design perspective. The basic approach?

  1. Ideal state analysis: Imagine a specific business process WITHOUT contract acceptance. That’s right, just get rid of it! How would the process change without contract acceptance? How would it speed up and improve? How much are you deviating from the optimal process now? Does your current contract acceptance take your process on an unnecessary tangent?
  2. If velocity is important, focus on engagement and the acceptance experience in a way that is specifically tailored to the people accepting the contract.
  3. Once you’ve analyzed your ideal state and have thought long and hard about velocity, engagement, and the experience, figure out how to inject contract acceptance back into the business process in a way that a) preserves that ideal state and b) creates the high velocity experience.

You’d be amazed at what is possible with this approach. The clickthrough example above is just the start. Any point of electronic engagement with a customer becomes an opportunity for seamless, high-velocity acceptance.

Brian Powers

Written by

http://pactsafe.com, father of 2, love all things cuse and indy