Tom Bangay: Lovely. Thank you very much. And we also have Claudia joining us from Personio.

Claudia Saraiva: Hi, everyone. So a little bit to myself. I said I'm Claudia. I work at Personio as a legal operations manager. For those of you who don't know Personio, Personio is an HR tech business. So it provides HR tech solutions to small and medium enterprises. And my job is ultimately to get the right tech stack for legal to drive up efficiency within the legal team, but also when working with other departments. And in that course, I also am responsible for gathering the data and reporting on legal efficiencies.

Tom Bangay: Thank you very much. Great. So we've got lots to get through. I think the next slide tells us what we're going to talk about today. Just to set a bit of context, I don't think data modeling is taught in the LPC. So definitely we have a lot of in-house lawyers in our community who are looking for a bit of a steer when it comes to getting started with data. So it's really cool to be able to share some of the wisdom of our panel today.

So we'll kick off with, I guess, starting with why. Why do this at all? There's a million and one things a legal team could be doing. And data is not necessarily seen as a core skill for many lawyers. I guess I'll start with you Stephanie, so you're in the middle. Like why did you start doing this? What was the point of gathering some data when you first started to do it?

Stephanie Stevenson: Yeah, sure. So why do we start gathering data? I mean, ultimately, we didn't have a great deal of choice. Our business is super data driven. We're a tech business based out of the States. So there's an expectation that all departments have data and we have all kinds of various reporting lines, synthesis, board reports, quarterly, monthly, et cetera. So I think we were getting away with some kind of bullet lists for a while.

Our GC at the time and our current GC now are more ambitious than that. And they, while technically legal is a back office function and is a support function, they want us to be seen up there with the revenue org and the product and marketing orgs as movers and shakers in our business. And a load of text on a page wasn't particularly encouraging anyone to read what we were doing. So it was partly a, it was really an attempt to grab some attention and talk in the same language as our business to mean that we had a kind of stake at the table.

Tom Bangay: Yeah, much easier to tell stories and startups that people actually want to hear if you have numbers to talk about. Was that similar for you, Claudia?

Claudia Saraiva: I would say we were in a slightly different position. So I came into Personio where we were start of growing up. So as a scale up and startup. So that means we didn't have a lot of these structures that Stephanie was mentioning. Also not the structures in terms of reporting. But it was increasingly difficult giving the high workload that the team was tackling to actually, you know, justify where we would need additional people joining the team or what actually the task that took the much of our time. So that was more the drivers behind our own incentive into looking into data starting to really dive into why do we have this high workload, where is it coming from and what can we do to kind of structure it and get a little bit better understanding of the prioritization.

Getting started with legal data

This all started with the legal dual system. So basically a clustering request was a first good incentive for us to start looking into data and gathering this kind of data and then starting the way for how many people do what. That more or less a little bit of a different approach and also the why came rather from the legal than from the business. But increasingly with time and with growing, it has proven useful that we already started at quite early stage to also think about how can we get data to kind of transparently outline the high workload that we have.

Tom Bangay: Yeah, very nice. I think visualizing or being able to express dispassionately the volume of work the legal teams are dealing with is obviously very valuable in terms of resource and planning and how the business interacts with you guys. Just on the kind of outcome side, we'll talk about what you guys did to kind of address those challenges. But in terms of how it helps the business, you know, if that was the kind of the why that you did it, did you kind of end up satisfying the outcome and getting to a place where it's successful for the business and you can say that it's helped?

Stephanie Stevenson: Yeah, I think we have. I mean, there's always a bit further to go. And the problem is, it's like once you start giving them a bit, they want more. So it is slightly a dangerous game in that sense. But something, and we might come into this later, but maybe worth flagging out, something that we've done is try to gather data that is to Claudia's point, it's useful to us, but it's also useful to the business.

And so for example, gathering data on like the value of the contracts that we're reviewing, obviously useful to the legal team to get a sense of priority and a sense of impact, but really useful to the business. And while we do have tools like Salesforce for our revenue team, we are able to use that data to give really good insight into the late stage pipeline of our sales teams. Because we can say, look, with legal right now, there are this many live actions or live requests and they're worth this much in total.

And that way we've been able to provide really valuable insight to the business that they could have worked hard to get from Salesforce, but we were kind of able to give to them without them particularly asking. So I think in that way, we have answered more than the original question, if you like, of us providing some data as to what we were doing.

Tom Bangay: Yeah. And I think probably trying to get the sales team to take on anything other than closing, like surfacing legal review stage data and stuff like that is probably a big ask that's not going to happen, especially around month end. Claudia, on the kind of outcome side, are you happy with where you're at now in terms of helping the business?

Claudia Saraiva: Yes, I would definitely agree with Stephanie and adding up. I brought some visuals that I think might fit well in here. Basically, what we are trying to do when we are giving data to the business, we try to formulate it in a kind of user story. So that makes us at the first stance think about what we actually want to showcase, and how does this actually fit and tie back to what the business has asked us. And one aspect was that we got several requests from different parts of the business that they felt that the requests were not dealt with in the time that they indicated to us. So what did we do?

Dashboards and legal data

We actually integrated that in our dashboard structure to understand from an early stage. So this is the last picture that you see. So we provided the structure to be able to really dive deep on that kind of data. and then to understand so the black graph is the amount of requests that we receive for each of those data brackets. At least my screen is fairly small so I might just read them out. It's zero to five days, it's then five to 14 days, 40 to 30 days.

And also finding out whenever people from departments don't indicate when we have to provide them feedback. And this has been super helpful in getting back to the departments and telling them, hey, if you really want something to get done or something done by X and Y date, why don't you put this and that amount of date? And it also helps to clarify whenever we give guidelines to department, look, everything that you put with a normal priority will be worked on in this amount of days. They can actually then come back and we can tell them you have indicated this with this normal priority, still you request us to work on it with zero to five days.

There's a mismatch and this is something that has been super helpful to come back to the business with exactly that amount of insights and showing them, look, this is what we've been agreeing on. This is how it worked out. How can we make it better in the future?

Tom Bangay: we're definitely seeing this at the moment - we have our first lawyer in and it's like, I hear him say, you know, when do you want this turned around? And people say, you know, like right now, immediately, of course. So I think being able to bucket this out in different ways is really useful. Can you just talk us through the tech stack here? So you're using JIRA for ticketing.

Claudia Saraiva: Yes, that's true. So basically what you see on the top is our user story. So as a legal team, we want to see if requests could be solved in the provided timeline. And this, again, should help us to receive reliable planning data so that we can map out all for team A, B, and C, we had this and this amount of capacity in the last weeks. And if we are then planning on scenarios, we can see if this is continuing or if we look as well at the growth of those teams, we would expect increase of XYZ amount in that team on requests and meaning we would need more capacity. So that's basically where we started from and how this is then translated.

We have the indicated deadlines that we ask from people to fill in request forms. That's an important point, I think, that we've come through structured data, having structured data is super helpful because then you can turn it immediately into reports and you can really include it in dashboards. And that's the second point again, then when we're looking into what are the deadlines that they have provided.

We grouped it into categories of what we think from the complexity of the tickets and requests that we received would make sense in order to get the first understanding so that we then can look on ad hoc requests, more long-term requests, and try to drill down on those differences. And as you can see, maybe if we take Team D, the last bucket, so it's the second one from the right, so to say, you see all the amount of tickets with no indicated deadline. And you see that, especially in Team D, this is the second most chosen category.

Avoiding ad hoc requests

So either they want ad hoc requests or they give us no deadline at all. And that's a very good indication to understand like where is this differentiation coming from and then how the team to work out on a better schedule. And this is equally for other teams. So if you see, for instance, team A, there's nearly never a deadline given, which means that they would not have any urgency in their requests, which is of course not the case. So it's also then another indication for where we need further education for the users in order to understand how they can help us to provide the better service to them.

Stephanie Stevenson: I've got a thought just hearing Claudia talk about like the dates and the deadlines, something that as a, I guess, like a counterpoint to that, something that we found in our original ticketing system, which we've subbed out this year, we gave people the opportunity to give us deadlines and we had real, it became a real problem. It might just be our business, but maybe others can empathize with this.

Because people would just click like the next day in a calendar choice, they would be like, I want it by tomorrow. And obviously most of the time that was totally, totally unrealistic. And it just really, it just created some really bad blood between our lawyers doing the work and the businesses they work for because they would just roll their eyes at those deadlines and be like, it doesn't mean anything. I'm obviously not getting it done by tomorrow. So I'm gonna ignore it entirely and just sort of assume everything's of a similar urgency.

So in a system we use now, what we do is instead of asking for a date, we ask for a free text field and say, explain when you want this done by. And obviously sometimes people write ASAP, but ASAP is a bit different from tomorrow. And I think by selecting tomorrow, they really meant ASAP and, well they can write ASAP, but if it's not done by this month, it's okay to do it next month. And we found it's kind of controversial because some people find that a bit annoying. And obviously the problem contrary to this whole kind of discussion is we don't get any good data out of it because it's not a fixed structured data point with a date, it's a free text field.

But my view is currently in reality, it's more useful because it also means we don't have to produce legal data graphs that say here are the deadlines and here are all the deadlines we missed because we're just not giving that as a choice. And kind of similarly, we used to ask, is this matter business critical? And the amount of yeses was just ridiculous and often they really weren't. So we changed that round and now we ask three more specific questions that kind of lean towards criticality, like if this vendor in most cases was no longer around with this undermine our platform infrastructure, is it personal data? Like three questions along those lines. And if they tick yes to one or more, then we in the triage point market is business critical. So we still get that data, we still know what is business critical, but we're just not giving the business the chance to choose that because it doesn't tell a very good story to the storytelling point. The story it tells needs a load of explanation and caveats, which is problematic.

Tom Bangay: Yeah, and I think there's something really nice in like your point about the free text field. Obviously it doesn't give you a structured legal data point, but it forces a bit of introspection from the people requesting. Like tell me in your own words why this is important, which is a higher bar to clear than just like pick the quickest one because it's easiest, which I think that's really interesting. So I think the last question I was just going to ask on this bit, I guess to both of you is you both have something quite sophisticated going on now, but what did you do first? Like what was the first thing you decided to track or implement just to get started with this being the endpoint?

Claudia Saraiva: So I'm happy to go first. So it's actually something completely different. We started with a standard contract deviation rate. So actually trying to map out just very briefly and giving that number out and how many times did we actually need it to deviate from the standard. That was the first one and maybe to give out a reason for that, it was to check because ultimately every deviation that we have might lead to a process change, might lead to something that needs to be done differently and it needs to be considered and needs to be handed down in the whole business. And therefore having the like a threshold and then not reaching the threshold or being able to escalate when we do reach the threshold was one of the first indicators, to be able to support the business in case there might or yeah, necessary changes might need to happen.

Tom Bangay: That's a really nice one. Stephanie, what about you?

Stephanie Stevenson: So we kind of, we did start with a bit of a big bang and bear in mind, we, the data capturing at TripleLift started before I joined, but what the embryonic original team did was use a system we already had, which was a very basic IT ticketing system. It's called, it's actually called support system. I would not recommend it to anybody. It is terrible. It makes it's really not comparable to Jira or anything like that. It's seriously basic.

But we just grabbed that and created a use case for it and built out, I think, at the beginning, three intake forms, which were customer, vendor and consultant and other, I believe, and then had those and the purpose that was sort of how the purpose was actually to Claudia's original point was to try to track just how much work was coming to legal, and to build a business case for more headcount because it was originally really a GC, a commercial lawyer and a legal ops person. And so that commercial lawyer was doing all of it and they needed a stronger business case than just "I'm super busy" to be able to sell the idea of more lawyers.

‍To watch the webinar in full, click the preview at the top of this page.