Resolve by FAQ - Service requests

[Lyonel]

Hi,

I have a question regarding a recent functionality in Service Manager: 

 

This is really cool!

My question: does it only work with Incidents?

Am I missing something? A setting somewhere maybe?

If not, is there any particular reason why we cannot use it against Service Requests? It would be incredibly useful for us if we could...

Thanks!

 

[Steven Boardman]

Hi @Lyonel please you like it

It has been introduced in Incidents as this was seen as the most natural place for it, in terms of having knowledge available to help you resolve the issue and return to BAU, so it sits there alongside the workarounds from linked Problems, as possible solutions which you can use to resolve your Incident. 

In regards to Service Requests we have had various requests to have the ability to link documents to say a New Starter Service Request with the steps which need to be followed, and this is now possible through the Document Manager action bar icon on all request types. 

In addition we have just added a new iBridge option which allows you to automate the adding of specific documents from within your business process - so using the same example above, you can always add the relevant New Starter Guide document to the New Starter Service Requests

 

And the new iBridge option under the Integration call in your process designer

There is more discussion here on this and an example config for the above:

 

[Lyonel]

@Steven Boardman thanks for the additional info.

However it does not really answer my question... We would like to resolve a Service Request by using a FAQ (just like you would with an Incident). Is that not possible at all? If so, is there any particular reason?

Documents are OK, but we need to use FAQs so that our end users get used to the service portal. No need for a full document... A simple FAQ does the trick.

[Steven Boardman]

@Lyonel FAQ's are only available to resolve Incidents currently

In regards to Service Requests, FAQ's and your end users.  The new functionality which has been introduced for using an FAQ to resolve an Incident is restricted to the Agents, not visible to end users on the service portal.   Any FAQ content in the resolution details of an Incident will be visible to them.

Obviously end users can still use FAQ's to solve their issues before logging a request of any sort. 

The same would then be true once a Service Request is raised, even if the option for FAQ's was enabled for Service Requests the end user would not see an FAQ linked to their Service Request from the service portal just the FAQ content in the SR resolution details.

We do see the FAQ's on Incidents as being an enabler to resolve the Incident, and in regards to Service Requests we see agents perhaps needing guidance and process to follow to onboard a new starter, give them access to a system etc hence the suggestion of the document approach.

We are also finishing off another knowledge story which will allow ens users on the service portal to be pro-actively presented with FAQ's and other knowledge inside progressive capture to allow them to self help and prevent the need to raise Incidents, Service Requests in the first place - this will be out shortly and will be in the form of a Knowledge centre

All of that said, if there is a desire and support from customers to extend functionality into other areas or provide a solution which provides the same end result.   

Could you provide some examples of where you could see this benefiting the different types of Service Requests you process?

Thanks

Steve

[Lyonel]

@Steven Boardman the new development sounds promising!

In our case, we could use the same functionality for Service Request when it comes to "access request" to a system. Some of our systems have access control managed by business users (e.g. NOT I.T people) and we do not deal with that. But our dear users just don't care... So we want to log the request (as a Service Request) and then close it pretty much instantly using an existing FAQ.

We could also use it a lot for "training" end users with recurring questions (for example: how can I change my telephone number in my email signature?). Indeed, for most of them we have a FAQ available.

Bottom line is what you did with Incidents is really good! So why not expand it to Service Requests too?

[Steven Boardman]

@Lyonel so on SR's it is more the case that you want to be able to resolve question type service requests by including a link to an existing FAQ in the resolution of the SR?

Something like:

You can change your telephone number in your email signature by following the instructions in this FAQ (Link) 

Hopefully the embedded knowledge will prevent a percentage of these even raising a service request but i see what you are looking to do, i'll raise this internally and post back updates.

Thansks

Steve

[Lyonel]

@Steven Boardman yes exactly!

HOWEVER do not underestimate the love of users for emails... I mean, despite our best efforts, this is the history of calls per source type:

In average, 72.25% of the calls are logged by emails. Another 18.92% is raised directly by analysts (most of the time on behalf of users). So we are talking about  90 % of our calls logged by IT staff rather than users themselves. 8.74% of calls in average are logged via the self service portal.

No matter how clever your system is, if the user does not go onto the service portal, we still have to log the request... Hence why such feature on Service Request as well as Incidents would be incredibly useful

Edited January 17, 2018 by Lyonel

[Gerry]

Its been my experience that if you remove email as a channel for logging support requests, users will go to a portal instead.  The problem with email is exactly what you say, users like it because its easy for "them" but if you force the issue it is almost always ultimately better for both the customer and the service desk to work in the portal.  I think its a leadership challenge as much as it is a product/feature challenge

Gerry

[Lyonel]

@Gerry there is no way to force them to use the portal unfortunately... So we will always have the "email" problem. I think you will find the same problem in many private companies that are in the manufacturing industry, where our customers are actually people working for that company.

 

[Gerry]

If email was down for two days what would happen?  Anyone that can send email would reasonably have access to a browser, even if thats on their phone.  In my experience, there is always a way of forcing a transition from email to a self-service portal, your organisation just needs the conviction to do it. 

I wont profess to understand the organisational or political dynamics of each organisation but there is certainly no technical reason in todays world not to abandon email in favour of a portal/self-service, thats a choice each organisation makes (or not)

Gerry

[Patrick Bolger]

People have a status quo bias, and don't like change. The problem with most efforts to deploy self-service, is that they're driven by IT, with the intention of reducing costs, rather than being driven (with the customer) to improve the service experience. 

Some of the best deployments I've seen have involved feedback from customers/users from start to finish.  They focus on what the customer/user wants to do and see via the portal (FAQ's, Knowledge, videos etc). Customers usually want a simple way to say "Something's broken", or "I need something" and be able to see what's happening with their requests. 

The experience should be better and quicker than email. However, regardless of how good it is, you'll still need to promote the portal and an easy way to do this is with a soft launch. Get service desk staff to say "Did you know you could have logged this via self-service?" After a while, they can say..."Is there any reason you have not logged this via self-service?" The message will need to be consistently reinforced. 

At the same time, the "What's in it for me?" messages need to be marketed to users, e.g. Self-Service is open when we're closed, You can access popular FAQ's 24/7, etc. Although I accept that each industry is different, people are generally the same, and will use any channel that's easy to use, and delivers the best experience.  Changing their current habits isn't easy, but it's worth it for both the customer and the service desk.        

[Lyonel]

@Gerry, @Patrick Bolger I do not disagree with any of what you said! And I wish we could stop emails altogether but it will never happen in my company.

So, given a bad situation, I am trying my best to use Hornbill and convince users to log calls themselves, go onto the service portal, provide feedback, etc.

Having the option to resolve a Service Request with a FAQ entry would considerably enhance this communication strategy (my only option here as I can't remove emails at all) as it would literally force the user to realise the information was already available to him/her.

Of course, the template for emails is extremely helpful for this communication strategy and I am planning on a new "marketing campaign" to promote the service portal.

@Gerry if emails were down for 2 days, most people in the IT department would get the sack! that's why we moved to Office 365, so that it does not happen (or if it does, not really anything we can do about it). Joking aside, if emails were down for more than a couple hours, it would be "the end of the world" for top management (and almost "holidays" for everybody else as we could actually focus on our jobs instead of emails)

[Gerry]

@Lyonel

lol "if emails were down for 2 days, most people in the IT department would get the sack! that's why we moved to Office 365" 

I hear your pain, not every organisation is quite ready to let go of their beloved email treasure

I will let one of our SM product team pick up on the FAQ requirement and respond with something that does not include get rid of email... thanks for the clarification

Gerry

[Dan Munns]

We use the old 'for audit purposes' to make users log tickets via the portal. 

"For audit purposes all Service Requests need to be logged via the portal, so that all relevant information is captured and logged correctly against the ticket"

In fact the only ticket type will accept via email is an incident and unless it is a password reset (which most are) even then it is done grudgingly. All of our 'New Ticket Logged' email templates say 'ticket updates will be provided via the Support Portal, available here <LINK>' to get users used to going there in the first instance.

We put bulletins for new services a couple of weeks before they actually go live and a lot of work has gone (is going?) into pushing the portal as the best thing for the user since dress down Fridays. 

Our results have been promising to far.

 

That being said having the ability to resolve a service request with an FAQ would benefit us from another angle.

• User is added to shared mailbox and FAQ instructions on how to add said mailbox is included in the resolution.
• User logs a request to have an address added to the spam filter and FAQ on adding email to users spam filter included in resolution. 
• User logs a request to have a network location mapped, FAQ included in resolution

These are just a few examples of where the SR FAQ resolution would be a great help to us as well. 

 

[Lyonel]

@Dan Munns the percentage of Email is quite impressive I have to admit! 

Just out of interest, why do you have such big chunk under "Analyst"? Is that because the customer phones?

[Dan Munns]

@Lyonel yes the analysts chunk is mainly password resets for NT accounts.

If a user calls to log an SR over the phone though they get told they HAVE to use the portal. 

The above chart is over a 6 month period from July to Dec 2017. Looking at our monthly stats almost (sometimes over) half of all our calls are password resets taken over the phone 

The amount of email logged calls should drop even further as quite a lot of those above were logged from monitoring sources and we have a project to determine which emails are useful (ie warrant a ticket) so we can auto log them and get rid of the rest.  

[Gerry]

@Dan Munns

"a lot of work has gone (is going?) into pushing the portal as the best thing for the user since dress down Fridays"  superb... I think you have it spot on, any business justification (such as for audit purposed) that gets your users on the portal will ultimately be better for your customers and you, frees your team up to deliver higher value work.   Email is the devil when it comes to sucking up time for IT ... its always easier for people who want help from IT, just fire an email and make their problem IT's problem, but allowing that cuts off every possible avenue you have as a service provider to improve the service you deliver - kudos for getting those numbers. 

You also said, "The above chart is over a 6 month period from July to Dec 2017. Looking at our monthly stats almost (sometimes over) half of all our calls are password resets taken over the phone "  so how can we help you automate that, it would be a big win for you guys if we can right?

Gerry

[Steven Boardman]

@Lyonel just an update on FAQ's in Service Request's, this has now been added and will be available in an Service Manager update in the coming weeks (it missed the cut off for the next update, but will be available shortly).

[Dan Munns]

@Gerry one issue we have is that there is no way for users to log a password reset for their NT account as we use SSO and they are obviously unable to access a machine.

I think that the password thing I will just have to live with a trying to stop a user calling to reset a password will be an impossible feat I fear. They 'need access now' so calling is a guaranteed way of getting them signed in. 

I have added a password reset service for all other password types (with little take up)

As you can see in the chart, the dark section (call logged via analyst) is a great deal larger than the lighter (self service) option.

Although over the same 6 month period as above NT account password resets only accounted for 33% of all password resets, the need to be logged on to any given system as soon as possible seems to force users into calling the desk.  

[Gerry]

Hi Dan,

I understand the thing about SSO but there is still a lot that can be achieved with a mobile smartphone or IVR, fully automated this means your users will have access "right now" 24x7 and of course you could eliminate taking calls for this completely.  

One example would be they call your service desk and are prompted with a voice response, press 1 for Password Reset type thing.  In there they could be asked for a PIN number (basically a secondary security question) and on the back of that they could be "text messaged" a temporary password which when logging in they would have to change their password.  https://www.twilio.com/use-cases/contact-center/ivr/build

Another possibility along the same sort of lines would be a mobile app that uses the identity of their mobile phone coupled with a security question such as a PIN number to effect an automated NT password reset. 

There are lots of ways of automating it I believe. 

Gerry

[Dan Munns]

Thanks @Gerry

I might take a look at the IVR solution. 

The issue we will have is that not all of our users have mobiles and personal devices are not allowed on the floors.

I will speak to our telecoms guys and see if there is a way of only presenting users with mobile numbers in AD with the IVR option to reset a password. 

Out of interest, what IVR systems can you currently integrate with?  

[Gerry]

Dan,

Anything that has some form of Web API. Twillo is a good platform for this sort of stuff and we have integrations in iBridge built for that already.  Your own internal phone system may well have IVR capability so worth a look for sure but in my experience the "telephone system provided IVR;s" tend to be over-complicated and outrageously expensive with feature keys required for almost every single feature.  Modern VOIP/Communications platforms like Twillo buck this trend and make way for innovation.  (I do not work for, or have shares in Twillow - just saying)

Gerry

[Dan Munns]

@Gerry we have an IVR system already, just wondered what you had dedicated integrations for. 

I will speak to the guys my end and see if it is possible with what we have already.

Thanks again. 

[Gerry]

Hi Dan,

Twillow I know for sure, not sure about others, I think we have a couple in iBridge.  Let me know what IVR you are using and we can take a look and see whats possible. 

Gerry