The Future of Contracting with Juro's Richard Mabey

Step into the future with this wide-ranging conversation with Juro CEO, Richard Mabey about his company's take on the future of contracting as detailed in their recent White Paper – Machine-readable contracts: A new paradigm for legal documentation.

Watch:

READ:

Hi guys and welcome to InCounsel, today we're joined by the CEO of Juro, Richard Mabey. Juro is one of the newer entrants in the contract management space that's been making a big splash. I've been tracking their progress from afar for a good couple of years now, and really been impressed with the traction they've had in the in-house community and their product as well. They're true thought leaders in the contract and legal design space. So today we wanted to really drill down on their latest idea, which has been encapsulated in a White Paper called Machine-readable contracts: A new paradigm for legal documentation.

Here to explain is Richard, thanks so much for joining us.

Richard Mabey:

Thanks for having me David, and as an early subscriber to your newsletter it's a great, great pleasure to be talking to you today.

Awesome. Well let's dive in. So that White Paper sets out this new paradigm for legal documentation and I wanted to start with why? What's the problem that you're looking to solve here?

So it was an interesting question I think when we were starting out, we started having this vision around machine readable contracts and to a certain extent it's been part of the special sauce for Juro since inception and recently, as you said, we decided to spill the special sauce by actually producing for the community this White Paper. So I think, when we look at the problem space that we generally attack, I think it's no secret that contract management has generally been an inefficient core business function for some time. And we don't spend too much time speaking about that space because that's really what everyone else talks about. And we know this to be the case. I think for us, what became really interesting was the design of legal documentation itself. And so if we look at the current paradigm of how legal contracts are agreed – you and I are ex lawyers – so we know that Microsoft Word is a fairly fundamental part of our day.

But we also know that Microsoft Word is powering 99.99% of contracts pre signature, and post signature at 99.99% are powered by PDFs. And the question we really asked ourselves was: are these file formats really the best way to agree contracts given, one, that those documentation formats were never designed for legal contracts? And two, given the format of data within those documents is unstructured or essentially in layman's terms, just piles of legal text? So that was how we saw the problem space and really the things that stem from that ‘file-spaced’ paradigm for contracts are three things. So first thing is that we believe that that format is inherently uncollaborative. So if you look at the process of redlining agreements, which is a fairly fundamental part again to a corporate lawyer or commercial lawyer's day, we believe that actually the way in which legal teams enabling their clients through those documents could be much improved.

August + Hive Privacy Policy design sprint in action.

Second thing is the contract data. So think about things like dates and names and clause types that are generally speaking siloed in an organisation if it's structured in file. So you think about the Google Drive, Box or Dropbox you use to store all these documents. That data is in there, but it's in a silo. And then the third thing is really that in order to get data out of these documents, you need to do one of two things. Either manage a very manual process of actually reading all your documents, which is a, as a former trainee lawyer I spent a lot of time doing, or actually apply one of the actually great contract review tools out there like here, Kira Systems, Luminance and co to go and use AI to go and find what those contracts say. So we said to ourselves, well what if there was a way in which you could get data from those contracts without having to go through a hugely manual process? And wouldn't that be a better way for in-house counsel to go and enable their clients.

Just on Kira and Luminance, we have a number of contract analytics or data extraction tools that are out there embarking on this exercise. How is your solution a bit different to what they're proposing to do?

Yeah, so I think the tools out there, which actually are great generally, right? So if you look at Kira Systems, you're doing a due diligence exercise, you've got 30,000 contracts, you need to find all the change of control clauses as part of the transaction. It's an absolutely great solution. It's something painful and I've experienced this myself. So I have absolutely nothing bad to say about those tools because they're solving a problem and doing it really well. I think what we found from our clients is they said, well what about future looking contracts? So if I'm myself creating a problem, which is that I'm agreeing contracts in word and PDF and then having to pay a tool down the line to tell me what they say, essentially what we're saying is well, wouldn't you like to get that insight as you go?

And so we tend to focus both pre and post signature meaning that from a collaboration perspective you can start to track things like which clauses are most heavily negotiated and you actually know what contracts say without trying and so we position much more in the contract collaboration, contract management space than those providers. I think one note to that is we do also have some data extraction capabilities as well. And the reason we do that is we are conscious that not every agreement in the world is suddenly going to be agreed through the Juro document format and through our in-browser editor. So for those other documents we handle that as well. So being able to drag a PDF agreement straight into Juro, being able to pull out quick key clauses and data points, we can handle that too. I guess the trend that we're pushing towards is saying, well if you follow the new paradigm, actually you shouldn't have to do that all the time. And of course persuading the legal industry to move away from Word is a huge challenge. And we know it's incremental and we know that we still have to solve our client's whole problems as well.

Just on your document editor and your solution in particular, which is in the White Paper, it's creating a machine readable contract. Can we just dive in a little bit deeper in terms of what is the document editor you guys have produced? How does it work and what makes it a ‘machine readable’ document versus Word or other solutions?

There are three layers to the editor. The top layer we call the visual representation layer. So if you have a look at our product in the browser, you'll see a contract appear and it has the feel of something like Dropbox Paper or Google Docs. It's an in-browser editor. And there are some crucial differences at the visual level which are, we think about things like Google Docs. The reason they didn't really work for collaborating on legal agreements is you can't really control between an internal version and an external version. So as you are gathering around and putting together your negotiating position, you can't in real time, actually control who sees what. So we have much more of a structured workflow at that level to ensure that that visual piece that you see in your browser, that the editor itself is designed to cope with those very specific legal workflows.

juro contract editor interface.png

The second layer is a data layer. So we use a JSON format document for that. So essentially a contract written in code. Now of course when you go into Juro, don't see a page of code, you see a contract. But underneath the surface we have a data layer. And that's showing everything from data points, like dates and names and counterparty information and clause types. But it also will track things say, as in when you strike out a clause as captured in that contract data model. And then the third layer is the logic layer. So in document automation, essentially we have this no code environment which says, well if you want to have a set of standard clauses which are going to be added in and subtracted from the document, you have to have a really clean way to actually assemble that from an automation perspective.

And so when you combine those three, what you actually get for the end user, and let's remember most of the time the end user of contracts are not lawyers, they're people in sales teams, and HR teams, and supplier teams, procurement teams and wherever it may be, they're just given a really easy to use interface in a really collaborative environment. For the lawyers on the other hand, there's this thing going on under the surface, which is giving them not just workflow but actually insights as well.

And if you take the Word document that you already have, is the idea to upload that Word document into your platform and it gets converted into this format that you're talking about? Or do companies need to take their Word document and recreate it in your platform? How does it practically work?

So it's the former, so we have capabilities which will automatically track formatting in Word docs. And we don't just handle your own templates, we handle one-off documents and inbound documents and things like that. But for the templating engine, essentially it's just dragging that Word agreement into Juro, all formatting is perfectly tracked and then you can go and do the automation, set up tags, conditions etc. And as part of that, we have built out functionality where at any stage in the contract life cycle, you can export it out again. And if you export it out again, then at some point you want to bring it in and maybe it's to use our native e-signature or maybe it's you want to actually spend the whole time outside of the system and then you want to just drag it back in. That's where we can do reconciliation. So we can show you that, okay, the version that you had, which was the original version in, let's say Juro, and then the version that you had three weeks later after multiple rounds of negotiations come back in. And then a little bit like Git software, you can see things like a ‘delta’ between the changes, I think in my law firm it was called Delta View.

Delta View, I remember that!

You can do that instantly and in browser. And that's really important obviously because actually the way in which people work with Word, it is clunky but it actually does the job and the reason it does the job is you control the versions and you can control what you see. So we try and marry the two and the more you can get that data into Juro, really the more value you can get out.

... we see this huge trend, especially in the US but now in the rest of the world as well, where lawyers are saying to themselves, we need to become more data driven. And the challenge our clients typically has is not that they don’t believe that, almost everyone does believe it, it’s just how do I get this data?

I was about to say you would be better off in terms of capturing those data points around negotiation – which are the most negotiated clauses, how many turns of the document did it take to negotiate the contract – for example. If people are downloading and taking it out of Word, you're losing those data points.

I agree. And I think we read a lot and we've written quite a bit about legal operations and we see this huge trend, especially in the US but now in the rest of the world as well, where lawyers are saying to themselves, we need to become more data driven. And the challenge our clients typically has is not that they don't believe that, almost everyone does believe it, it's just how do I get this data? What data and how do I get it? And so these little things, I think it's not just that it's helping you to know if someone's striking out an indemnity, to be able to go and see, well, do we have any examples of contracts without an indemnity? Of those that have an indemnity, where are they and what does that indemnity say? And then also to make optimizations, and we have clients who have agreed five, ten thousand contracts from one template.

So identifying what are the bottlenecks, what actually are people striking out from this contract? And what it means for the legal teams is you get the insight and you can provide, we have a better service to your internal client, but you can also export the data as well. So you can run reports, and you can go up to the CEO as a General Counsel and say, okay, just so you know, we processed 372 contracts last quarter. We saw a process improvement time between the approval step and the signing step, we will need some more resource next quarter because we see a trend going upwards, and by the way, we've now adjusted six of our templates because we realised there was surplus clauses in there which didn't add value and which were holding up the business. And this is how we as a legal team can be an enabler of revenue. What we provide is not that insight and not that judgement that lawyers are using, we just provide them with the data and the visualisations. And it's critical that if you have to manually capture that, generally speaking, it just doesn't happen. So what we're able to do with the editor is give you the information as you go.

... you can go up to the CEO as a General Counsel and say, okay, just so you know, we processed 372 contracts last quarter. We saw a process improvement time between the approval step and the signing step, we will need some more resource next quarter because we see a trend going upwards, and by the way, we’ve now adjusted six of our templates because we realised there was surplus clauses in there which didn’t add value and which were holding up the business.

I read one interesting part in the White Paper that talked about a new workflow, an ideal workflow. Can you just step us through what that workflow in an ideal scenario would look like through your platform?

Yeah, so I mean, workflows are always a little bit different depending on the document type. But if we take, again, one of those templated agreements, I think the first thing is that having a dashboard within Juro to control those standard forms in real time. So if you want to make an edit, that's really the only version of the template you can use. But that's the starting point. And bringing that in the machine readable editor is where we see an optimization at that point. So any level of complexity, logic, integrations into Salesforce, whatever you need, you're doing that at that step. Now from there, the second stage is typically an internal collaboration stage. So in Juro we have a structured approval workflow, so maybe the doc needs to go to the legal team and then it needs to go to the VP sales or whatever it may be.

And typically we will power notifications in email or tools like Slack. So you can just get a bot notification to say, I need to take action. And then once the document's ready, it's then going and sending it out for red-lining. And in an ideal case, the document is red-lined through the Juro system, so you're still capturing all of those data points as you go. There's no data leakage. We have native e-signatures. So in an ideal world you don't have to, but in an ideal world you would sign that through Juro. And then post completion for things like key date tracking, that would've have been set up at a template level anyway. So without doing any work, you're going to be notified in Slack or over email, three months prior to expiry of that document, because you predefined that data point as part of the semantics of the agreement.

So, really quite a smooth process is what we envisage. And that is assisted by the editor. I think real life gets in the way sometimes. So if you are creating a contract with a bank, you try the process, the person at bank says, I need to send that to my boss in Word. And then my boss's boss, and we're going to get our external law firm involved in, there's going to be this huge process. And so what we see is in Juro, engagement really as and when you want. So maybe you want to just throw a new version in there just so you can have it auto reconciled. Maybe you want to actually not do that and take it all the way through to signing, bring it into Juro for signing. It's that flexibility and the workflow we allow. But in the ideal case, we're powering the entire end-to-end process with all data being tracked at every stage.

Yeah, and I absolutely hear you in terms of real life getting in the way and 99% of lawyers being familiar with Word worldwide and that's a big behavioural change. But I do feel that at some point in the future, things will be all on platform for all these reasons around encapsulating and capturing all that data. So in terms of that journey, who do you need to convince first to use the editor or the platform? Is it the company or is it the law firm? And how do those companies or firms convince their counterparties to use this otherwise unknown platform for them?

Let's take the example of sales contracts, a commercial agreement. So there's actually a tonne of stakeholders involved, because you've got the in-house legal team, you've got their internal clients maybe with multiple people in that team, in the sales team, or commercial team. You even as you said, a contract counterparty, you might then have external counsel for the customer, the Juro customer. You might have external counsel for the people on the other side, you might have 12 signatories, you might have three approvers. So there's this whole army of people actually involved in the process. So for us, the core exercise of convincing tends not to be for the Juro customer because the benefits can be straight-forwardly proven. And we do see a high level of interest in adoption throughout those businesses. The question normally is, how do we convince the counterparty to adopt this workflow which has been owned by someone else?

So in 98% of our contracts that are processed, and we’ve processed now I think 35,000 or 40,000 contracts have gone all the way through that end-to-end workflow.

And there's a few routes for that. So one is that they're already using Juro themselves, in which case they're delighted because it actually goes in their workflow. In a world in five years time, we have this ambition that actually this new format of agreeing terms is going to be widespread. Now of course, we're in the scale up phase so we're not there yet. And so then it becomes an exercise in agility. So right now I'll give you a stat, but it's 2.1% of contracts are exported from our system by the counterparty. So in 98% of our contracts that are processed, and we've processed now I think 35,000 or 40,000 contracts have gone all the way through that end-to-end workflow. And so we're pretty surprised by that, because-

Yeah? I'm surprised!

You wouldn't expect it. And to a certain extent, it depends slightly on the kinds of customers we serve. So we're working often with scaled up tech businesses, the early adopters of software, they often have high contract volumes. But even in the cases we start to see in a really heavily redlined documents going through the system as well. So we see that as a positive step. Now the kinds of documents that we don't handle are, if for example you're negotiating an SPA, it's not really what we do at this point in our roadmap, and we know that there'd be a tonne of counterparties and probably at some point someone would say, let's just get this out in Word and let's do the same old thing.

SPA, a Share Purchase Agreement?

Yeah. A purchase agreement or a document that's really high value, really heavily negotiated. That's not really where we play. So for our-

And you've got a counterparty that is – adversarial is not probably the right word – but there's a lot on the line for each party.

Agreed. And I think a lot of what's helped us get to that point of high adoption is actually user experience design. So I'll give you a couple of specific examples, but one is you can share documents in Juro as links. So a little bit like a Google Docs or a Dropbox Paper, you can share a link. But of course sharing of links itself is, in the context of contracts, there's a certain level of risk involved. So we have special controls for Juro documents that you can't get elsewhere. For example, you can time limit a link so you can make it available for one day and then it's squashed. For example, we don't make those publicly available ever so there's certain levels of encryption which will protect them. But from an experiential perspective, if you're already emailing a client and saying, Hey, let's just agree an NDA and just say here's the link. And then they click on the link and all they're releasing is a contract with collaboration capabilities, which really intuitive like chat and redline functionality.

If you do that really, really well and you've made a great experience for them, then you're much more likely to get adoption. Whereas if you do it badly, and we've seen some people in the past do this where they'll require a login for the other party, or it will be super hard actually to work the button that's in the browser to get to where you want. And after five seconds you just say, let's not waste time. And so that design point is absolutely fundamental. And we have our lead product designer who came to us from Revolut, spends a tonne of time on optimising that experience. Like how can we make it so easy and so undeniable that actually you'd want to take it through in that format.

And when you say that other providers need a login, I'm assuming you don't need a login, so your counterparties or new users don't need a Juro account?

jurocover.png

Correct. And if you think about from the perspective of an in-house legal team, a lot of what we tend to hear from them is, we want to make this easy for other people. We are on a mission to enable the business and our external stakeholders, so why introduce that friction. And if you can be clever in the encryption and the way in which these kinds of links can be shared, then actually you don't need that. And that takes a huge hurdle for adoption away.

Yeah, I mean you see it already existing in e-signatures which are a good example of that. You receive a link from one of the major providers, you don't need a HelloSign account or a DocuSign account. They do encourage you however, once you make a signature to sign up for an account, I accidentally signed up for one the other day just by clicking buttons. But no, I mean I totally get it and I think that's a big friction point removed if someone doesn't need to actually sign up and create an account. Just in terms of that workflow, the document has been created on platform. With the data, I assume that the documents then continually live on Juro. Does that mean only one party can really leverage that data or can both parties leverage the data that's in there and get those triggers for renewals or expiries and that type of thing?

Yeah, it's a super interesting question, it's quite topical for us. So right now it's just one party, so it's just really our customers that get access to that unified workspace. And there's all kinds of granular permission settings. So you might want a sales person to see the three contracts they've got out for signing, and you might want the GC to see 12,000 contracts in various structures. So things like reminders, analytics, a structured search. I'm a big believer in search, very unsexy feature, but very, very powerful.

I think it's really sexy – good search. I mean we're the beneficiaries of things like Google search, then bringing that into the contract space, I think that's really sexy.

It's huge. And if you think about things like say, our search supports typos. So if you make a typo in search, will still give you some predictive results. So all those things can be super helpful. But the reason it's topical is I think the other side, we started to see people a little bit in the e-signatures where you mentioned say, not so much we don't force people to sign up, but come in and say, well actually this seemed to work pretty well – how can we use that? And so we have thought a little bit about this idea of well, could we then give an option of just saying to someone: here's your free workspace with the contract you just agreed within it and all the metadata is searchable. And this is where I think it becomes quite powerful because you're delivering value through a tool which isn't just, “Hey, someone's asked me to do this thing and as a favour I've done it through Juro and I had to sign it and we sent out an email with a fully signed PDF.”

I've got this PDF, but then what do I do with the PDF? Where does that go? Does that just go to my Dropbox and then do I have to put a line item in my spreadsheet to say I've got this new contract, or actually could this be seamless? And I think we're at the first stages now of seeing contracts where both parties have Juro. Because when you're super small like that, that's obviously never going to happen. We've just started to see that. And so it's a question we're working through.

Yeah, I mean I can absolutely see if a vendor for example, is using Juro and they sell a product to a customer all through the Juro platform, if the customer then says, you know what, I will take an account, thanks very much. Because I also as a customer want to know the triggers and the data points, especially if it's a big customer. So if both parties do have a Juro account right now, do they have equal access to that contract, so to speak? Or is it still just really the ... Because what I'm trying to say is both counterparties are Juro customers in that sense. I mean, they both come into and get that same data access.

So the short answer was no, at least no for now. But it's quite an interesting point because I think, and certainly to the point of the White Paper, a lot of our thinking has moved towards how is this going to become standardised. So if we're providing for our clients this new data format, which is giving them value, and if people then in the community are saying, well actually can we do that? Of course we can build them Juro accounts and that's fine, but really what we're interested in this systemic shift in the industry, which is, are we going to be in 10 years time, all working in Microsoft Word, or will there be another default? And I think about it a little bit like Word is an incredibly powerful tool. So it's got 30, I think we worked out the age from when Word was started, Word as a tool is older than the majority of our team. And so just the depth of features that are in there are absolutely vast. But it's a little bit like, someone used this analogy the other day at Juro, which was, if you give a spoon to a surgeon and say remove my appendix, you could still achieve the end result. I mean, there's a lot of pain involved -

and a lot of blood, infection…

But it still kind of works. And then ultimately we have a scalpel that’s closer to Microsoft Word, but now we have robotic surgery and so the question is, how can we take to lawyers a tool which really equips them to leverage their skills. And I think a lot of the frustration I felt as a lawyer was just the sheer quantity of time spent on process is so severe that the work we really want to be doing, which is the higher value advisory work we've trained for so long to do, is somehow swamped in this massive process. And our bet in the market is building a workflow tool for Microsoft Word, which is what actually others have done and quite well in the contract management space, we don't see the future there. And the reason we don't see the future is Microsoft will never build for lawyers. It's too successful, it's too niche to go in that direction.

And nor will Google. I'm a huge fan of the G Suite products and everything, but at the end of the day they're not going to build just for the legal industry or any sector. Their success is in having broad adoption across every industry. And I believe in this future as well, the future that you're heading for and I'm not sure when that will happen. But I think this type of platform play will be eventually the right side of history for sure. Well, probably the final question, because we are talking about data points and triggers that sit within contracts that now sits on servers, thinking further down the track can that then maybe be connected into real world events? Leveraging banking APIs or other public APIs to then have these contracts enter into that so-called ‘smart contract’ space?

Yeah, it's a super interesting and topical question for us. I mean the main reason we built the editor was that we realised that AI is not at 100% predictive accuracy, but if you structure information it's pretty close to 100%. So if you can just make things structured you get the data. I think as the thinking's developed, I mean, I look quite carefully at smart contracts, whether they're blockchain based or not and this is something that's been talked about for 25 years, the world of self-executing agreements. I think that when we were starting Juro, the bet we made would be that if we had built a business in that space we'd be slightly too early for the market. And I'm convinced of that world as well. And I do think we will go there, but I don't think we'll go there in the short term mainly because the challenges the legal teams have are a couple of iterations back from that. Forget, can my contract self-execute? Like, where are my contracts? I can't even find them.

We already have APIs pushing data into contracts, pulling them out. It’s fairly simple. In fact, we could do it today with our API where a data point and Juro could then go and trigger something externally. It’s just not something that we think today we’re going to build because it’s slightly abstracted from our core use cases and I’m interested to see how ready the market is for that.

And so there's a process, an incremental process to go through. I personally really like Clause as a product Peter Hunn’s product, which is working in this world, this post-signature events driven world. And I think the way in which ultimately we will work when we get there is that if you start with a structured document in the first place, it's fairly simple to integrate APIs. We already have APIs pushing data into contracts, pulling them out. It's fairly simple. In fact, we could do it today with our API where a data point and Juro could then go and trigger something externally. It's just not something that we think today we're going to build because it's slightly abstracted from our core use cases and I'm interested to see how ready the market is for that.

Well, I imagine you probably wouldn't need to go down the blockchain path to make this happen. So smart contracts have always been associated with a blockchain scenario, but I'm not quite at the point where I'm convinced that you'd necessarily need it in all cases. I guess there's a trust issue that a blockchain could solve for. But at the same time, I think we place our trust in large corporates all the time and in our counterparties. So I just see, yeah, a definite opening there for this type of tech connecting with real world events without blockchain.

I agree with you, I've never fully understood why blockchain is required. I can see why it's useful. I mean I found out the other day that this is a UK thing, but the UK government is in the process of building regulation I think, or legislation to basically make clear two things about smart contracts. One is that crypto assets can be classed as security for the purposes of financing. And the other is that a smart contract is a contract for the purposes of English law. And so I think what the government, and I think the government's been very forward looking over here about this, is saying is well it's all very well to have a smart contract. But what about concepts like misrepresentation? What about concepts of warranty? There are things that don't self-execute but are still important. And so ultimately what you get at the end, well, you still get a contract, it'll just have some self-executing modules to it. And that's where I think starting from where we are today, where in this base of documentation looks as it always has, but has gone a little bit further and has this data model into you can plug in really whatever you need. And then you have this system of agreement where you've just got a commercial agreement codified and executed in whatever way you want.

Well look, it's a pretty exciting future. I think it'll be interesting to see whether we're overestimating the next few years of progress and underestimating the next 10 years of progress, and I really enjoyed speaking with you and enjoyed reading that White Paper – I don't really see too much like it in the marketplace. And yeah, just wanted to congratulate you on it and the thinking and look forward to seeing more of these features come through in the future. So thanks for speaking with us Richard.

Thanks for having me, David.



//

 

YOU MIGHT ALSO LIKE:

Want Users to Read Your Privacy Policy? Make it Delightful.

 

//

 

STAY UP TO DATE:

InCounsel Weekly: Bite-sized insights for in-house counsel and creative legal minds.