When to Hire an Incident Communication Consultant - And When Not To

When Hiring an Incident Communication Consultant Makes Sense - And When It Doesn't

I want to do something that most people in my position don't do.

I want to tell you honestly when hiring someone like us makes sense - and when it doesn't.

Not because I'm indifferent to whether you become a client. But because I believe my job is to act as your advocate - your most trusted advisor in this space - and that means telling you the truth about your situation regardless of whether it leads to a sale.

I have spent more than twenty years in IT operations watching companies make purchasing decisions that weren't right for their situation. Buying tools before they had a process for serving them. Bringing in consultants before they had addressed the infrastructure problem, the consultant couldn't fix. Investing in training before the culture was ready to use what training would produce.

I have no interest in being part of that pattern. A client who wasn't ready for the engagement, or didn't need it, or needed something different - that's not a good outcome for anyone. Least of all for them.

So let me be direct.

A Word About Tools First

Before I talk about when to hire a consultant, I want to address something that often comes up before that conversation.

Many organisations discover they have an incident management problem and immediately begin evaluating tools - PagerDuty, Opsgenie, AlertOps, xMatters. They demo platforms. They compare pricing. They read comparison articles. This feels productive. It produces spreadsheets, vendor meetings, and a decision timeline.

What it often doesn't produce is a better incident response. Because the tools - excellent as many of them are - solve a specific problem. They alert faster, route escalations more reliably, and track incident timelines more accurately. They don't solve the process problem. They don't define who owns communication during a live incident. They don't write the client update. They don't determine whether the post-mortem loop actually closes.

If you're considering a new incident management tool, I'd encourage you to do one thing first: understand your process well enough to know what you need the tool to serve. Not the other way around. The tool is downstream of the process. Always.

That's not an argument against tools. It's an argument for approaching them in the right order.

When It Genuinely Makes Sense to Bring In External Support

There are specific situations where bringing in external support for incident communication and process makes a real difference - where the return on the investment is clear and the alternative is materially worse.

You've had a significant incident, and the aftermath revealed gaps you don't know how to close. This is the most common starting point. Something went wrong - badly enough that the board noticed, or a client relationship was damaged, or the team's confidence took a hit. The post-mortem identified problems, but nobody is sure how to address them structurally. In this situation, external input has a specific job: translate the post-mortem findings into a process that actually works under pressure.

Your team is scaling faster than your incident process. You went from ten engineers to thirty-five in eighteen months. The informal coordination that worked with ten people is breaking down with thirty-five. Incidents are taking longer. Communication is fragmenting. This is a structural problem that requires a structural solution - much easier to build during growth than to retrofit after a major incident reveals the gap.

Your leadership team cannot answer basic incident readiness questions. Can your team run a P1 end-to-end without you personally involved? Do you have a documented escalation path that your team has actually used? Does your on-call team know what to say to a client in the first fifteen minutes of a major incident? If the honest answer is no, or I'm not sure, the gap is real, and it has a cost that accumulates quietly in the background.

You operate in a regulated environment where incident response documentation is a compliance requirement. GDPR, FCA, NIS2, DSPT - all of these impose requirements around incident response that go beyond having tools in place. If your documented process wouldn't survive an audit, and you know it, that's a specific and time-bounded risk worth addressing directly.

When It Probably Doesn't Make Sense

I told you I'd be honest. Here's the other side.

If you've never had a significant incident, and your team is small and tightly coordinated. A five-person engineering team where everyone knows the systems and incidents resolve quickly - you probably don't need a formal incident communication process yet. Invest in it when you're growing, not before you need it.

If the real problem is your infrastructure, not your process. Incident communication support is not a substitute for addressing fundamental technical debt. If your systems generate incidents weekly due to architectural problems, fix the source first. Then build the process that handles the ones that remain.

If you haven't yet defined what you need from a tool - or bought one hoping it would define your process for you. If you're mid-way through a tool evaluation and you're not yet clear on your escalation paths, severity levels, or communication ownership - stop the evaluation. Define the process. Then revisit which tool actually serves it.

If you're looking for a one-time document and nothing more. A playbook that sits in a folder and is never practised is not worth the investment. Behaviour change is the outcome, not the document. If your organisation isn't ready to commit to implementing what gets built, the timing isn't right yet.

If the budget is the genuine constraint right now. There are things you can do yourself - I've written a practical guide to building the core of an incident playbook without external support. Start there. If you hit the ceiling of what you can build internally, you'll know exactly what you need next.

The Question Worth Sitting With

Before deciding whether to engage any external support - mine or anyone else's - I'd encourage you to ask one question.

What is the cost of the current situation, honestly measured?

Not just the last incident. The accumulated cost of the pattern. Recurring incidents, communication failures, engineer time on firefighting, client relationships that are less solid than they were, leadership attention diverted from strategic work.

If that number is significant - and in most organisations of 15 to 200 people that have a genuine incident management problem, it is - then the investment case is straightforward.

And if you're not sure what the number is - that uncertainty is itself a reason to do the honest calculation before the next incident forces it on you.

Frequently Asked Questions

What does an incident communication consultant actually do?

An incident communication consultant helps organisations build the human and process layer around their incident response - defining roles, creating communication templates, establishing escalation paths, designing post-mortem processes, and running simulations. Critically, this work is done before tool selection, not after - so any tools chosen are selected to serve a defined process rather than to replace the need for one.

Should I sort out my incident process before evaluating incident management tools?

Yes. Tools like PagerDuty, Opsgenie, and AlertOps are most effective when they serve a defined process - clear severity levels, documented escalation paths, named communication roles. Without that process clarity, tool selection is based on feature comparison rather than operational fit. Define the process first. Then choose the tool that serves it.

How do I know if my incident process needs external help?

Ask three questions: Has a recent incident damaged a client relationship or revealed gaps you don't know how to close? Is your team growing faster than your incident coordination? Can your team run a P1 end-to-end without any single person? If any answer is no or unclear, there is likely a gap worth addressing.

What's the difference between an IT consultant and an incident communication consultant?

A general IT consultant typically focuses on technical infrastructure, architecture, or systems. An incident communication consultant focuses on the human and process layer - roles, communication, escalation, stakeholder management - that determines how well an organisation handles incidents regardless of their technical capability or tooling.

How much does incident communication consulting cost for a small business?

Engagements vary depending on scope. An incident playbook build typically ranges from £2,500 to £5,000. Training and workshop programmes from £1,500 to £2,500. Monthly retainer support from £1,500 to £3,000. Emergency response support at £250-£500 per hour.