Evan (00:00):

Welcome to go with the workflow where we interview world-class leaders and legal and experts in workflow automation to learn from their hard earned experiences in making work more efficient and more meaningful. Today my guest is Brian, hub. Brian is what the young kids would call one of the OGs of legal ops, but he's also just a great human being overall. He was one of the founding leadership members of Clock and has 25 years experience in the in-house space, establishing and leading legal operations functions for electronic arts, Dolby Laboratories and Facebook Now meta. Today Brian continues to share his experience and advise legal teams in his role as senior advisor at Uplevel Ops, a legal ops consulting firm that is filled with wonderful people just like him. In this episode, we take a systematic approach to evaluating and selecting a workflow tool, starting from determining whether you even need workflow automation versus other technology. So the readiness work that comes before vendor evaluation, followed by the common requirements to look out for in a workflow tool, and finally the process you run to get to your selected vendor. Across his career, Brian has been involved in countless evaluations of workflow automation platforms, so I cannot think of a better person than Brian to be on this episode. So with that, I hope you enjoyed this episode.

‍

(01:45):

Hello everyone. Welcome to another episode of Go With the Workflow. This is episode three on evaluating and selecting a workflow automation provider. Thank you for joining us. I can see some familiar faces in the audience today and some new ones. So if you haven't met me already, my name is Evan Wong. I am the co-founder and CEO of checkbox, the host of this web series, and today I have a very special guest with me, a friend, if I can call you that, Brian. Oh, absolutely. Well, we have here Brian Hopp to lead us on this topic. I can't think of anyone better than Brian to do this. Brian has established and led legal operations functions for electronic arts, Dolby, Facebook now Meta, and he was also the founding leadership team member of Clock, the corporate legal operations consortium, and served many years on their board as well.

‍

(02:43):

Today Brian works with many legal teams as a senior consultant at Uplevel Ops, and if you haven't heard of them already, they're a great, fantastic legal operations consulting firm, fantastic people, great culture, and they basically help legal departments with a range of services including Legal Lobster as a service, strategic planning, technology process improvement. Much, much more. And Brian, because in your career you've been involved in so many countless evaluations, workflow automation tools, I cannot think of a better person than Brian today to be on this episode and lend his advice. So Brian, thank you for being here and welcome to the show.

‍

Brian (03:21):

Thanks so much for having me. It's great to be here.

‍

Evan (03:24):

Fantastic. Alright, well Brian, let's kick into it. I mean you've now had I think 25 years working in the in-house legal space alone. You've spent even more than that in the legal industry across your career, but one thing as impressive as your knowledge in legal operations is your photography work. I've seen your photos before. I know you head out to the Arctic every now and then and you take photos of polar bears and wildlife. How did you get into that and how does this creative adventurous side of you help you be better at your legal operations role, if at all?

‍

Brian (03:59):

Well, thanks Evan. It's really kind of you too to compliment me on the photography. Maybe not so kind to keep calling out the number of years I've been in the legal industry. But yeah, I got started early. I always had a camera in my hand when I was little and then I got caught up in that Silicon Valley life where you get to your desk all hours of the morning early and stay there until late at night. And I kind of had a hiatus where I wasn't doing a lot of my creative work, but then I took advantage of some sabbatical time after I'd been at EA for about 13 years and started doing photography workshops, especially landscape. And more recently I've started doing more wildlife photography.

‍

Evan (04:56):

Very cool, very cool. Does it feed into, besides taking a break from all of the crazy world that is legal ops, does it feed into the creative side of legal operations for you?

‍

Brian (05:08):

Yeah, I think it does A couple of things. One, I always think it's great for legal ops people to have another passion, especially a creative passion and do creative things because especially if it gets them outdoors in the fresh air and gives them a chance to recover from the stress of corporate life and the number of demands everybody always has on their plate. But for me it does a lot I think to help me in my day-to-day legal ops work as well because when I get out in the field, if I'm out on the frozen arctic ocean photographing polar bears, if I'm Barcelona shooting sort of a fire parade, which is what I was just doing, you have to think ahead about the kinds of situations you're going to find yourself in and really know sort of something about the behaviour of your subjects. And I think a lot about how to use the tools at your disposal when you're out there.

‍

(06:27):

You have to, it helps I think if you've sort of pre-visualize what you may encounter, the kind of situations you may be in. So if you suddenly come around a corner and you find this guy 20 feet away from you, a nine foot polar bear, granted it's not a litigation attorney with an urgent data request, but it still gets the blood pumping in the same kind of way. If you've already thought about how you're going to react, if you've already thought about how you're going to take advantage of the opportunities in the moment, I think you're much better off and you come away with a lot better results. I think the same thing is true for a lot of what we do in legal ops. So I'm a big proponent as all of my brilliant colleagues are at uplevel of readiness work ahead of time to make sure that you're setting up the right way for every party.

‍

Evan (07:35):

Yeah, absolutely. I certainly wouldn't want to have to do change management for a polar bear, but let's talk workflow automation. So I know you're a huge fan of workflow. You've said before that it's a foundational technology for legal teams. Why do you like no-code workflow so much?

‍

Brian (07:53):

I think there are a lot of reasons and a lot of it has to do with how much administrative burden you can lift from your teams. For all the companies I've worked for, we were coming from a place with no automation and getting to a place where you had the satisfaction of actually building it better, doing it better, alleviating a lot of that drudge work that really nobody wants to do, but somebody usually gets stuck with. It lets you move all of your team members up to focus on work that's more meaningful to them and really higher value for the company as well.

‍

Evan (08:41):

Amazing. And I know that you've said before as well with workflow, it's addictive, it's fun. People tend to get lost in starting with one and rolling into a bunch. And I feel like speaking of starting with one, I know that you and I both have a love hate relationship with the self-service NDA. It's a great place to start workflow, but often people can sometimes not see past that workflow becomes NDA automation and NDA automation is workflow and I think one concept you mentioned to me last time we were catching up is this concept of creative visualization. I think that was a phrase that you used with me, like the importance of creative visualization to help teams see the overwhelming possibilities of workflow automation. So maybe we can do some creative visualization now. What are some examples of workflow that you've seen across your career that can help people really break out of just that NDA or example?

‍

Brian (09:37):

Yeah. Well obviously for those just beginning, the most common ones are obviously getting your self service NDAs up and running and thinking about handling legal request intake, but where a lot of people look for a tool that can help them get those initial use cases done. A lot of people, as said, get stuck in thinking about those as point solutions where workflow automation tools are just capable of doing so much more and not only for legal, there's really nothing legal about 'em. They're really enterprise level tools. And I think it's really important to think about sort of a much broader set of use cases as you're approaching these tool sets to begin with thinking about not only the legal use cases and whether that's doing marketing material review, getting trademark clearance requests, getting other self-service contracts up and running MSAs and sows in order to enable the business more and keep things more standard.

‍

(10:56):

There are things along the compliance lines like conflicts of interest, workflows, stock sale, pre-clearances, those are all things that are pretty common to find people rolling out who have gotten past that first stage. So I think it's good as you are thinking about automating to really talk to practice group leads and the people in the trenches in different practice areas around legal to really understand what are the potential use cases that may really serve them well. But while you're doing that, it's great and it's a good practice anyway for ops, people go out and make friends with ops people in other parts of the business. HR usually has ops, the IT team definitely does. Finance teams will understand what those people are up to, what some of their needs are and can really feed into the success of a workflow automation project because you can make allies around the organization.

‍

(12:10):

Number one, for an ops person, that means you have other people to split the costs with, which is fantastic. But number two, it means that you're not implementing a point solution that especially these days is going to come under a lot of scrutiny. Is it worthwhile having this whole tool and this whole platform to just do this one thing and the answer, no matter how good that one thing is, the answer is always no. So thinking about rolling or at least planning to roll out multiple workflows from different parts of the business is a really good way to leverage the tool capabilities number one, but really guarantee that you're going to have that tool going forward in your toolbox.

‍

Evan (13:05):

That is such great advice because workflow by nature is about connecting people to process and people to people. And so inevitably it's going to have to branch out beyond just legal even if that is the entry point. And so taking that enterprise mindset when thinking about workflow automation is so important and the allies and the influence and the sharing of the budget, that all makes complete sense. And it's interesting because when you talk about the examples of workflow that you've seen in your career, Brian, you've sort of gone broad there, but it's interesting because over time you can look at other legal use cases, compliance use cases, and then use cases across enterprise. But people also don't realize that you can go quite deep also in those areas. Like for example, self-service NDA might be perceived as a very basic document automation or assembly type use case.

‍

(13:57):

Where someone might come in, they're looking to generate let's say an MSA with a supplier and the tool can actually tell you, no, we've already got an MSA in place. In fact, you don't have to create another one and go through another cycle of review. And when there's an MSA in place, then maybe it can link that workflow to, well, why don't you generate an SOW under that MSA? And if there isn't an MSA and it's expired, then you can go ahead and generate a new one. And so there's all these kinds of interesting business process flows that can really unravel itself just from even this simple concept of contract automation that people often think is a powerful mail merge. It can be so much more than that. The workflow that wraps around it makes it very interesting.

‍

Brian (14:49):

Absolutely. And all the capabilities we used to in the earliest days, I think around 2010 when I rolled out my first self-service NDA, it was pretty basic and that was a huge help and a big leap forward, but leveraging the capabilities that have really been built into these platforms since then, things like lookup as you said, so you can connect it to either another data source or have a data table in the solution so you can find NDAs that are already in place or master agreements that are already in place. That's a huge time savings and that's a reduction of the number of emails that the business team is going to be otherwise sending to the legal people to check, do we need a new one? Is this going to expire? All those kinds of basic questions. But beyond that, you can even really get into enabling the business to do more and really take on that second round of easy changes.

‍

(16:05):

So just sticking with the NDA example, corrections to the counterparty name changes of the governing law changes from a perpetual term to a five-year term. These are all things that the legal team can decide ahead of time. We're okay with the business making these changes within these guardrails that we can control, and that's another round of stuff that's not coming through to legal. So it's just a world of possibilities. And as you said, as you get to know the capabilities of some of these tool sets, you can really start doing that creative visualization around how you're going to leverage those capabilities and really have much more flexibility in building out processes that meet your needs and that are not driven by the tool set.

‍

Evan (17:03):

Absolutely. Very cool. Okay, well let's dive into today's sort of main topic, which is really on evaluating and selecting a workflow automation provider. I want to take us on a bit of a journey, almost like a story. Let's follow the journey of legal team X, pretend we're part of a legal team. So they sort of are aware that they need to improve their legal department and how they run it, but they're not really sure what sort of technology they need. And I think even before we get to the question of how to evaluate and select a workflow automation provider, we have to take a step back to a question that I think a lot of people are actually dying to get your thoughts on before we get to that, which is there are so many categories of technology nowadays and they seem to overlap. So how do you even know you need workflow as opposed to some other technology, right? If you have a Venn diagram, there's often this intersection between workflow, CLM, matter management, project management, and then you branch out into enterprise tools like CRMs, procurement ticketing from it. And I know that you've told me before clients have come to you and said, Brian, we're coming to you because we need CLM. And you realize, no, you don't need CLM. What you need is workflow. So how do you help your clients navigate through this sort of maze of different technology types and decision-making process?

‍

Brian (18:27):

Yeah, I think the best approach we can take in those cases is really to dig in with the client a bit more here about what their actual pain points are here about where they think the needs are arising and where they think or where they've heard from the business that they need certain things. Oftentimes legal departments are led to CLM by procurement teams and it's good to have a CLM. It's great to have a strong repository that you can depend on and all the functionality that comes with that. But oftentimes when we start drilling down with clients and asking the specific questions around the kinds of functionality they need or the kinds of problems they're trying to solve, they're really not trying to solve advanced redlining or collaborative drafting or some of the other more CLM focused capabilities. They're really more interested in alleviating administrative burden and making sure that transactions are getting the right approvals, that transactions are being completed, and there's visibility into that process.

‍

(20:00):

And that a lot of times we find their needs are not just in self-service contracting. So a lot of CLMs do have some workflow capabilities and they're focused on contracting. So if you try to do general intake, sort of request intake, we've tried to do a conflicts of interest workflow or a stock pre-clearance workflow, suddenly you're trying to squeeze these things into a CLM framework that's not really suited for the kinds of workflows you're trying to build. So I've always been a really strong believer that legal teams need both, but that workflow automation is the more foundational tool of the two because of its reach, because of the fact that everybody can leverage a workflow automation tool, not only again in legal, but outside of legal. Everybody at the company might order an NDA. Everybody at the company may need to check on conflicts of interest if they've gotten a gift from a vendor.

‍

(21:16):

Not everybody needs to learn or touch a CLM system. Those are more legal team focused and they don't really deliver the benefits or lift or sort of brand development, if you will, for the legal department with all the other users. And it's much better to deliver some services that are easy to use, that are relevant for broader populations in workflow automation tools and then integrate them where you have self-service contracting with A CLM, escalate advanced redlining over to your CLM and let your legal team deal with it there, integrate so that self-service agreements are all being filed in the CLM in your official repository of record and being profiled without anybody touching them once they've been DocuSigned Adobe signed. There are just so many advantages of having a really good workflow automation foundation that I think a lot of other possibilities arise after you have that.

‍

Evan (22:32):

That's really insightful because I feel like with that sort of overlapping functionality that happens, and I think where it overlaps between workflow and we're using the example of CLM here specifically is sort of that self-service contracting because as you say, some CLM do have that workflow component, but what you're saying is sort of best tech design is often where you draw the line between them is the handover point is where you need that more advanced redlining. Maybe you're looking at negotiation and AI clause library type concepts that might need to come in, but for the most part, if it's a vanilla low complexity self-service journey, that better sits on the workflow side rather than the CLM side.

‍

Brian (23:16):

Absolutely. And the change management tends to be a lot higher when you try to get business users to go into tools that they don't use very often or that they don't necessarily need to use at all. So keeping them in more intuitive interfaces that workflow automation platforms can provide is a huge advantage. Not to mention usually a reduction in licensing costs for your CLMs and other specialized systems where you want your specialized people to be in, but not necessarily the general population.

‍

Evan (24:01):

Yeah, absolutely. Okay, so let's continue on with that journey. We now have a legal team that has looked at its own needs, and realized that it doesn't need the other sort of technologies for the moment. It's very much in the position now of looking at onboarding a workflow automation tool or perhaps they already have a CLM and now they're looking to bring on workflow automation. So a lot of people would be tempted at this point to jump straight into vendor selection, but you and I both know, yeah, you and I both know that's not ideal. So what phases of project readiness, you talked about this phrase earlier on, right? So readiness, what phases of readiness do you recommend a team work through before getting to system selection and why is this readiness work important? Why not just jump straight in?

‍

Brian (24:47):

Well, I think the old adage is building the plane while you're flying in it, and for those who go straight to system selection without understanding what their requirements or use cases may be for a broad spectrum of workflows that they may want to set up, they're taking a gamble first of all that the platform that they jump into, we'll be able to support the kind of diversity and flexibility that they may need for lots of different kinds of workflows. Second of all, I think for clients that have gone that direction that try to just jump in, they found a lot of them have found in my experience that it's a lot more expensive for them because they can't build quickly if they're doing the D diligence at the same time and really trying to understand what they want to build. So they end up with potentially vendor professional services resources or integration partner resources standing by while they debate the format that they want to have this information or that information.

‍

(26:12):

And we always find it's much better to pull back a little. It's great to understand what tools are out there and some of their capabilities. So I'd really encourage everybody to take advantage of opportunities like clock and link and legal operators where vendors come in to demo their software and they can answer basic questions and you can hear from other users how they're using tools or reaching out to vendors directly to really understand what the capabilities are in a tool. So you can start thinking, okay, how would we leverage those? But it's important to start at the beginning and really understand what you are trying to accomplish. It's always important to establish your project goals and objectives and sort of get alignment on them, maybe in a working group. That's often a good way to get started and really start to map out the kinds of processes you may want to automate and really think about them, what the requirements that they would impose on automation are what you might need to integrate workflows with, again, CLM, other repositories, your e-billing tools and so forth.

‍

(27:45):

And then thinking through the requirements that are implied by the kinds of use cases you may be trying to employ, getting out to the business and having some conversations with them about where are their trouble spots, where are their sticking points, what do they want you to solve for? And oftentimes those may be very different things than the legal team is thinking about or they may have additional requirements that they want you to document. So I would think of it as sort of a diligence investigation phase where you're understanding your current processes, their pain points, you're thinking about the tools you already have available within your walls because you're going to have to have those discussions with your IT teams.

‍

(28:41):

Thinking about the impacts of the use cases on the people that are involved in those processes, how will you manage the tool? How if you're alleviating a lot of administrative burden, how is that going to change the day-to-day job of some of the people who are currently uploading and profiling agreements to the CLM? How can you help them re-envision a role that hopefully focuses more on the types of work they want to be doing rather than the administrative kinds of work? And then I think as you get through that design phase, it's really starting to map out what those workflows will look like, validate again with the business users that you're headed in the right direction, think about their specific needs because as the builder, you should always be trying to satisfy all of the constituents, not necessarily taking all of their requirements and building something crazy, but really making sure that the information that's flowing through the data that's flowing through the system is useful for everybody that you can do the kinds of reporting that the business needs.

‍

(30:19):

You can do the kinds of reporting that finance needs, you can do the kind of reporting you may need and legal, and then start thinking about some of the change management that you may need to undertake. So there's a lot. You get through the diligence phase, you move into the design phase, and I think as part of the design phase, you can really have some heart to heart conversations with your main stakeholders with that working group who may be leading the project about how to phase out the workflows that you want to build and what you should focus on first. There's a lot of ways to keep it simple at the beginning to deliver a lot of immediate value for the business to tackle sort of easier to tackle problems and then phase that out so that you are dealing with the more medium complexity, high complexity workflows once you've already learned a thing or two about getting workflows together and really more about the capabilities of the tool sets that you're using.

‍

Evan (31:41):

Absolutely. I mean there is so much there, which is why it's very much a capability that's built over time in being able to even run readiness work for transformation and particularly workflow, but I'd like to think about it as when you're at that initial sort of what did you say before design? So you're in before the design

‍

Brian (32:06):

Phase, diligence, investigation,

‍

Evan (32:08):

Diligence and investigation. Yeah, so in that diligence and investigation stage, I guess it's an appreciation that vendors tend to be experts in the solution, but actually you are the expert in the problem and the vendors will do their best job to understand problems through their discovery and then you'll need to do your due diligence out the other way to understand how their solutions work. And it's almost like the bringing together of those two worlds that then create the perfect storm. And I think the looking inwards is where you start, but I like how you talked about it's good at the very beginning to also take a scan of what is actually possible on the other side not to commit, but it really helps create your vision almost of what is possible, but really still focus on what are your core challenges that is what are the business outcomes that we're looking to achieve here? And then moving into the design phase mapping. And so some of the outputs might be things like what, like a list of requirements, it might be process maps. Are there any other outputs from this sort of readiness phase that you typically see?

‍

Brian (33:16):

Yeah, we usually put together spreadsheets of the metadata that's moving through each workflow and then how that data may flow into downstream systems, through integrations. All of those things are important and getting a data map along with sort of a Vizio of how a process might run. And as you said, your requirements list I think are really important. Ultimately as we move further towards system selection, we tend to put together a short script or the potential partners that our clients want to work with that those vendors can put together targeted demos a little more specific to what the client is expecting to see. And I think that's really helpful too. Not everybody, when they approach workflow automation has the same sort of imagination, imaginative capacity, they kind of understand what they see. So getting an initial sense of the requirements and then helping people understand what will that look like in a workflow really starts to bring everybody together and help you get much more specific feedback that can help you then fine tune designs.

‍

Evan (34:53):

And I don't think, well, I think there are people out there who may not realize how important bringing people into those earlier phases is because it's the beginning of your change management exercise. It's not only getting to build and select the right thing, but it's also beginning that buy-in journey that is so critical because if you go all the way and then launch a tool and say, now use it often, you're going to be a lot of, you're

‍

Brian (35:19):

Really risking adoption or lack of adoption at that point if you've already brought in at the right time. I'm not necessarily saying at the very beginning, I think it's good for, in our cases, legal teams and legal ops to really understand what they need to deliver and before they go out and solicit a lot of feedback from the business. So it may be a little bit further along in the design process, but I think it's really important not to design in an echo chamber and not to design something for the legal team because really the legal team is not the consumers of what you're building. It's all the teams out and around the business. So you want to hear from them, you want to identify the friends, the people that you work with regularly anyway that sort of understand the processes. They understand maybe the challenges of the processes that they face on the business side and they understand things like specific data points which are useful for the business, but that legal doesn't care about at all, like project numbers or expense coding, things like that that you may need to include fields for in a workflow manage, but that have nothing to do with the legal part of the workflow.

‍

(36:48):

So you get a much more complete view and you start, as you said, developing cheerleaders really those change management agents out in the business. So when you do launch, there's already a sense that you've taken the needs of the business or different parts of the business into account and that's going to go over much better than here's the thing, now use it.

‍

Evan (37:18):

Absolutely. Okay, let's continue on our story here because so we've got the legal team, they've now done their readiness work and they're ready for vendor evaluation. So they go out, they probably jump on a bunch of websites, ask their peers, what are you using? And they whittle this down to a shortlist and obviously they need to at some point pick their preferred vendor. So now that you've run so many evaluations and seen so many RFPs around this stuff, what are the main capabilities and characteristics of workflow tools that you tend to find are needed in a workflow automation system? If you were to have the Brian hub cheat sheet, this is the R F P cheat sheet for workflow automation, what are the key items on that?

‍

Brian (38:05):

Yeah, I think there are a lot of things that are table stakes that every vendor will deliver. Sort of the flexibility of building intake forms, sort of the ability to build smart forms and leverage contingent logic on the backside to really keep your form relevant to the type of request that you're dealing with. So a lot of that I think is sort of basic. I mean I look for those things in all vendors and most of you do that extraordinarily well. Then I start looking at some of the specific functionality that is sort of the key requirements I would call them as you're gathering requirements, what are the things that are more specific to the kinds of workflows that you need to launch? Do you need really robust self-service contracting functionality? Do you need to be able to manage 10 templates in a workflow but keep it simple?

‍

(39:21):

Do you need things like dynamic clause insertion for dual language provision and contracts if you're contracting with Quebec or France for example? Are there sort of more robust data table management needs because you have very complex approval matrices or decision trees that you have to basically build into the backend of your workflow platform. So lots of different requirements can come up and that's why when I said as you're working through prioritizing the kinds of workflows that you're likely to launch, not only in phase one, but maybe looking down the road a bit, what are the likely ones we're going to tackle next? Extracting the key requirements from those and making sure you've got the flexibility and the scalability in the platform to address those. I think it's really important. One of the other things that I've always found super important is understanding how responsive a vendor is to additional needs.

‍

(40:47):

Hey, we've got this need. I've talked to other ops people and they seem to want that same kind of thing. Can we add that? Can that be added to the platform at least over time? And do you have an active community of users who are feeding back ideas to help build that platform roadmap so that you've always got an active engaged community and you've got a platform that's going to grow with you over time? I think a lot of what we're seeing now, and we can probably talk about this later, is a lot of the AI features, the generative AI features are starting to come into workflow. So is it important for you to manage FAQs through the platform? Do you need that kind of conversational chat so that people can find the workflow that you built when they're in teams or Slack or can they find that training deck that you put together that you spent a lot of time on but nobody looks at it because they can't find it?

‍

(42:02):

Or do you need to help them in the sort of consumer society we live in today? Do you need them to be able to get a quick answer from a 10 page policy that they're not going to read? So all of those sort of go into your capability set and I think as you're working through that, you're constantly thinking about the user experience and what you're delivering and it's important that you do that because that's really going to guide a lot of times ultimately, which vendor you decide to go with, which platform for our culture at the company that I'm in feels intuitive, which platform feels like it belongs here. There's a lot of that subjective part of it, which goes to how easy it is to use, how intuitive it is, how little change management might you get away with doing? I had workflows at Dolby for example, when we rolled out a pretty complicated NDA process. We did it with zero training. We started with a beta group and we found that we had essentially built it in a way that was really intuitive and easy to use and it had a lot of information in the system so that people could get answers if they had questions.

‍

(43:44):

That's not always what you can get away with doing, but I think if you've designed it right and you've really thought about the user experience and you've thought and you've gotten that feedback from the business and what their expectations are, then you can really design something that is much easier to use on the front end, even if it's really complicated on the backend.

‍

Evan (44:09):

Completely agree. I mean because workflow often then touches thousands of people in your organization or tens or a hundred thousand people at the end user recipient end of the workflows. I mean, it's not practical to train people on how to use the tool. It needs to speak for itself. There needs to be no training required, at least as you say for the actual participants of the workflow. But of course people building it, I mean the complexity is inherent in process design there, but for the end users, absolutely. I think there should definitely be an expectation where people can just click a button and just make their way through and get to the answer they want. Absolutely.

‍

Brian (44:48):

The other thing, one other thing before I lose the thought is that obviously I mentioned that you may have other systems internally, you may have, it may have ServiceNow, your IT may use Jira and they say, oh, well you just need a simple workflow. Why don't you just use one of these that we already have and maybe that meets your use case. But what I'd suggest and what I've done traditionally is when I've come up against some of those walls with the IT team is really to do what I call a demo off. Give them the same script that you're giving to your other shortlisted vendors and tell your IT group that they have the same couple of weeks to demo how that can be built and whether it can, they can give you an assessment of what they can build, meet your requirements and deliver what you need. And if they can't or it doesn't, then you've already helped yourself and helped that conversation move forward and now they're thinking, okay, you have thought about your requirements, you have thought about your design and the functionality that you need and maybe we don't have that in this or so maybe the IT group can come to the table a little more open than the otherwise might be.

‍

Evan (46:25):

Yeah, I'm glad you jumped back in there because I feel like that is a very common road bump that many people may not expect if they haven't tried bringing in a workflow tool before because workflow by its nature, as we said before, is an enterprise concept. It's just that a lot of these workflow tools are so purpose-built for the use cases and requirements going back to the business problem for legal and related functions, that it is a better idea sometimes to bring those in than reuse a ServiceNow or a Microsoft Power apps, et cetera. So I'm glad you brought that up because that demo off, demo off bake off whatever you want to call it, is a really effective method because you can always build, those tools are super robust. You can always build many things using those tools, but it's like it requires your IT team and it's like at the bottom of our two year queue.

‍

Brian (47:13):

Yeah, exactly. That's what I was going to say. I mean I'm always very skeptical of people saying, oh, we can build anything on our platform and that may be technically accurate, but it doesn't necessarily mean that that's the easiest, most cost effective route to go. And a lot of legal teams traditionally suffer from a lack of dedicated IT support. So choosing a solution that's really dependent on an IT team better means that the IT team is serving up a fully dedicated resource and usually that's not the case.

‍

Evan (47:56):

Yep. Awesome. Great. So final step, I guess in our process we've gone and determined, alright, we don't need CLM for the moment or matter management, what we need is workflow. We've then done a whole bunch of readiness work internally, process maps, list of requirements, the data model and how it flows into all the other downstream systems and upstream into those systems. And now we've taken that requirement sheet and shortlisted the vendors, the process is then interacting. We're finally now having meetings with vendors. What does that look like? I think before you mentioned a bit of a demo script for the vendors. What does that process look like? If you are now at this stage, what meetings do you have? Who do you have involved and how do you go from this step to basically signing a contract?

‍

Brian (48:46):

Yeah, they're good questions. It's always going to depend on the organization somewhat, but really if you've got your designs, you've got your requirements, you you've got a demo script and you've seen demos really seen the things that are relevant for you in action, then I think it comes down to discussions internally about the best way to go forward either for the legal team or the collective group of stakeholders that are looking at workflow automation solutions. And I think at that point you're bringing in your IT teams more. You're bringing in your information security people into the conversation if they haven't already been involved. And a lot of it, again, as I said, often comes down. I think for a lot of our clients, once the capabilities are met, they know that it's possible to build out what they need in a handful of systems. Then it starts to become more about what is the user experience in our environment and how well it will interact with the other tools in our legal stack, in our corporate tech stack.

‍

(50:28):

And a lot of times some of that is kind of subjective, but again, something you can validate with sort of your key friendlies out in the business to get their feedback as well. Then I think negotiation of pricing is important for everyone to pay attention to. I think a lot of traditional problems and why a lot of teams have ended up in point solution situations is because of the way workflow automation tools can sometimes be licensed on sort of a number of workflows requiring people to go back, get additional budget approvals to continue to build out and so forth. So it's important to understand what you're getting to have thought about what phase two and three might look like. If you're building two or three things this year, what two or three things might you build next year and the year after, and is your set up with the vendor aligned with that vision?

‍

(51:56):

So I think all of that is important. And the great thing about workflow automation solutions, just because you're probably like, oh God, don't talk about pricing, is the fact that the ROI for Workflow Automation Solutions has such high and immediate return and value that these are really kind of no-brainer projects from an ROI perspective. When you look at each individual workflow you're building out and you think about the 10 minutes you're saving here, the 15 minutes you're saving there and you think, okay, maybe we're saving or offsetting cost X amount against actual people cost, those are real dollars that are at play. And I think Gartner and Forrester are both saying workflow automation pays for itself in three years. I've always found that to be super conservative. I always found that it paid for itself much faster than that and really, again, started freeing up some resources so that you get other benefits around your organization as well can move people to deal with more significant, more meaningful, more strategic work rather than some of the administrative things that they're having to do today.

‍

Evan (53:27):

Yeah, amazing. That was really helpful. I've got one last question for you to wrap this up. You mentioned it before, and given all of the talk nowadays about Gen ai, we can't end this episode without at least having a single discussion point on it. I know that I saw that you and your Uplevel colleagues published an article in I think above the law recently around gen AI and specifically how it's driving change in the workflow automation space. So where do you, and I guess your uplevel, the general sentiment from your organization see workflow heading on this front of AI and what does that actually mean for those of us who are looking into system selection now? Is that something we should be including in our RFPs and our vendor assessments? How strong of a view do you take on this?

‍

Brian (54:18):

Yeah, well, I really think that you want to find vendors that are either starting to build use cases out or that are working on their roadmaps, sort of actively working on their generative AI roadmaps. I think a lot of the use cases that we're focused on or very practical in nature, again, sort of F A Q and process and policy information management, having that sort of conversational chat assistant be able to help people with getting answers from a defined set of information that you can keep within a walled garden so that the AI is only looking to that to answer questions. I think the future is going to be how these AI assistants can work together across different tool sets and help us leverage data that may be in disparate systems and really facilitate tasks that go across multiple AI assistants. I think there's a lot of great stuff coming.

‍

(55:43):

Again, I think right now having that sort of F A Q management, being able to launch workflows from places like Teams and Slack where people live and spend more of their time without necessarily having to go to a dashboard that's specific to the workflow tool is really helpful. It makes it that much more user-friendly for the business, and I think the potential in the near future to have AI help generative AI help build workflows and design them is kind of the next thing that will also save time and money. And if you can write out a script of what you want your workflow to look like and the AI assistant can build that workflow for you in the background, that's that much faster, you're up and running that much faster. You have a prototype model you can start testing and a lot of costs and hours that you're saving in getting it launched.

‍

Evan (56:56):

Yeah, I can imagine a near future where legal ops person walks into a room and says, Jarvis, build me the workflow for blah, blah, blah, and then the bot just,

‍

Brian (57:08):

These are the stages it needs to go through. These are the approvals it needs, and we're really not very far off from that. Things are moving so quickly. I think it's really exciting to see what's coming,

‍

Evan (57:23):

For sure. All right, well, we're on time. Brian, thank you so much again, someone did post and say that they want to request the fire photos if you have time to share them, please and thank you. So you've definitely piqued the interest of someone with your art, but if you want to check out Brian's art, I think it's at Brian, what is it, Brian,

‍

Brian (57:46):

Go to Instagram, Brian Hupp Fine Art, you can see sort of the latest. That's where I post most of my stuff, and thanks for looking

‍

Evan (57:56):

Super cool. Big thank you to everyone who decides to lend us their time today and tune in. And Brian, of course, a big thank you to you for dedicating some time out and sharing your expertise. And just to rub in your face again, over 25 years of experience was captured in an hour of conversation here today. So thanks so much, Brian.

‍

Brian (58:18):

Thanks Evan. We also have a lot of free resources@uplevelops.com. If you want to pop over to our site and see if there are things that can help you out,

‍

Evan (58:30):

Definitely go check it out. Like I said, Uplevel is amazing and so is Brian, so please continue the conversation. You're interested. Alright, everyone, have a fantastic rest of your day. Thanks, Brian.

‍

Brian (58:39):

Thanks. Bye-bye.

‍

Evan (58:40):

Bye everyone. Thank you so much for tuning in to this episode of Go With the Workflow. If you found something valuable, you can subscribe to the show on your favorite podcast app like Spotify or Apple Podcast. Also, please consider giving us a rating or leave a review as that really helps other listeners find the podcast too. That's all for now, so we'll see you in the next episode.