Mon–Fri, 8am–5pm · Brisbane time Gold Coast QLD, Australia
Callback usually the same business day
bcom ICT
HomeServicesIndustriesSupportPricingAbout Get a quote Call 07 3041 8993
Trust centre

How we actually run the service

Our service management is based on ITIL 4. Stripped of the jargon, that means eight things — and every one of them answers a question a client has already asked us.

bcom ICT runs service management practices based on ITIL 4, covering service desk, incident, request, problem and change management, service levels, configuration management and continual improvement. Ollie holds ITIL 4 Foundation certification. bcom ICT is not certified as an organisation against ITIL or ISO/IEC 20000-1.

Eight practices, and the question each one answers

Most providers put "ITIL-aligned" in the footer and leave it there. The reason it's worth more than that is that ITIL's practices map almost exactly onto the things clients worry about when choosing an IT provider — so here they are side by side.

PracticeWhat you're really askingHow it works here
Service deskWho do I call, and will a human answer?One number and one email address, answered 8am to 5pm Monday to Friday. Outside those hours our digital assistant takes the details and logs the job for the next business day. Every request is logged, so nothing depends on someone remembering a corridor conversation.
Incident managementSomething's broken. How fast do you come?Faults are prioritised P1 to P4 by business impact and worked to published response targets. Restoring service comes first; understanding why comes after, as a separate piece of work.
Service request managementHow do I get a new starter set up?Requests are handled separately from faults, because mixing them means the new laptop request competes with the server being down. Requests are scheduled; faults are responded to.
Problem managementWill you fix the cause, or keep charging me for the same fault?When a fault recurs, we open a problem record and chase the root cause. For managed clients that work is included — which is exactly the incentive difference between managed IT and break-fix.
Change enablementWill you break something and disappear?Changes that could disrupt your business are approved by you, scheduled, and have a documented backout plan before we start. High-risk work happens outside business hours.
Service level managementWhat have you actually committed to?Response targets are published rather than negotiated privately, and reviewed with managed clients at their service reviews.
Configuration managementWhat happens to our documentation if we leave?Every device, licence, credential and supplier is recorded in an asset register that belongs to you. You can request a copy at any time, not only on exit.
Continual improvementWill anyone ever think about our IT strategically?Managed clients get periodic service reviews covering what broke, what's ageing, what's coming out of support and what to budget for. IT that's only ever reactive gets expensive slowly.

Keep it simple and practical

That's one of ITIL 4's own guiding principles, and it's the one that matters most for a business with eight staff. The full framework describes machinery for organisations far larger than yours or ours. Running all of it at your scale would cost you money and buy you meetings.

So we run the parts that change outcomes:

  • Everything gets logged, so nothing lives only in someone's head
  • Faults get prioritised by business impact, not by who shouted loudest
  • Recurring problems get a root cause, not a repeat visit
  • Nothing disruptive changes without your approval and a way back
  • Your documentation is written down and belongs to you
  • Someone looks at the whole picture periodically, not just the last ticket

We run the same disciplines a large IT department runs. We just run them at a size that suits a business with eight staff, and we explain them in English.

Where this is written down

Practices that only exist in conversation aren't practices. These are the pages where ours are set out in a form you can hold us to:

  • Service levels — the P1 to P4 priority matrix, response targets, hours, escalation path and exit terms
  • Onboarding — what happens in the first 30 days, including the documentation we build and hand to you
  • Data handling — what we hold, where it lives and who can reach it

Ollie holds ITIL 4 Foundation certification. That is an individual credential — it does not make bcom ICT an ITIL-certified or ISO/IEC 20000-1-certified organisation, and we do not describe it that way.

Questions

What people actually ask about how we work

Six questions, including the one about whether any of this is worth the trouble.

“Isn’t this just process for its own sake?”

Usually a fair suspicion. Service management frameworks can become bureaucracy, and plenty of providers have made them exactly that.

What we do Judge it by what it prevents. Every practice we use exists because of a specific failure mode — changes made without a way back, faults fixed repeatedly without a cause being found, work nobody recorded. If a practice is not preventing something, it should go.

“We just want it fixed, not a process”

Usually entirely reasonable, and the two are not opposed. The process is what makes the fix stick.

What we do The visible part should be a fixed fault and a clear explanation. Incident, problem and change handling happen behind that, and if you are noticing the framework rather than the outcome, we are doing it wrong.

“What’s the difference between an incident and a problem?”

Usually a distinction that sounds like jargon and is the single most useful idea in the framework. An incident is the interruption; the problem is the underlying cause.

What we do Restore service first, then find the cause separately. Businesses that only ever handle incidents fix the same fault indefinitely, which is expensive and completely avoidable.

“Our last provider changed things without telling us”

Usually no change management. It is one of the most common complaints we hear about incoming clients’ previous arrangements.

What we do Changes that could disrupt your business get approved by you, scheduled, and given a documented way back before they start. No silent Friday-afternoon upgrades.

“Why does everything have to be written down?”

Usually because undocumented knowledge is a dependency on individuals. It works perfectly until somebody is on leave, unwell, or no longer with either business.

What we do Documentation is yours, not ours — asset register, network diagrams, licences, credentials and configuration notes, available on request at any time rather than only on the way out.

“Are you certified in ITIL?”

Usually a question worth answering precisely. Ollie holds ITIL 4 certification. bcom ICT as an organisation is not certified in anything, because ITIL certification applies to people rather than to companies.

What we do Credentials sit on the person who holds them. We publish whose they are, which lets you check rather than take it on trust.

In practice

What this looks like in practice

Representative engagements, drawn from real work with identifying detail removed — we don’t name clients without written permission.

Representative engagement

The fault that had been fixed eleven times

The situation

A business had a recurring problem with a shared system that failed every few weeks. Each occurrence was resolved promptly by their previous provider and billed. It had been going on for over a year.

What we found

Reviewing eleven separate tickets, each had been handled correctly as an incident — service restored, ticket closed, invoice raised. Nobody had ever opened a problem record to ask why it kept happening, because nobody was being paid to. The cause turned out to be a scheduled task that failed under a specific condition roughly monthly and consumed a shared resource on its way down.

What we did

Restored service as an incident, then investigated separately as a problem, found the failing task, and corrected it. Recorded the whole thing so the history exists if anything similar appears.

The outcome

It has not recurred. Eleven correct incident responses had produced eleven invoices and no progress, which is what happens when the distinction between an incident and a problem is not made.

Representative engagement

A change with a way back

The situation

A business needed a significant upgrade to a system its whole operation depended on. The previous attempt, made by another party two years earlier, had failed and taken the business offline for a day and a half.

What we found

The earlier attempt had been made on a Friday afternoon with no tested rollback and no agreed point at which to abandon it. When it went wrong, the only options were to keep going or to restore from a backup nobody had tested. That is what turned a failed upgrade into a day and a half.

What we did

Scheduled the work outside trading hours with a tested rollback in place, a verified restore, and an agreed cut-off time at which we would revert regardless of progress. Confirmed each step with the business before proceeding to the next.

The outcome

The upgrade completed inside the window and the rollback was never needed. Having it ready cost about two hours of preparation, which is the entire difference between the two attempts.

Common questions

Questions Gold Coast businesses ask us

Does bcom ICT follow ITIL?

bcom ICT's service management practices are based on ITIL 4, and Ollie holds ITIL 4 Foundation certification. bcom ICT is not certified as an organisation against ITIL or ISO/IEC 20000-1 — ITIL is a framework we work to, not a badge we've been audited for. Call 07 3041 8993.

Isn't ITIL overkill for a small business?

The full framework is, and we don't run it. ITIL 4's own guiding principle is 'keep it simple and practical', and that's the part we take seriously. What a small business actually needs from it is: requests get logged, faults get prioritised sensibly, recurring problems get chased, and nothing changes without warning. That's it. The rest is machinery for organisations far larger than yours or ours.

What's the difference between an incident and a request?

An incident is something broken — you had it, now you don't. A request is something new — a starter, a device, an access change. They're handled differently because they compete for the same people, and if they share a queue the new-laptop request will sit behind the outage or, worse, the other way around.

What is problem management, in plain terms?

Fixing incidents restores service. Problem management asks why it happened and stops it recurring. If your printer jams every Tuesday, incident management clears the jam each week and problem management finds out that a scheduled job is sending it a malformed file. Break-fix providers rarely do the second part, because they earn from the first.

How does change control work in practice?

For anything that could disrupt your business — a firewall change, a server update, a migration — we tell you what we're doing, agree a window, and have a way to reverse it before starting. Routine low-risk work like a patch on a single workstation doesn't need that ceremony, and pretending it does just slows everything down.

Do we get service reviews?

Managed clients do. They cover what broke and why, what's ageing or coming out of support, security posture, and what to budget for over the next twelve months. It's the difference between an IT provider and someone who answers the phone.

Want to see how this works on your systems?

The free review is where it starts — we look at what you're running and show you what we'd document, prioritise and fix first.

Last updated: August 2026 · Reviewed by the bcom ICT team