Technical problem affecting your operations? Tell us about it

Consultancy / Escalation

Tier 3 escalation and advanced troubleshooting

For the problem your IT team or supplier has not been able to solve. We bring additional specialist expertise to difficult faults, work to find the cause and explain what we find clearly.

Engaged by
IT departments, suppliers and organisations without an IT team
Works
Alongside your team and suppliers
Response
No guaranteed response times

Start a conversation

On this page
  1. When organisations engage us
  2. Who this is for
  3. What helps us help you
  4. How we work
  5. What you receive
  6. What it is not
  7. Getting started
  8. Related articles

When organisations engage us

Tier 3 is the level of support where a problem has already passed through the first two: the service desk and the internal technical team or supplier. Organisations engage us when those teams meet an issue that needs additional expertise.

Typical situations:

  • Difficult network faults, such as intermittent drops, routing that behaves differently from one site to another or a VPN that works for some users only.
  • Authentication failures, where sign-in to the network, VPN or a service fails for some accounts or devices and the cause is not obvious.
  • Infrastructure performance problems, such as an application that is slow at certain times and no one can show why.
  • Complex cloud configuration issues, particularly where identity, networking and a hybrid connection interact.
  • Integration failures, where two systems exchange data most of the time and fail in a way that is hard to reproduce.
  • Persistent technical problems that have been fixed and returned more than once.

In plain terms

Tier 3

Support is often organised in tiers. Tier 1 is the service desk, Tier 2 is the technical team that handles harder faults, and Tier 3 is specialist expertise brought in for problems that are still unresolved.

Who this is for

  • IT departments that want a second pair of specialist eyes on a problem without changing how they run things.
  • Teams who work with suppliers and need an independent view alongside them.
  • Smaller organisations with no IT team whose supplier is out of ideas and who need an independent view.

What helps us help you

You do not need a perfect write-up. The more of this you can send, the faster we can get to the cause.

  • A timeline. When it started, how often it happens and whether it follows a pattern.
  • What changed. Updates, configuration changes, new equipment, a new supplier or a new user group around the time it began.
  • Logs and diagrams. Device and server logs, network diagrams and configuration exports, where you are able to share them.
  • What has been tried. Including what did not work, which is as useful as what did.
  • What it affects. Which users, sites or services are involved and which are not.

How we work

We work alongside your team and your suppliers, not around them. We work within the access permissions and change-control arrangements agreed with you. Where practical, investigations begin with logs, exports and read-only access. Any changes to live systems are discussed and authorised before they are made.

We trace faults by comparing configuration against the design, reading logs, checking what changed and, where the evidence is not otherwise visible, capturing traffic during a fault.

What you receive

  • The cause, explained where one can be found, in terms both your technical team and a non-specialist manager can follow.
  • A recommended fix, with the reasoning, and what to check afterwards.
  • A hand-over, where appropriate and agreed, of what we found and did, so the knowledge stays with you.

Findings, explanations and recommended fixes are documented where that is agreed in the scope; otherwise we take your team through them directly. We do not promise that every investigation will find a definitive cause: some faults have more than one, and a few cannot be fully explained. If that is the case we say so, and say what we ruled out.

Illustrative scenario, not a client project

A fault that comes and goes

  • Situation: An organisation’s remote users are intermittently unable to connect to a hosted application. The supplier and the internal team have each checked their own side and found nothing wrong.
  • Approach: We would ask for a timeline, the VPN and firewall logs and the authentication logs from the times of failure. We would compare working and failing sessions and look for the difference between them.
  • Typical result: A clear account of what the failing sessions had in common and, where a cause is found, the change that addresses it and the check to confirm it.

What it is not

Tier 3 escalation is not an emergency service, and it comes with no guaranteed availability or response times. The urgent option on the contact form flags your message so that it is clearly marked. It does not create a commitment to a particular response.

It is also not a replacement for your IT team or supplier. It is extra expertise for the cases that need it. Where you want ongoing support afterwards, that is agreed separately: see continuing support.

Getting started

If the problem is current, choose the urgent enquiry type on the contact form and include what you can from the list above. It is flagged, but not answered to a deadline. For planned work, such as an assessment before a change, use the project enquiry. More on how engagements are agreed is on consultancy: how we work. Related capability pages: network infrastructure, infrastructure engineering and Microsoft 365 and Azure.

Describe the problem

Send the timeline, what changed and what has been tried, and we will say plainly whether we can help.