Choosing a managed IT support provider in Sydney: what to check before you sign

Put three managed IT support proposals side by side and they tend to read the same. Each promises a help desk, proactive monitoring and a named account manager. Most are priced per user per month, so the totals end up close together and price doesn’t separate them. The real differences are in the contract detail and in how the provider behaves once the sales team has handed you over.

This post is part of our Buying IT Services series. It covers what we would check if we were buying managed IT support in Sydney, in the order we would check it. At the end there is a one-page list of questions to put to every provider on your shortlist.

Pin down what “managed” covers

“Managed” has no fixed meaning. For one provider it means a help desk plus remote monitoring software. For another it means they are responsible for the day-to-day health of your whole environment. Before you compare prices, write down what you expect to be covered and ask each provider to mark every line in or out:

• Help desk: the hours of cover, and whether staff can log a ticket by phone as well as by email.
• Patching: whether it covers third-party applications or only the operating system.
• Monitoring: which devices and services are watched, and who acts on an alert at 2am.
• Backups: where the copies are kept, and when someone last tested a restore.
• Security: whether endpoint protection and MFA management are in scope, and whether they will report your position against the ASD Essential Eight.
• Vendor management: whether they will log and chase faults with your telco or line-of-business software vendor, or just give you the vendor’s phone number.

Most gaps between proposals turn up at the line between support and project work. Moving to a new Microsoft 365 tenant, fitting out a new office or replacing a firewall usually counts as a project and is billed separately. Get that line in writing, with examples on each side, before you compare monthly fees.

Read response and resolution separately

A response SLA and a resolution SLA measure different things. A 15-minute response can mean nothing more than an automated email confirming that a ticket exists. Have the provider define a response: is it a technician starting work on the problem, or an acknowledgement? Then check whether the contract commits to resolution targets at all, or only to response.

Priority definitions matter just as much. Have the provider explain in plain terms how they would rate your finance system going down two days before month end, and who decides that rating. If the provider sets priorities alone and the SLA clock depends on the priority, they control how their own performance is measured.

After-hours cover is the next thing to read closely. Check how the contract defines business hours, whether NSW public holidays are excluded, and the after-hours rate. If you have staff in Perth or people who regularly work late, a Sydney 8-to-6 window will leave some of them without cover.

Then ask for the escalation path. You want a named person to call when a ticket has stalled, and you should know whether that person is an engineer or an account manager. Find out what service credits apply when SLAs are missed, and whose ticketing data is used to measure the miss.

Ask who answers the phone

Ask to walk through the support process as a user would. When someone rings at 9am on a Monday with a locked account, who picks up? It could be an engineer in Sydney who can fix the problem, or a first-line team somewhere else that logs the ticket and passes it on. Both models exist. You need to know which one you are buying, and how many people will be involved before the problem gets to someone who can fix it.

Location affects more than call quality. If engineers outside Australia can reach your systems, you need to know where admin access comes from and where your data is viewed. That feeds into your own privacy obligations. Onsite support is a separate question. Some faults need someone in the room, so ask whether the provider can send an engineer to your office and what a visit costs.

PicNet has been a Sydney business since 2001. Every one of our managers is an engineer, so when a client escalates a ticket, the person who takes the call can read the logs.

Check the reporting before you need it

Get a redacted sample of a real monthly report before you sign. A useful report shows SLA performance against the contract, patch compliance, backup failures and open risks, as well as ticket volumes. A report with nothing but ticket counts tells you the provider is busy. It doesn’t tell you whether your environment is getting healthier.

Recurring problems are worth asking about by name. If the same printer or VPN fault comes up every month, the report should say so and someone should be finding the cause. Under per-ticket billing, the provider makes money from the fault coming back, so look for evidence in the sample that they track root causes.

Agree on how often you will review the report and who attends. A quarterly meeting with an engineer who knows your environment will surface more than a monthly PDF that nobody opens.

Plan the exit before you sign

Onboarding shows you how a provider works. A careful provider will spend the first weeks on discovery, writing down your network, accounts, licences, backups and vendor contacts. Find out how long onboarding takes and what documentation you will have at the end of it.

That documentation should belong to you, and the contract should say so. It should be stored somewhere you can reach without asking the provider, such as your own SharePoint or a documentation platform you can export from. The same applies to credentials. Global admin accounts in Microsoft 365 and on your firewall should be in your organisation’s name. The provider should hold delegated access that you can revoke.

Licensing can tie you in without anyone noticing. If your Microsoft 365 licences are bought through the provider’s reseller agreement, find out how they transfer to a new provider and how long that takes. Domain names and DNS hosting should also be registered to you.

Finally, read the exit clause. Look at the notice period, any termination fees, how much handover help is included and the format your documentation will be handed over in. A provider confident in its service will usually agree to reasonable exit terms. If they won’t, that tells you something before you have signed anything.

The one-page checklist

Put the same questions to every provider on your shortlist and compare the written answers.

1. Which of help desk, patching, monitoring, backups, security and vendor management are included, and which are billed as extras?
2. Where does support end and project work begin? Give examples of each.
3. What counts as a response, and do you commit to resolution times?
4. How are priorities defined, and who decides a ticket’s priority?
5. What hours are covered, and what does after-hours work cost?
6. Who do we escalate to when a ticket stalls, and is that person an engineer?
7. Who answers the phone, and where are your engineers based?
8. Can you send an engineer onsite in Sydney, and what does a visit cost?
9. Where are our systems administered from, and whose name are the admin accounts in?
10. Do any of your tools send our data to third-party or AI services?
11. Can we see a redacted sample of a monthly report?
12. How often will we review service together, and who attends from your side?
13. What does onboarding involve, and what documentation will we have at the end?
14. Who owns the documentation and licences, and where are they held?
15. What notice period, exit fees and handover help apply if we leave?

PicNet builds production AI systems for Australian organisations and runs managed IT support for Sydney clients. If you’re also thinking about AI, talk to us about what a first project could look like.