Webinars Best Practices Request Inbox

Request Inbox

[Tom] Today we will be focusing on requests in Accelo, and request inboxes. My name's Tom, and I'm your host. I'm an account manager here at Accelo, I'm also joined by my good friend and coworker, Saagar, who is a client success officer who will be primarily running the session today. I'm gonna hand it over to Saagar here. He's gonna really. Before I do, I'm gonna quickly run through the agenda, and then we can get going. I'm sure there's probably a couple other people trickling in as we wait. Today, so we're starting with just a general overview of what requests are inside Accelo. Moving through some kind of different use cases and different types of request inboxes that we commonly see across all our clients. Some general workflows and setting up these requests. Including setting up the various inboxes that go along with them. Managing and actioning these requests as they come in primarily as emails, And then converting these emails into objects in Accelo. We're talking sales tickets, are the most common ones. Both manually and also automatically through triggers. There is a Q&A function, so please feel free to submit any questions as we go, and we'll try our best to get to them. And yeah, I think that's about it, I'm going to hand it over to Saagar, and we can get going, thanks.

[Saagar] Thank you, Tom. So the first thing on our agenda is what are requests? So requests may not have been something that you may have used in your previous tools, or in Accelo just yet. So requests are manage, track, and respond to client requests sent to your shared company addresses from a central inbox. So think about your personal inbox. So for example, for my, it's saagar.gupta@accelo.com. Versus a request inbox that I oversee is support@accelo.com. So the differences are, you know, if a client's emailing me directly, I'll have to respond to it, you know, whenever I get time, when I'm not on calls. Versus a support address, whoever's first available and sees a request coming in, can immediately respond to get a faster answer to the client. So essentially, the goal is to give your team a place to work together to resolving or escalating sales tickets or projects that come in from your clients, or even potential clients. And, you know, kind of moving forward, it's to prevent any trip-ups, forgotten emails, or doubling up on work. So previously, with the clients we work with, an email goes through a distribution list that goes to a variety of individuals, say, you know, salesperson one, two, three. Now who's responsible for responding to that email? That might have a few taps on the shoulder saying, "Did you respond to that?" Oh, I assumed you responded to that. The idea with this request inbox is you know who's working on it, what has already been done, and then you can step in if nothing has been done just yet. So different types of request inboxes, or in other words, use cases. So here's just a couple examples of how we use it at Accelo. So you have email addresses like sales@accelo, support@accelo.com, accounts, bestpractice, implementation. And these are the different request inboxes, your sales, support, accounts, best practice, implementation. And then who actions these requests. So each of these inboxes notifies a number of different individuals, but what's nice is, through this request inbox in Accelo, again, you can tell if, say, Tom has already actioned another request that came in. And then I can action a different one. So we don't have to work on the same thing, or even view the same thing, at the same time. So it starts with having your own email address. You set up a request inbox in Accelo, and that notifies your team, and then your team will action those requests in Accelo. So looking at the common workflow. So it starts with an initial inquiry from the client, it can be through an email, a web form, and if you're familiar with our web form's API, it's relatively simple to have, say, contact us, or an info@request come into a request queue where you can action it from there, to client portal. So a client can create requests by the client portal for you, so you can, you know, let your clients know that. Or your internal staff can create a request, and a common scenario is, the sales team calls the support line for like sales and pricing questions, so we may create a request for our sales team to kind of follow up on that. So the next thing is, again, it goes to the request inbox, and at this point, it notifies your internal staff that is responsible for those request inboxes. It goes to an auto-reply sent to the client, so it might be saying, you know, here's what you can do based off common questions. If you've ever emailed into support at Accelo, you'll notice that we have an auto-reply that goes right back to you. And once it's in the request inbox, you can go ahead and reply directly from the inbox. You can relocate to an existing object, so what if that request is relevant to a sale project ticket or retainer? You can convert it into a new sale project or ticket. So for example, a client emails in saying they're looking to work with your team. You can then convert into a sale, and then assign it to a sales member of your team. Or you can just go ahead and close it. And the idea of closing that request is just, you know, it's taken care of, maybe you're waiting for a client reply, because when a client replies, it'll go back, and then you can reply to one of these two options. And one thing to note is you can automatically convert requests into, say, sales or tickets, that's probably the best examples. Especially in the IT space, a lot of clients will email into support, a support inquiry, saying something's broken, and a lot of our IT clients would have it automatically converted over into a ticket. That being said, in different industries, you may have different kinds of cases where certain request inboxes should be automatically converted into sales or tickets, whereas others shouldn't be. Again, feel free to ask any questions along the way. But otherwise, just kind of talking through the steps before we set it up live together. The first step is to set up a request type. The second step is to set up conversions, so what can this request convert into? So think of your sales tickets and projects, and you can even name specific sales types or specific ticket types and such. Setting up a forwarding rule from your team inboxes, from the current email to the request's capture email address, so think of your support@accelo, to your support@accelo, I guess in this case, .accelo.com. So in other words, your support@yourdomainname.com to support@domainname.accelo.com. Again, we'll talk about that. And then potentially adding a trigger for certain requests. So you may have support inquiries that you want automatically converted into tickets, is the example I used, and again that's really the most common. We can add a trigger, and that's only in our premium module, to you know, escalate those inquiries. But otherwise, as we'd like to do in this webinar, let's do this together. So if you just give it a second, we're gonna kind of zoom out and share a different screen. So we're pulling up one of our test accounts. This oogli that we've used for previous webinars. And the first you want to do is, where are requests in the system? Requests are hovering over your inbox, and it'll say support and sales. And you can show, you know, make a lot of these requests to show up, by going to your preferences and choosing which requests you'd like to be shown. So in this case, you can expand this. Again, we got here by hovering over your user icon, going to preferences, and then going to your request inbox, and you can choose which request inboxes you want to be showing on the top right. So, for example, if I come into our HQ account for Accelo, then I can see how many support requests are in there. So if there's say, over 10, then maybe I can jump in and making sure the clients can get a faster answer, versus if there's one or two, you know, I can probably let my colleagues handle that. Again, you can see your own personal inbox right above that. So again, separating your personal inbox from your team inbox, But right now we only have support and sales. So let's go ahead and set up a request type together. So if you hit that top left module button, and you go to configuration. We're going to go and click requests. And under requests, we'll see a couple of different options. And we're gonna hit types. So as of right now, we have a support request type and a sales request type. So let's add an additional one in together. So just something common, you might have Help Desk. This is a common example. Allowing emails to come in to this request queue. You have an incoming capture address, so the idea is, you may have helpdesk@oogli.com, all you'll need to do is forward it into helpdesk@oogli.accelo.com. Again, this will be in your, say, Google G-suite account, or your Office 365 account. These are called your distribution lists in your Office 365 account, or a Google group in your G-suite account. So you need to set up a forwarding rule into this email address. This is how our system captures those email addresses. Next it's, who do you want to allow to come into this request inbox? In most cases, again, I'd recommend the second option. Just because from our experiences, a lot of individuals tend to use their personal addresses by accident. Or by accident, or by whichever is kind of convenient to them. We will add them as a lead and convert them into a contact if you reply. We just don't want to negate any emails coming in, so we'll only add the request, or in other words, sender, if we can match it to an existing company, just because again, I might use my saagar.gupta@gmail.com email address, and then it may not be captured by those that are choosing that first option. So as we talked about earlier, should we allow this to the client portal? Sure, and invite to the client portal. I tend to keep this off, just because we like to kind of limit who is shown to the client portal, from our clients and again, it's really up to you. We tend to limit it to the admin members of the team. Then you have a user notification. So who can see these emails that are necessarily coming in? So you may have Saagar, you may have Nick. We'll just add a couple individuals here. So any request that's created in this inbox will then notify Nick, Saagar, and Tom. Again, you can also just add in a separate group, or you can just have one individual or no individuals. You can also have a dedicated activity address. So for example, you may have helpdesk@accelo.com. Oh, in other words, say oogli.com. So anytime a response comes in, you'll respond from helpdesk@oogli.com, right? Rather than your own personal address. So for example, if you ever just send a support inquiry to, say, a national corporation, say like T-Mobile as an example, you may have different people reply, but it's the same email address, it's your support@tmobile.com. All right, similarly, you can set up your own help desk and say, any reply comes in, it might be one individual, say Tom, and maybe Adam the next time. It'll still all come back from the same email address, but again, you can personalize it a bit more and just have it say saagar.gupta@accelo.com replying. You can also set up an auto-reply using the different merge fields, so when a client emails in to helpdesk@oogli.com, they get an auto-reply saying, you know, hi. You can put in first name, thanks for sending in an inquiry. And you can say, like, Oogli Support. And then just So you can set up these auto-replies just so your clients can get basically notification that you've received this inquiry. And let's turn this off just for now. But otherwise, I'm going to save this type. Now that we've saved this type, we can also look at conversions. So we've set up the request type, but what can this convert into? So at the moment, we have three different options: new ticket, new sales opportunity, and new project. These are conversions found on the left hand side. So we can add in separate conversions for specific ticket types. While this is a test account that may not have separate ticket types, let's take a look. Yeah, so it doesn't have any separate ticket types, but say you have default, which might be your bugs. You can go ahead and create a conversion saying New Bug. We can default the progressions, the activity classes, say problems. Potentially this can be automated, to automatically convert. And now we have New Bug here. What is allows us to do is go to Help Desk, and add in a new conversion. So again, we're still all working in the admin configurations under types and conversions. In this case, we're just adding that this can convert into a new bug, or say, new sales opportunity. Again, we're customizing it just a bit further. Feel free to ask any questions along the way. But lastly, we can also set this to automatically create into a ticket. And we're going to talk about that in just a bit, but kind of just seeing how this can happen. Automatic conversion, once per request. For any request that comes in, and we'd like to convert that request into one of those options. Say new bug. And if you turn this trigger on, then all of the requests that come into this. Request type, say Help Desk, will automatically be converted. So just taking a quick look at it. For each rule that's satisfied, the action will take place. What's important to note is, if you're already using this request inbox, which you may want to do is have another rule for the created date is after a certain date. So in other words, after today, rather than converting every former request that was already in the system. But otherwise, kind of taking it. Now that we've set up, say, this request type, now let's take this and see what can come out of it. So what I'm gonna do is I'm gonna just email into this given request, so if you give me a second. Again, you can email into that helpdesk@oogli.accelo.com. But I'm gonna hit that top left module button and then hit requests. Again, ideally, you'll set up that request to just be here, so you can hover over your inbox, and then go to that inquiry. So as of right now, we have two different requests in the platform. One was from nine days ago, and one was from the day that this account was started. So if you give me one more second. I'm going to give you just another example. Okay, so from this request queue, these are actually each inquiry that's coming in. Again, you can have different types of requests that come in, and also, you can also create requests. So just a few different options, and there's different use cases and scenarios for each one. So an email that might come into this request queue, it's because you've provided your clients, say, the helpdesk email address, or sales or support email addresses, which they can inquire from. Again, you can have that web form, you could have that client portal and all those options. But say Saagar went ahead and, you know, emailed you, saying I want your services. This is an example request from Accelo. Now it might get a little bit confusing because I have a test Saagar account, but otherwise, from here, now you have say three emails. And you have, say, sales members on your team. Now who's going to be working on which one? What you can do is if you hit reply or claim, an individual can claim one request at a time. So if Tom's working on this request queue, then Tom can go ahead and work on, say, Apple with Steve Jobs, because he knows that Saagar's working on this request. You can hit reply. And you can have an email that's kind of basically prompting you to send an email to Saagar. And you can send that reply in. Or, you can just go ahead and relocate this to an existing sale. Say Saagar has already emailed you what he's looking for, you can then just go ahead and hit relocate, and go to an existing sale, if there was one already available. In this case, it does seem like there is one, and you can relocate that request. Or you can reply and then relocate. What we like to do at our support team is, if we reply and we're waiting for the client, we just close it out. And if the client replies again, it comes back into our request queue. So in other words, you know, we're closing it out for now. Client replies, it comes back into our queue. Otherwise, you can just go ahead and convert these over. So you remember, we were adding in one of those conversion options, so sales and bugs, you can go ahead and convert these requests over into, say, a sale or a bug directly from here. So again, emails that come in, web forms, and you may have a call, which just an example. You may have a call that comes in for the sales team, but you're on the support team, you can go ahead and put in, say, that sales request type. You're looking for a new website, as an example, and hit Save Request. If you refresh, then it would show up. So you can create requests. Again, it doesn't have to be a call, and it's maybe you need the support team to take care of something, or you may need to accounts team to take care of something, or your interns or whoever needs to get a queue of work. You know, you can potentially use the requests for that purpose as well. A lot of just different use cases. You know, there's standard use cases, and then there might be creative use cases that you may come up that we're happy to help you with if you email into our support at accelo request inbox. So, just an example, if you go here, and you convert this over into a bug. You'll notice that this will populate with the title and description for that ticket. And again, it just simplifies that process. We want a streamlined process in Accelo, where all your client inquiries can come in, and then you can go into, say, the sales module, project module, or ticket module. But otherwise, just kind of, you know, taking a few steps back. If I want to add this request inbox, just to finish it off, just go into your user preferences, go down, hit save. And now, when you come into Accelo, you'll have that help desk request inbox as well. So you know, it's not uncommon for clients to have five to 10 request inboxes. It's really up to you and what kind of use cases you'd like. Sometimes you may even have a client-specific email address. You may have a VIP client, and you can potentially use this as an upsell opportunity to say, oh, we're going to charge you $500, and you have a direct line to our admin team. And that could be just really through a request inbox, and as simple as that. So think about how creative, you know, you want to get, and different use cases. And feel free to send that over to bestpractices@accelo.com, or just support@accelo.com, and Tom and I or whoever else is on the queue that day, would be happy to take care of it.

Client Portal | Customize & Configure | Intermediate

Client Portal | Customize & Configure |…

•  Customize the look of the Client Portal
•  Invite and…

Best Practices for Better Invoicing

Best Practices for Better Invoicing

• Customize Invoice Template styling and Custom Fields
• Show Work…

Survival to Recovery: Taking Control Again

Survival to Recovery: Taking Control Again

This has been a year where most businesses have been…

Best Practices for Scheduling & Resourcing

Best Practices for Scheduling & Resourcing

• Take advantage of Auto-Scheduled Time
• Understand the Booking Tool
•…

Best Practices for Email Capture & Requests

Best Practices for Email Capture & Requests

• Email Capture Rules and Integration Settings
• Request Inbox…

Accelo uses cookies to give you the best possible experience - by clicking 'Continue' you agree to our use of cookies. Refer to our Privacy Policy for details. Continue