Because of our focus on document and legal automation, you might expect us to advocate for automating everything, but as with most things, it’s about context.

Automation is great when you have very high volumes, many standard options you need to choose from, and/or details that need to be entered multiple times. In those situations, you can save 75% or more of the drafting time while ensuring that the right clauses are inserted in the correct format. It can get you 90% or more of the way there, allowing you time to add the final 10%.
You don’t need to automate all documents, though.

If you have standard contract terms that hardly change, there is less benefit in automating these. At LawHawk, we have a Professional Services Agreement (PSA) which is essentially the framework that applies to our automation projects. We’ve taken great care to draft those terms, so they are fair to both parties, easy to read and understand, and flexible enough to cope with most projects. It takes only a couple of minutes to enter the other party’s details and check that there is nothing unusual we need to consider. We have these stored as a Word template for easy access and to protect against overwriting. We get minimal - almost no - negotiation of these terms.

At the other end of the spectrum is a document that changes so much that there aren’t enough standard options to make it worth automating. This is the case with our Professional Services Order (PSO) (which is how we document each particular project we do under our PSA framework).

I’ve seen plenty of cookie-cutter Statements of Work, and I think they’re a lost opportunity. You can read them and still have no idea what is actually happening, what the required outcomes will be, and how the parties will need to work together to create value. The limitations and exclusions of liability are sometimes longer than the work descriptions.

We deliberately take a different approach and write them with our customers as the focus. When talking to a prospective customer about a new project, I try really hard to understand their problem to reflect that understanding in the PSO, using their words where I can. That context then allows me to describe as accurately as possible what we will do, what we will need the customer to do, and how we will work together to deliver the solution. I describe the solution in ways that will be clear to the customer, so they can easily tell if what we are going to do will meet their needs. I then describe where I can what the expected outcomes are likely to be, which is obviously very context-dependent.

Because the solutions are so customised, we also don’t have standard pricing structures, so that also tends to be something that we think through and tailor to the customer and the project.

I could certainly see ways to automate our PSO document production if we wanted to. It would be more efficient in getting a document out, but it would be much less efficient in terms of overall project delivery and much less effective in ensuring a successful project, which is the main thing I care about.

There are plenty of other things we can automate that will make much more sense.

As with most things, its a lot easier to tell which approach to take when you know what outcome you are trying to achieve.