All I can say is…. “Phew!”.

It’s been a super hectic past few months whilst we’ve been busy integrating Beetil into GoToAssist, and then transitioning all our customers over to the new platform!  The great news is that we’re now past all that stuff and getting back down to focussing on our roadmap.   We’re still here, that’s for sure, and have the same old team, plus a whole heap more awesome resources to tap into.

I do bear a teeny bit of sad news though – this will be our last Beetil blog post – the end of an era.  But that sparks the dawn of a new era, so you’ll all no doubt be chuffed to know that we’ll be posting plenty of goodness over on the GoToAssist blog, as well as the release notes.    We’ll also be bringing over some of the old goodie blog posts as well.

We’re all really amped about this year.  It’s gonna be a big one for us, which we hope means its gonna be a great one for you.

May this blog wish you all a fond farewell.

Love, the BeetilDudes.

The post The Beetil Blog Swansong appeared first on Beetil Blog.

Read the Citrix press release here.

Citrix is a great company known for its market-leading, cloud-based support product line, Citrix GoToAssist, and the addition of Beetil into its portfolio will provide a fantastic and seamlessly integrated set of cloud-based services for remote support, monitoring and service desk management.   We’re really excited to be part of this, and it’s going to be great for our customers.

We’re keen to ensure that existing customers aren’t at all affected by this acquisition and we’re happy to announce that all existing pricing of Beetil services will remain unchanged.   And we’re certainly not going to ease off on our development roadmap either.   In fact, the Beetil team will gain access to additional engineers, UX designers, QA resources, network operation centers around the world and so much more. Your service will transition into an even more powerful application in the future; since Citrix is well-known for delivering integrated solutions for IT professionals to support people and technology that are simple to use, offer great experiences, help businesses manage IT better, increase customer satisfaction and drive operational efficiency.

Over the past few weeks we have met some super smart people at Citrix, all that share the same passion as us.    It’s a great, positive sign for things to come and the team are looking forward to it immensely.

Kind Regards,

The Beetil Team (or to be more accurate, the Citrix Team).

The post Beetil has been acquired by Citrix! appeared first on Beetil Blog.

Strictly speaking something can be wrong/broken and not be a problem because it is not causing incidents (yet).  I like to call those Faults.   You can keep life simple (and your Beetil configuration simple) if you treat anything wrong/broken as a problem.

It is not uncommon to find an organization that doesn’t use problem records, only incidents.   This is a big mistake.  An incident record says that a user is unhappy.  If we get the user working again (say using a Workaround – see our Incident Management post) then the incident is over, though the problem may be still there.  An incident ends up getting used to track the problem, which usually takes longer.   This screws up our reporting, making it look like we have long-running incidents, like we are not looking after the users.

Incident Management and Problem Management are very different activities and need to be kept separate.  Not only does it make the incident reporting more accurate; keeping problems separate has other benefits:

• We can see our “portfolio” of problems: we give the overall situation visibility, so that we can prioritise what we fix, and work out how much resource we need.
• Incident and problem practices often have conflicting objectives.  For example rebooting a server will quickly fix a lot of incidents but it potentially destroys diagnostic information for resolving the underlying problem.  These conflicts should not be laid on one person to reconcile.  Different groups should make their case to higher management to resolve it when they conflict.

So use problem records.   We open problem records in several different situations:

• There is an incident and we can see there is an underlying technical cause (even if we don’t know exactly what yet, it is clearly not, say,  a user error or an administration mistake)
• We detect a pattern in incidents and start to suspect there is an underlying cause for them
• We see something is wrong/broken

If you want, you can be quite general about what you define as a problem.   For example, lots of user errors might show you there is a problem with the training.

Track all your problems (prioritise, work on them, follow up the slow ones), and record what you did about them, and close them off as you fix them or decide to live with them (if they are too hard or expensive to fix).

It is not the bosses’ job to solve problems.  Problems don’t get escalated.  The old manager’s mantra is “Bring me options not problems”.  Those doing operations know best how to fix problems.

In order to fix a problem (or an incident) you quite often have to do root cause analysis.  There are formal techniques you can use to do this.  Some argue that there is no single root cause of problems.  It generally takes several causes together to create a problem – they have to “line up” in some way.  The first and most obvious cause you find is seldom the end of the story: keep asking “why” until the answers are not useful.  Finding root cause is not necessarily about assigning blame – it is about removing cause.  Complex systems are in fact permanently broken, so when they actually fail it may be nobody’s fault.   On the other hand there could be negligence.

Once you are tracking and dealing with problems, the next level of maturity is to “kill the alligators before they bite you”: proactively seek out problems and fix them.  When you are really good you will forestall them and prevent them ever existing.  Find a keen, clever, energetic employee and assign them half a day per week to be an Alligator Killer: measure them on how many problems they find and eliminate.

Your register of problems in Beetil is closely linked to your register of risks and you may want to link them somehow.  An unfixed problem is one kind of risk: a risk that it will cause more interruptions to service.

The better you get at dealing with problems, the fewer incidents you will have .The other area that you can improve in order to reduce incidents is Change Management.  We’ll talk about that next.

The post Problem Management – Sensible Service Management appeared first on Beetil Blog.

Customer Unresponded > 8 hrs

Incidents that have been raised by a customer where it has been more than 8 hours and the support team is yet to respond. A healthy count for this queue is zero, and if anyone in the team sees the count ticking over to one or more they are quick to get this back to zero again. Introducing this queue has been the most effective thing we’ve done to reduce our response times.

Unassigned and New

While an incident may have been responded to it is not necessarily assigned to a team member or investigated enough to be set to a particular status. A healthy count for this queue is less than 5, ideally zero. If it starts creeping up it’s all hands on deck to get this down to a more manageable number.

In Progress

This queue is for incidents that are currently being investigated. As with the above queue if the count starts creeping up it’s all hands on deck to get this down to a more manageable number.

With Customer

When we’re waiting for more information from the customer we will set an incident’s status to ‘With Customer’ and it will appear in this queue. Seeing the count here is a good visual reminder of where things are at and stops incidents falling by the wayside.

To be Fixed

We take a sensible approach to providing workarounds or logging change requests in favour of automatically fixing every incident that comes in, but occasionally incidents will require an immediate fix. Incidents with a status of ‘To Be Fixed’ will appear in this queue and if the count starts creeping up it’s all hands on deck to get this down to a more manageable number.

Pending Release

These are incidents that have been fixed in the codebase and are awaiting release. Upon release we’ll get back to each customer, set the status to resolved, and close.

Remember you can create your own personal queues – something I personally take advantage of. In addition to the above queues I also have some personalised ones on my dashboard e.g. “Mine with customer” and “Mine to be fixed”. You can read more about setting up your own queues in our blog post ‘Dashboard Queues’.

As part of our continual service improvement we aim to frequently evaluate our support structure and processes and refine our dashboard queues accordingly. Spend the time on good service design, get everyone involved and you will be rewarded with a happy, efficient team and happy customers!

The post How we use queues to improve our service support appeared first on Beetil Blog.

You can also easily re-use content from knowledge articles and place it within the comment or resolution of an incident.

We’re already benefiting greatly from having problems and knowledge articles being suggested, and are hoping this encourages the re-use of documentation already stored in Beetil and improvements in our resolutions rates. As always, we’d love to hear your feedback. Drop us a line at support@beetil.com or log your thoughts and suggestions via Feedback in Beetil or via our Beetil Support portal

The post Improved suggested matches from Incidents appeared first on Beetil Blog.

In some schools of thought – me for instance – you can also have a Major Problem.  They are different paths to the same point: we respond in the same way.

The first time we have a Major Incident, that response is usually to panic.  Or at least a lot of turmoil ensues, as people rush about working out what to do and who should do it.  We get things fixed quicker and we keep our customers happier if we have planned how to deal with it: we need to think about Major Incident Management (MIM) before it happens.

To set the scope for MIM, this is something more than a high severity incident, where we give it highest priority and put our best people on it, yet we use the normal procedures to deal with it.  And it is something less than a total disaster, where our systems are wiped out and we have to go to our disaster recovery (DR) plan.  A Major Incident sits somewhere in between.  Sometimes a high severity incident turns in to a Major Incident, when we realise the impact is worse than we thought, or when it takes too long to fix and there is no sign of a resolution. And sometimes a Major Incident turns out to be so bad that we give up trying to deal with it and declare a disaster.  So they are on a ladder of increasing severity:

Notice that I refer to a DR plan, not a DR procedure.  In a disaster, we plan the things that need to be done.  For a rebuild of our systems we often define a series of steps that have to happen in a certain order, but there isn’t so much a procedure for dealing with a disaster (do this then this then this) as lists and policies.  We have lists of the systems we need to restore first, lists of contacts, and so on.  We have policy that sets the rules and bounds and trigger points.  But there is little point in trying to create a defined procedure because the circumstances of every disaster differ so much.  We are going to have to make it up to suit the situation.  The DR Plan helps us be as prepared as possible.

MIM sits somewhere in between a structured incident procedure and the guidance of a DR plan.  In a major incident we can say what the initial procedure will be but beyond that it will again vary depending on the circumstances, so we also need to have a MIM plan to provide as much guidance and information as possible.  The MIM plan should define the following:

Policy

Some organisations put a lot of effort into defining what constitutes a major incident.  It is futile to define the exact measures of one (more than 90% of this; three or more of those).  Trust me, the real world will invent a new crisis that is outside your definition yet clearly a Major Incident.  It is worthwhile defining guidelines or principles for recognising a Major Incident, but a Major Incident is like art: hard to define but you know it when you see it.  And like art, you need a human to recognise it.  So the key thing to define is not what a Major Incident is but who gets to declare one.  This should be equally broad: any manager above a certain level, say.    It must be easy to find a qualifying person in the heat of a crisis.

Other policy sets the principles we work by in addressing an incident, the goals, the rules and bounds, the responsibilities.

Roles

There is a Major Incident Manager role.  You need several designated people willing to take on this role on a crisis.  They may not be the same person as your day-to-day incident process manager.  Choose people who are natural leaders, strong communicators and good under pressure.

Other roles include a Communications Manager, to deal with internal and especially external communication; and a Resolution Manager who directs, understands and coordinates the technical people fixing the problem.  You need several designated people willing to take on those roles too.

Procedure

The first few steps in dealing with a Major Incident will be the same in almost all cases.  By having these defined, we bootstrap ourselves up to a state where we can start writing the rest of the procedure on the fly.  These steps are listed in a checklist at http://www.basicsm.com/declare-major-incident-or-problem

Once we have a Major Incident Manager in control of a centre of operations, we are in a situation to plan the next steps according to the situation, to hopefully resolve the incident.

Those steps will include some standard ones which should also be documented in the MIM Plan:

• The Major Incident Manager reconfirms that there is indeed a Major Incident
• The Communications Manager communicates the schedule and methodology for future updates to all parties
• The Communications Manager notifies all business owners of the service(s) and other stakeholders listed in the Communications Plan
• A Resolver Team or teams are assembled by the Resolution Manager.  The Resolver Teams agree to their communication schedules and protocols before getting to work.

Communication Plan

The Communication Plan should describe who needs to know what, how, and how often – from customers to non-involved internal staff.

It should describe what happens at certain points:

• Regular updates from the Resolution Manager to the Major Incident Manager.  Nobody else communicates with Resolver Teams except the resolution Manager.  Leave them alone to get the job done.
• Regular updates from the Communications Manager to stakeholders
• Meetings of the Major Incident Manager and Communications Manager with senior internal and customer management and other stakeholders

Center of Operations

The MIM Plan should describe how to set up and run a “war room” for the duration of the incident.

This includes looking after people: feeding them, and making sure there are rosters of staff so that they get some rest, especially the key people.  Therefore you need more than one person for each of the key roles.  After 12-18 hours under pressure, people are dangerous decision-makers.

If this MIM Plan seems like a lot, it won’t be when the day comes, as it most certainly will.  You will wish you had planned more.

One last point: rehearse this just as you rehearse fire drills.  Rehearse the initiation until the center of operations is up and running.  Rehearse the meetings with stakeholders.  And rehearse the root cause analysis and problem resolution.  We’ll talk about those last two next time when we look at Problem Management.
Some of the content in this article comes from the MIM checklists at http://www.basicsm.com/checklists.  You can use those checklists to help keep control in a crisis.  Braun Tacon http://majorincidenthandling.com/ contributed to the MIM checklists.

The post Dealing with Major Incidents – Sensible Service Management appeared first on Beetil Blog.

When you now ask for customer feedback the email they receive will contain unique addresses for each rating level (Excellent, Average, Poor) which when clicked on will take them directly to the incident’s feedback screen without needing to log in first. The rating they had clicked on will be preselected and they have the option to add comments, and optionally have the ability to log in to the portal to read the incident in full.

We hope that change reduces the barrier for customers entering feedback when your team resolves and closes an incident. As always, we’d love to hear your feedback. Drop us a line at support@beetil.com or log your thoughts and suggestions via Feedback in Beetil or via our Beetil Support portal

The post Log Feedback without having to log into the Portal appeared first on Beetil Blog.

To set this up go to Incidents > Reports & Queues > New Report / Queue and choose ‘Last Updated By’ from the report criteria selectbox (in the ‘people’ section towards the bottom of the list). Choose from any user, customer, assignee, or owner. If you are focusing on current incidents be sure to specify ‘open’ incidents and any other relevant criteria. Don’t forget to add the report as a queue to your dashboard when you save it so you always have visibility of this important incident state.

We hope that this proves to be a useful addition for all your support teams. As always we’d love to hear your feedback and suggestions. Drop us a line at support@beetil.com or log your thoughts and suggestions via Feedback in Beetil or via support.beetil.com/portal.

The post New Report Condition: Last Updated By appeared first on Beetil Blog.

Adding a test plan is easy – when creating a new change or release click the ‘Create a test plan and assign testers’ link to get the test plan field and tester settings. For existing changes and releases you can expand the ‘Test Plan & Assigned Testers’ section to view, edit or add your plan.

You don’t have to have a test plan and can start creating issues whenever you like. Testing issues now have unique IDs so your auditors will love you even more.

As always, we’d love to hear your feedback. Drop us a line at support@beetil.com or log your thoughts and suggestions via Feedback in Beetil or via our Beetil Support portal

The post Testing Plan for Changes and Releases appeared first on Beetil Blog.

In the previous blog post in this Sensible Service Management Series we looked at the core of servicing customers: managing Requests.

In Beetil, everything we respond to is called an Incident.  Let’s talk about incidents in the strictest sense of the word: dealing with things going wrong.

Everything we talked about last time regarding Requests still applies. We will add some more considerations now for when something needs to be fixed.   Recall we talked about three main capabilities:

1. Record

Provide a single point of contact with multiple channels to access it.  Make sure you keep a record of all requests as Incidents in Beetil. Record all interactions with your users. Track all your responses and record what you did about them.

2. Respond

Make sure someone owns every request. Build up information in the Beetil knowledgebase.  Use external information.  Provide scripts for how to deal with common requests. Use Beetil to pass requests to someone else.  Regularly monitor how long requests are taking and chase up the slow ones.

3. Report

Make sure you don’t drop the ball on any requests.  Look for trends to help you improve your service.

OK, so now let’s extend that.  Sometimes a user requests help with a service not working as expected: something needs to be fixed. That is an “incident” in the strictest use of the word.

Sometimes that “user” reporting an incident is an internal person picking up an error before it affects any of the “real” users consuming the service.  It can even be a software program detecting the error and automatically alerting us.

Elaborating on “Responding”

In any case, if something needs fixing we need to elaborate on the “2. Respond” part of our Request process we described last time.

Here is how we expand that part of the process:

2.1. Categorise

We didn’t talk much about this last time.   It helps to categorise all incidents, whether general requests or issues to be fixed, but it is particularly important when we are fixing stuff to get a general idea of what type of incident it is so that we can determine how serious it is, how wide and severe the impact is, and so that we pass it to the right person first time.

2.2. Diagnose

This is where keeping records of what we did in the past, and building up the knowledge base, really pay off.  Search Beetil’s Incident records, Problem records, and the Knowledgebase, to see if we know what the cause is and how to fix it.  If you get a match, fix it if you can or pass it to somebody who can. This is called Level 1 support.

If you don’t get a match or can’t fix it, pass it to Level 2 support: those who have the technical skills to do specialist diagnosis and resolution.  If they can’t fix things, they refer the incident to Level 3 support: the folk who built or supplied the stuff that is not working, often a supplier external to your organisation.

2.3. Escalate

All this passing around amongst support groups is called Functional Escalation, but when we talk of “escalating” we usually think of Hierarchal Escalation, i.e. telling somebody more senior.  We hierarchically escalate because:

• The incident impact is serious enough that they should know about it
• A fix can’t be found
• Someone is not responding fast or well enough considering the severity of the incident

That person might make a call that this is a Major Incident.  This means drop the normal process described here and switch to a crisis-response process that we will talk about in a future blog post.

2.4. Resolve

Somebody is not getting the service they expect.  The incident process must focus on restoring that service.  Sometimes that is not the same thing as fixing the underlying problem (fixing the Problem is a different process we will talk about some other time).  If we have to fix the problem in order to get the user back on track again we will, but sometimes there is a Workaround: a way to get them back up and running without fixing anything.  For example, with some software, simply logging off and on again may get them around an issue and working again.  Or rebooting a server may make the problem go away. (There is an old joke that “a problem gone is a problem solved”).

You can find Workarounds as part of Beetil’s Problem records, and/or you can also record Workarounds in the knowledgebase.

Eventually a Problem may cause so many Incidents that we have to hold the user up without a Workaround while we properly diagnose it and nail it once and for all.  That is a management call whether the inconvenience is outweighed by the ongoing cost of recurring incidents.  But in general the Incident process takes whatever Workarounds or temporary fixes it can to get service restored to the user as quickly as possible.

2.5. Close

This applies to all Incidents and Requests.  Before you close the ticket make sure:

• You tell the user it is done
• You make sure the user thinks so too: that they are happy with the outcome
• The Incident is properly categorised so our reporting data is useful.
• The Incident has a record of everything that happened and what workaround or fix you used.  In the future, you or one of your colleagues may be grateful you wrote it down.

ITIL confuses things by talking a lot about finding and fixing the underlying problem, and recovering the broken service, as part of the Incident process.  We will keep it clean by talking about all that as part of the Problem process (coming up in a future blog post).  Keep it nice and crisp:

• Incident process is about getting the user(s) working again as quickly as possible, however we manage that.
• Problem process is about fixing the underlying cause(s).

There is a huge body of knowledge out there about Incidents and Requests, which you can investigate further as you need to.  ITIL has a lot (in the version 3 book Service Operation and the Operational Support and Analysis intermediate course).  The Helpdesk Institute produce a lot of useful material too.  COBIT 5 is my choice for formal  definition of what should be happening and what should be produced, and by who.

For now, start with:

1. Record

2. Respond

2.1 Categorise

2.2 Diagnose

2.3 Escalate

2.4 Resolve

2.5 Close

3. Report

Want to read more sensible service management goodness?

• Responding to Requests
• Service Management Success: Delivering to Your Customers
• Better Process Can Be Better Business

The post Responding to Incidents – Sensible Service Management appeared first on Beetil Blog.