What to expect when working with an outsourced IT support company


Businesses began outsourcing IT Support in the 1980s. Since then it’s an area that has grown and continued to dominate the service sourcing industry. It’s an important area to consider as IT has become such a core function of any business and does require a certain amount of financial investment. It is an area that is only going to grow in the future as technology drives business, almost regardless of the sector.

I’ll explain some of the reasons why businesses choose to outsource IT support, what that partnership can look like, and what to expect from them. 


Some of the top benefits of outsourcing: 


  • Broad technical expertise – inhouse IT support may give you specialised knowledge on systems only you work with. However, it can be limiting – a good outsourced IT helpdesk has wider expertise; different people with different areas of strength; always someone with the know-how to fix varying problems. 
  • Reduce operating costs – it’s generally more cost effective than hiring an inhouse IT helpdesk (for example minimum of 2 salaried members of staff – maybe more depending on size of company – vs a full team of technicians at the other end of the phone) 
  • Enable focus on core business – free up time to work on your business. 
  • Solve capacity issues – you do not have the resource to allocate purely to supporting your IT services. 
  • Enhance service quality – with inhouse they may not be held to any contracts or Service Level Agreements, and service not delivered to expectation. 


With more and more companies choosing to outsource IT support to an external provider, it’s important to understand what it’s like working with one. At pcr we serve over 100 clients, striving to work together with each of them, empowering them to achieve their business goals. Think of it like a partnership. 


What you should expect: 


Agreed Service Levels 

All outsourced IT support companies should have a Service Level Agreement (or SLA), which is a commitment between the service provider and the client.  At pcr we always have our initial response time included in an SLA, and these response times vary depending on the nature of the reported issue.  For example, if a case was logged by you was deemed as Business Critical for all your team, this would receive a quicker response time than your colleague who was reporting a standard request (I.e. install a new piece of software).  This seems simple, right?  So long as there is an understanding of how we prioritise our cases from the client’s side. 


Let’s take the example from your colleague – they are stressing that this software install is urgent, and needs done as soon as possible (but it is not impacting business).  If we marked this as critical, the first response time would be quicker. Imagine this colleague logged their case an hour before you logged your (legitimate) Business Critical case in which no member of staff can access files used to deliver for your own clients.  Your colleague’s case could be seen sooner, and thus impact your business further while you wait for your case to be seen. This is a crude example – but it demonstrates an important point. 


When checking requests made by our clients we will deem something as critical where no alternative option is available, and as a result this will cause damage to the business through missing key deadlines or stop delivery to a customer/consumer or partner.  We will always look to finding quick ways to keep you working that will reduce the critical nature – for instance the main printer is not working so the client is unable to print the urgent document; however, if the client can print to the secondary printer next door (to print the urgent document) then this immediately reduces the impact to business, and we can then work on the technical fix without the deadline looming. 


When it comes to prioritising cases, it’s important we get it right so that our clients get the right support where and when they need it, especially when dealing with multiple clients. 


Depth of knowledge 

An inhouse IT team may be experts in specific systems to your company, however throw something they’re not comfortable dealing with and you may find yourself waiting a very long time for a resolution. A good outsourced IT support company should have a wide bank of skills and expertise; if the first person you deal with doesn’t have the knowledge to fix your problem, there should be someone in the helpdesk that does. 


Some involvement in the case 

Our goal is to empower our clients to achieve their business goals, and that means involving our clients when troubleshooting and attempting to resolve issues.  We need to understand how you are affected or what you are trying to achieve – this could be the difference between simply fixing a technical issue, and getting you working the way you want.  


A chance to influence the service you receive 

While we may appear at times to don a cape and fly to the rescue at times of need we don’t claim to be superheroes – we are human, and sometimes we will make mistakes, or not quite get you where you need to be. That’s where our feedback loops come in. We always welcome client feedback, no matter how big or small, as it will help us to improve the service they get. Our team have channels to pass the feedback up the chain, but we also have a very helpful Client Services team – something businesses would not get with inhouse IT support. 
From prior experience working in a company who outsourced their IT I have seen this type of relationship from both sides. The more a client understands how the service works, and what to expect from them, the better the working partnership is with their IT company.  It’s why we’re always more than happy to talk to our clients if they need to understand better how we work with them. 

If you’re a company thinking about outsourcing your own IT or would like to know more about how we do things at pcr, please get in touch on the details below – we’d love to hear from you. 


26th July 2018
By Adam Reid

Leave a Reply

View by archive