[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… Read More
[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 firstname.lastname@example.org. Versus a request inbox that I oversee is email@example.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, firstname.lastname@example.org, 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,…