Business Workflow + Design Framework

[Adam] Good morning, or good evening, everybody. Thanks for joining us today for another best practice webinar with Accelo. Today we're gonna be looking at Business Workflow Design. So my name is Adam. I work in the implementation department here at Accelo, and I'll be the host of today's webinar. Then we've got John, as well, who works in our sales and is a service designer, and he'll be presenting the content today. So a bit of an overview of today's session. We're really gonna go into the workflow design. Starting it broadly with some examples from industry, and then looking at a bit of how we design a workflow. We're gonna kind of dive into two of the modules that we have here in Accelo in the ticketing and projects to show you what the different components are and what we've seen as best practice. Then, finally, a bit of improvement in the innovations based on how you can really optimize your workflows. Now please feel free to submit your questions as we go along. There's a Q&A section of the webinar, or you can send them through in the chat function and we'll get to them at the end. Now I'm gonna hand over to John now so we can get into the content.

[John] Great, thanks Adam. So what I first wanted to do was kick off with a service business example outside of the professional service industry to start it off. What I wanted to start off with was Starbucks. The reason I want to do Starbucks is hopefully most of the people on the call today have been in a Starbucks or at least heard about what Starbucks does. Also, what I like about it is how consistent the product and the service is. They've really found a solid niche of being able to, from all the way from China to the UK, have a really simple process that delivers the same latte and the same cappuccino wherever you are, and also the same service. When you walk into a Starbucks you feel warm and welcomed by the employees and the environment that they've built. Lastly, it was my first job, so I've been on both sides as the employee of a Starbucks and also as someone who frequents Starbucks. When you go to a Starbucks, you're first greeted by the line or the queue, and what you'll start seeing is things like the menu, what's available, some of the merchandising here for upselling. Then the next phase or the process when you go into a Starbucks is you're greeted by the barista at the point of sale. Let's say Shawn here asked you what you would like and you order off the menu, you might order a pastry, and he takes down the order, and you pay him. Then what Shawn does is he passes it off to Jimmy, and Jimmy makes the latte. Let's say it's double strength this morning. And you're watching as Jimmy makes it. Getting really excited for your drink. And then either Jimmy, or if he's too busy passes it off to Lauren, and she greets you with a smile, calls your name, says, "Hey, John, "your double strength latte is up and ready." You say, "Thanks, Lauren," and you take the latte. Then the next step is you either sit there for a few minutes and enjoy it, or as this gentleman does a few days on your computer as you work remotely, or however you end up spending your time at Starbucks. The reason I wanted to go through this example is to share some frameworks that Starbucks uses and that we use with our customers when they're designing their products and services. Those two are business process modeling and service blueprint. Adam, if you wanted to talk to this a bit as well.

[Adam] Yeah, so especially when we have new clients come in and we're discussing workflows initially, we talk about this a couple of ways we normally see it going. First one is the really simplistic way of setting up your different phases of your said project or sale to mirror what you wanna see in a reporting sense. So on your list screens, if you wanna look at your project pipeline and see where everything is, we kind of structure the different phases, or status as we call them in Accelo, as different areas you wanna see from a reporting standpoint. Alternatively, and we'll go into this in a little bit more detail soon, is you can actually optimize your statuses so that you can maximize the amount of automation you can bring it. And something will be talking about soon is progression actions. You can really tally your statuses in a certain way that you can get them the majority of the work that happens in a project or a sales process to be automated or standardized using progression actions. So we normally see them going one of two ways from the start.

[John] Thanks, Adam. When you're building or making a business process model, or even a service blueprint, it doesn't have to be fancy. Sometimes we use things like Lucidchart or draw.io, but as you can see here it really only takes that pen and paper to start mapping out the journey of the client and the interactions that you have with them. So what we're seeing here is the Starbucks example. First start off with I'm thirsty. I need to have some Starbucks, or at least I've identified Starbucks as the right store to go to. Then we go to the moving into the line phase, or status, you can think of it that way. I then decide on a product from the menu or the type of work that I want Starbucks to give them. Then there's the ordering phase, and there's a bunch of other actions that happen within all these phases. Essentially, there's the make of the drink, the call out of the drink, and then the enjoy. You can think of these as the flow or the business process that a Starbucks takes to eventually deliver that service and product to the customer. The other approach is called a service blueprint. What it does is it first starts with the physical evidence that the customer sees within the store, like the storefront or the barista at the point of sale. Then there's the customer actions they take as they move us through the service and the product, like paying or picking up the drink. There's the front stage where the employee is interacting with the client. Then there is the back stage where the employee is doing all the work and rendering all the work. So often the back stage is hidden behind the line of visibility, like they're pulling the shots or they're setting up the menu and the pastries before the store opens. Then lastly, there's the support process. Normally this is like the workflows, the process, the business technology that underpins the whole entire operation. What we've found is the business process model works really well for understanding the flow; whereas, the service blueprint is a really good way to understand the customer or the client journey. And if you're a web design company or if you're a business consultancy, you might be having these conversations already with the customer around design thinking or innovation around how they can better service the client. Now if we are to take this now in your terms of operation in Accelo what it can do, let's take a look at the customer issue ticket for the business processing model. It normally starts off when a customer has an issue that they can't solve on their own, and then possibly there's a few channels that they go through. They might send an email to support, call the hotline, or as we probably ask them not to but they still do, they email their favorite technician. Then there's a flow of taking these emails or phone calls or whatever channels they choose, and the support technician creates the ticket. So you can think of this as when a customer arrives at Starbucks, they've identified a need, then the different queuing that happens when it comes into our world. Then sometimes there's decision points like do I have enough information? And then there's eventually a resolution where we're working on the problem, and then notifying the customer that I'm done. So normal business process models, and again this is a very slimmed down version of what it can be, you can think of this as just boxes of things that happen, whether they're client or internal, and then arrows that connect the things that need to happen. On the other side, if we were to do a website project example using the service blueprint, physical evidence is really difficult for especially online or digital consultancy or web design businesses. So what we've seen the best practice out there is using the phases or the general evidence of the project and just calling them there; whereas, the evidence is really the sign offs, the invoices, the reviews, and things that happen as you go into these different phases. So, for example, if I'm kicking off a project, maybe the customer needs to grab the KPIs. If I'm building a mobile app, we're trying to increase revenue by 10%. What are the goals of the project? Then I have my conversation with the client, like a kick off call. On the back stage actions, this would be internally within the web design firm. What do I need to do? Like an internal kick-off call. Then lastly, there's the support processes. Usually we're thinking of these as the technologies that underpin this operation. Like I've created a creative brief in Google Drive, or I've just kicked off my Accelo project. And we're gonna be using these two examples to go through all the ways that we have statuses, progressions, and actions within Accelo, and how you can build a process within Accelo that maps onto something that you've created with pen and paper, or like I said with software. So what I wanted to do was start off on the ticket side. We'll first jump into statuses, and then go to more advanced things like progressions and eventually actions. How can I automate my process? So we'll go back to this customer issue and ticket example. The first choice or decision that we need to make is based on this workflow what should we call the different phases of the statuses. These are the four most common ones that we're finding with our customers. When a new ticket comes into our world, we usually want to have a submitted status. It's been submitted by the customer, but we aren't actively working on it. Then we have a decision point. It's open, or we need more information and we move into waiting. Then, lastly, we want to resolve the ticket. So what I'm going to show you is how to set up these four different statuses on a ticket, and then we'll take it from there. So all of the progressions and types and actions will be through configuration. In this case we are interested in tickets. Anytime we're talking about workflows and custom business process, that would be under progressions and fields here. So we already have one ticket type. Let's create a new one. You might want to put notes for the admin coming back to maybe assumptions that you've made, maybe even a link to the business process map. In some of these other fields for a custom ID, this just allows you to have a number in front of the different tickets that are opened. Is it billable? Is the work here billable? Can I eventually invoice the customer, or will it pull up onto a contract, or is this something that's just internal, like I have an issue with my computer and the internal tech team is working on it? Email sender address, this most often than not will use the user's own email address, meaning that the technician emailing the client, a client can see who the technician is, and knows him by name. Or we can use a variety of different aliases if we want to hide the technician, especially for like outsourcing the work, or if we don't want them individually emailing them. This has been a really good way to mask that. Then, lastly, if we're building a new ticket progression maybe we want to pull the progressions from a previous ticket and just make some slight modifications to it. This'll save you a lot of time by pulling the progressions as well as the custom fields. But in the example today we're gonna built it from scratch. So if we remember, we wanted four different statuses, and the way that we create new statuses is here. First one being submitted. What standing does is in the example today it's going to nearly perfectly map onto the name that we give the statuses. But let's say that you have four different ticket types and on a different ticket type submitted is a different name, what we would do is make the standing submitted, but then the title would be some other thing like on site visit requested. What standing does is, as Adam was alluding to, on reporting, if you're trying to report against multiple different types, standing helps you roll up all the names within a given type. It makes it a lot easier to say, what is everything within this status that is submitted even if they're different names. Then the last one is start. This allows you to define if a status can start a progression. In this case yes. In a lot of cases, no, we don't want a status to start a progression, it's in the middle of a workflow. Then, waiting if we don't have enough information. So submitted, waiting, open, and then the last one would be resolved. So now what we have is, besides our little blank status here, we have the four statuses that are involved in the process that we defined. The next step in defining my business process workflow is connecting the dots, I like to think of that as, and the dots or the lines in between each of these phases are what we call progressions. For example, when a new ticket comes in the progression would be moving it to submitted. Or when a support technician or someone on our team starts working on a ticket, we'll then progress it, or move it, between submitted and opened. So the next step in billing this workflow would be creating status progressions. Just like the business process map, what we do is we connect it by dragging two statuses together. Unless if it's the on create. Then, lastly, we have open to resolved. So we have available and create to submitted, submitted to open, and then open to resolved. Then, we have this side area as well, and what we'll do is we'll address this a bit later in the call, something called loops or decision points, and show you how you can build those into the process. The last thing we can do is build actions, and actions are things that you want to happen in each step. You can think of this as not only automating the updates and things that need to happen to the ticket, in this case, but they can also be automation sitting behind in Accelo to help you update fields or to send out automated alerts. In this case, what we want to happen is an automation at the very end when we resolve the ticket to then notify the customer that we have resolved it. What I'll do is add an action, and like I was mentioning before, there's a full range of actions that can happen, like updating a field, uploading a file like creative brief as we'll see on the project side, or creating an activity. And activities in Accelo are either internal notes, emails, they can even be meetings that we send out to the customer. Creating a task, this is on the, at least on the ticket side, good for follow ups. Maybe we haven't heard from the customer in a week or so. And then a full range of special processes that we'll get into a bit later in the call. So what I wanna do is there's actually two things. On the resolve I want to say, "Turn your computer off, "wait five minutes, and turn it back on." So that's a resolution note. Then, on top of that, I want to send that resolution note to the customer. So first I want to update the resolution type. I'm gonna leave it blank in this example. Do I want it required? Probably because we're emailing this to the customer, but sometimes I don't want required fields. Like this is an FYI or helpful piece of information in the sales process, but not really necessary for the closing of the sale. That's the times when I might not want it to be required. Then, lastly, hidden. In this case we don't want this hidden, because we do want the technician to update and put in the resolution type to then send to the customer. In other cases we do want it hidden, like an automatic alert if a ticket has just moved into a certain status for our team. So update the resolution type, and that's mainly for internal reporting, and then next I want to update the resolution. Put in some helpful information, maybe some guidance for the technician on what they should put in here. Then the last thing I want to do after I update those fields is create an activity, or you can think of that as an email to the customer. So in this case I want to email the main ticket contact. In the off chance that the person who submitted the ticket is different from the main contact on the ticket, I wanna email them both. In action title I usually like to put what I'm doing, like an email, if it's an internal note I might do internal alert here, and then the title of the email. What we've found best practice for internal emails and then also for clients to be able to easily search it later is either have the subject here so that it's a unique email in their inbox or some sort of ID. And that really depends on how your team works. If it's more casual and personal, a subject might be helpful. If it's more operational and there's a lot of tickets going around maybe an ID would work better, or maybe both. What I'm pulling in here, these merge fields, is taking information from the issue and then automatically populating it, and we'll see what that looks like as we go through the ticket. Maybe we want a little P.S. at the very end with a link to the client portal. We can start making it personal. Then lastly, I want to pull in some other fields like my resolution notes, and a nice little sign off from the technician who was working on it. Again, this idea of hidden and required comes up on this. We don't want this hidden, because my team wants to potentially personalize this email as we send it out. Maybe it is an existing relationship, and this email template feels a little too operational so I'm not gonna have it hidden. On the required side, yeah I really don't want any of my technicians skipping when I close out a ticket. Then the last part on this is just helpful for billable work. Let's say that these emails use to take you 10 minutes, but now you've automated it in Accelo you can put that 10 minutes in if you still wanna charge for that time, and have it billable. So let's take a look at what this looks like. And again this might be coming through the various channels as well, instead of me just manually creating a ticket. So we've now submitted it, and the only option that we have from submitted is to open, and that's because the only progression that we're allowing it to move into open is from submitted here. Then the next step as we're opening and working on the ticket is to move it into resolved. And as you can see here, when it's opened it can only move into resolved by, I know this isn't the perfect example because it can probably go into a few different areas, but just for today we'll make it linear. And then I want to update the resolution type, the resolution, and then send a quick email to the customer letting them know that we resolved it. So I gave some advice and in the case of this I asked them to turn it off. Now what it's done is it's pulled in this activity, sent it to the ticket submitter with the title of the ID and what we've done as well as the notes of what we found. Then, lastly, the 10 minutes are already sitting there. Now we've moved it to a resolved ticket. So in some ways it's starting to now resemble this ideal workflow that we're building out for the client and sort of ideal for our process internally, moving it from a submitted to an open, resolving, and then automatically notifying the customer. Now on the project side we'll go through the same workflow of statuses, progressions, and actions. So the first is taking a look at statuses on projects. What we've found is two approaches. Projects are interesting, because a project process in Accelo is both statuses that are high level, as well as, the actual process of the project with the milestones, the tasks, that go into it. So sometimes we're seeing our customers mirror the project plan of the planning, the design, all the way to complete. Then in other cases, we've seen our customers simplifying it where they have a planning stage for everything that's coming through the pipeline, then taking all these statuses and making them live. That's just helpful to say, well, 50% of my projects are currently in the live status, 50% are in the planning, rather than being possibly too granular in each of these statuses. Then, lastly, a complete or go live status. So similar to basically every choice that we have for creating a ticket. Exact same setup for statuses and progressions. So we have a planning stage. We have an active or a live status. Then, lastly, we have a complete status. Similar to the ticket side, especially if we were to do a linear approach, is just connect the progressions between each of the statuses. So anytime we create a new project we want it to move to planning. Planning moves to active. Active and live projects move to complete. Then the actions that can kick off a project in this case. So anytime we wanna move it to the planning, we can like a ticket, update a field, upload a file, notify team members, and then do a special process. So, in this case, we were saying, well, we need to pull that team together and notify them what's going on, we need to upload the creative brief, and then possibly send a down deposit invoice. Then let's notify the project managers and the company managers that a project is started or is at least in the planning phase. And I'll just give them an internal link to see where it's coming from. So that would be the behind-the-scenes that the customer doesn't see. Then, lastly, a special process. So on the planning what we found helpful is having a plan pick up every single new project, as well as, if it's a fixed bid project and there is a down deposit that's needed, then just send an invoice. So let's see this in action. We first wanna upload that creative brief. In this case, I'm gonna link directly to Google Drive. Maybe I'll upload this Best Practice webinar. Next, it brings me to the project planning notification to James Knoll, who's the project manager and the client manager here. So I'll save that internal note to notify the team. Lastly, it brings me automatically to send a down deposit invoice. And we're using invoice templates here. There's another best practice webinar on that for how we can automate the ability to have down deposit invoices automatically say 25% here. Then, like I was mentioning, we would probably drop in the project plan as well to sit there. So that's everything for the simple: connecting statuses, progressions, and actions on the ticket and the project side. Now what I wanna do is jump into three more advanced things. The first one being decision points and loops. So in our more advanced ticket workflow a support technician creates the ticket, and then there's a question internally of do we have the knowledge, skills, and abilities to solve this? Or if that personal technician doesn't, then we ask the question who does? Does the client? Does a third party vendor, like Oracle or Sales Force? Is it an internal team member and someone more knowledgeable than me, and do I need to escalate it to a tier two support person? So let's hop back to these tickets. What I want is before it moves to open, or actually even in open, we wanna move it to a waiting status. So we have that waiting status here. Something that we can do, more complicated loops, would be to have waiting come from a specific area. Sometimes we're seeing waiting as just as catchall status, and you can move any into waiting, and then drop waiting back down into an open queue. It's however you wanna set it up. Today we'll do open to waiting, and then back to open. But just to let you know, you can do more advanced things. Then, what we wanna have is specifically who's involved with this waiting, or who do we want to work on it. There's a few things that we can do. One that we found actually really helpful is creating a custom field called waiting reason. Potentially, we want a drop down of all the different waiting reasons. Other times we want it just more open like a text field. Now that it's in waiting, what we need to do is we need to loop it back into a status in that core workflow. So we're gonna loop it back into open. So now we're just waiting on the client or waiting on a third party, and then internally we might wanna do an escalation queue like a tier two support or potentially just a reassignment workflow. We don't have time to go into that today, but that's likely what we would do as the next step there. Next is a point of automation. So if you can see here at the very bottom. Normally we go through the ticket workflow, at least as it currently is today before Accelo. And we asked our question at the very end, is it covered by a support contract? Then we eventually log our time. What we can do is Accelo is change the flow of that. So anytime we open and create a new ticket we can have it automatically go to the support contract, and as we progressively log time on the ticket it can automatically link back to that support contract. So here anytime we open a ticket, we would go into a special process. And what we want to do is link to the latest active or open contract. Now what this will do anytime we move it to open is it's automatically going to link back into that contract. Then the last piece of it is service and product offerings. So when this comes into the queue, we may have a triage team who looks at the needs of the ticket and determines is this ticket a bug or does it feel more like an improvement that we can backlog or is it something where we need to go over to the client site and help them out? So what we would do in that case is we would create different ticket types, and then select them when we're opening a new ticket. Here we might want to have a bug ticket type, and then in this case we can take all the nice examples we're bringing from example ticket and use that as the baseline for this new ticket. Then, from here this is a totally new ticket. We can say, well, maybe there's a few other steps that need to go into bug tracking, and we can add that here. So some other examples of service and product offerings, on the sales you might have a different type for new business versus upsell. For projects, website might be different than social media. And we already went in this example. On a retainer, might be pre-paid versus post-paid retainer. You can have as many types as you want. It's just not binary like this. When we're designing workflows and we're thinking about the process, there's a lot of considerations that go into that. We unfortunately don't have time to jump into every single one, but we did want to talk about two things. First, the cycle time and the how long between different stages, and overall how long the process is taking. And then, transparency when we're going through the process with the customer and then also internal transparency. So one of the examples was, going back to the Starbucks, was cycle time. When people were coming into the store they were finding that the most of the time was actually waiting in line for ordering the drink and getting the drink, and that was a big problem in their process as they're looking at it. So what they developed was an order ahead app, and a lot of other stores like Starbucks have done this as well where you can order ahead, you can skip the queue or skip the line, one of the bigger pain points in the service and the product, and then just go and enjoy your drink or get it to go. So if we're applying that same cycle time to the ticket, a lot of the times this waiting status is a big issue of is the client getting back to us? Is the third party vendor getting back to us? Some of the things we can do with cycle time is put in custom fields and measure the days or the time in between when it moves into a status. So what I'll do is have a time stamp field called Date_Waiting. Then anytime I move it into waiting, I'm gonna update this field. And this is all for reporting and for measuring the cycle time so I can have continuous process improvement. In that case someone on our team doesn't need to see this. It's just a hidden metric that's sitting behind. Then the last is I want to have the default value at being today, the day that it moves into waiting. What you'll be able to do from this is see the day that it's moved into waiting. Then the last thing that we probably need to do is have the days in status. So I'm going to create a formula, today minus the day that it moved into that status, and so now what we'll be able to pull reports on is the number of days that it's in the waiting status in this case. Then we can look at is it 10 days in the waiting status? Is it four days? And with our custom field here, waiting reason, and we should probably have it as a drop down, we can start seeing is it the client that's usually waiting longer? Or is it a third party? What third party are we actively or more often waiting than not? And these are the sort of things that's gonna help innovate sort of like how Starbucks did finding the wait time and thinking about solutions to deal with it. Then the other side of it was around process transparency. In the case of a website delivery project, a lot of the process transparency was around the back stage actions and showing them. Really similar to the Starbucks example. They were having a lot of issues, and they wanted to show that they had craft and they're making the drinks, they weren't hiding anything. So what they did was they dropped down all their espresso and their coffee machines in the front to make the client interaction more face-to-face. They can actually see the process and what was going on before they got their drink, and they were finding that people actually enjoyed the drinks more when they saw all the work that went into that. So it's similar on the website side. A lot of that transparency around is it on time, is it on budget, what sort of design are you currently working on, and this is often a big pain point behind the line of visibility on much larger projects. Am I actively delivering value to the customer and can they see that? So what we have here is a few things. Within this project what we can do is anytime we kick off a live project, we can have a sign off to make sure that they agree and can make comments on the design brief that we've put together. Let's take a look at that example project. And let's make sure that they have access to the portal. So now we move the status into active. In most cases it's James as well. Or we can drag the files here. I would like her to sign off, and we can even put a due date on this for her to get back to us. And it might be a different project, unfortunately, so it's not James logged in, but normally we would be able to do is see the sign offs that we've then built into the process here, and they can approve or decline them from the client portal.