The First 30 Days of Co-Managed IT: A Melbourne Onboarding Playbook

Week 1 of a co-managed IT engagement is mostly listening, counting and writing things down. We audit the environment, capture credentials, transfer documentation from your internal IT person, and get a RACI matrix signed. No big changes, no tool rollouts. The goal is a true picture of what you actually have, not what the last vendor said you had.

That paragraph is the short answer. The rest of this piece is the long one — a week-by-week playbook of what the first 30 days of co-managed IT onboarding should look like for a Melbourne SME, what goes wrong, and how to tell whether your new partner is doing it properly or just collecting a monthly fee.

We’ve run this onboarding sequence dozens of times at TechAssist since 2014, mostly for businesses between 30 and 200 staff across Melbourne. The pattern below is what we’ve settled on after enough painful lessons to know which corners can’t be cut. If your engagement is starting next month, print this out and use it as a checklist against whatever your MSP proposes.

What co-managed IT onboarding actually is (and isn’t)

Quick definition so we’re aligned. Co-managed IT means your internal IT person or small team keeps running day-to-day, and an external MSP plugs in to handle specific gaps — usually 24/7 monitoring, after-hours support, escalations, project capacity, and the unsexy compliance and documentation work. It’s not full outsourcing. It’s not staff augmentation. If you’re not sure which model suits you, our co-managed vs managed vs internal IT comparison breaks down the differences in plain terms.

Onboarding is the bridge between signing the contract and the partnership actually working. Done well, it takes four weeks and ends with both teams operating as one. Done badly, it stretches to six months and never really finishes — the MSP is firefighting tickets they don’t understand because nobody documented anything, and your internal lead is quietly furious because they’ve been answering the same questions for ninety days.

The thirty-day target isn’t arbitrary. After 30 days you should be at steady-state: tickets flowing, monitoring green, runbooks written, the first quarterly business review (QBR) scheduled. If you’re not there by day 30, something has gone wrong upstream — usually in week 1.

The 30-day playbook at a glance

That’s the skeleton. Now the meat.

Week 1: Discovery and scoping

The opening week is unglamorous and easy to skip. Don’t skip it. Everything that follows depends on what you find in the first five working days.

The environment audit

On day one we walk the environment with your internal IT lead. Not remotely. In person where possible, even if it’s a half-day in a Hawthorn office. We want to see the comms cabinet, count the switches, photograph the UPS labels, find the cabling that runs through the ceiling void that nobody documented. Remote-only audits miss the patch panel that’s held together with cable ties and hope.

The deliverable from the audit is a written inventory covering:

• Every server (physical and virtual), with OS, role, owner and last-patched date
• Every endpoint count by device class, broken down by warranty status
• Network gear — firewalls, switches, APs — with firmware versions and support contract end dates
• SaaS tenants — Microsoft 365, Google Workspace, line-of-business apps — with licence counts and admin accounts
• Backup targets, retention policies, last verified restore date
• Internet links, static IPs, DNS hosting and where the domain registrar sits

If your MSP doesn’t ask for the last verified restore date, that’s a red flag. Backups that haven’t been tested aren’t backups. They’re hope.

Credentials capture

This is where most onboardings stall. Your internal IT person — let’s call him Dave — has accumulated passwords over four years. Some are in a KeePass vault, some are in his head, some are on a Post-it under his keyboard, and a few belong to a previous employee whose Microsoft 365 account technically still has Global Admin.

The MSP needs everything moved into a shared, audited password vault before week 2. Not Dave’s personal KeePass. A vault both teams can access with role-based permissions and full audit logging. We use a hosted IT documentation platform with credential management built in; your MSP will have their own. The point is shared, audited, encrypted.

Here’s what often goes wrong: Dave doesn’t want to share the passwords. Sometimes it’s protective — he’s worried about his job. Sometimes it’s just years of muscle memory around being the sole custodian. Either way, it has to be addressed by the business owner directly. The MSP can’t force it. We’ve had week 1 stretch to three weeks because a single internal lead wouldn’t hand over the firewall admin password, and the whole project sat there idling.

The fix is a frank conversation, framed around resilience. If Dave gets hit by a tram on the Lygon Street tracks tomorrow, the business needs to keep running. Co-managed IT is the insurance policy, not the replacement.

Documentation transfer

Whatever Dave has — Visio diagrams, OneNote pages, a folder of Word docs called “IT Stuff” — it all gets transferred and reviewed. Most of it will be out of date. That’s fine. We’re not auditing Dave’s documentation hygiene; we’re capturing institutional knowledge before it walks out the door.

Things we look for that are nearly always missing:

• Network diagram showing actual VLAN topology, not the one from 2019
• List of which line-of-business app talks to which database, on which server, on which port
• Vendor contacts with account numbers — internet provider, hardware supplier, line-of-business software vendors
• Recurring scheduled tasks (the script that runs every Sunday night that nobody understands)
• The actual office Wi-Fi password

RACI matrix sign-off

The most important week 1 deliverable, and the one businesses skip most often. A RACI matrix lists every category of work — patching, user onboarding, after-hours P1 response, M365 licence changes, backup verification, project work, vendor liaison — and for each one assigns Responsible, Accountable, Consulted and Informed roles between you and the MSP.

Without it, scope creep starts on day 8. We had a Box Hill manufacturing client where week 2 turned into a “could you just have a look at this” parade because nobody had written down who owned what. Their internal IT lead burned out within six months and we had to renegotiate the agreement. A signed RACI in week 1 would have prevented all of it.

A good RACI is boring. Three pages of “MSP responsible, internal IT consulted” rows. If it’s exciting, something’s wrong.

Week 2: Tooling rollout

With the audit complete and the RACI signed, week 2 is when the MSP’s tooling goes in. This is the visible part of onboarding and the part most clients judge us on. It’s important, but it’s only the middle act.

RMM deployment

Remote Monitoring and Management agents go on every server and endpoint. The deployment itself is straightforward — a GPO push or Intune deployment, depending on your environment. The harder part is the post-deployment tuning. Out of the box, every RMM screams about everything. By end of week 2 it should be tuned to your environment: warnings on the things that actually matter, silence on the things that don’t.

Ask your MSP what their first-week alert volume looks like. If they tell you “five hundred alerts a day, we’ll tune it later” — that’s a tooling team that doesn’t tune. If they tell you “we expect noise for 48 hours then it should drop below 30 actionable alerts a day” — that’s a team that knows what they’re doing.

EDR rollout

Endpoint Detection and Response goes on the same agents. We typically run in monitoring-only mode for the first week, then flip to blocking once we’ve baselined what’s normal in your environment. The Camberwell legal firm we onboarded last spring had a custom internal app that EDR initially flagged as malware. Two days of monitoring told us it was legitimate, we wrote an exclusion, and we never heard from it again. Had we gone straight to blocking on day one, their fee earners would have been locked out of their case management system.

EDR also needs to be connected to a 24/7 monitoring centre. Detection without response is just a noisier RMM. Our NOC at Tecoma watches EDR alerts for every client around the clock, with a sub-15-minute target response on P1 incidents. If your MSP doesn’t operate (or contract to) a true 24/7 NOC, you don’t have 24/7 cover regardless of what the SLA document says.

Backup monitoring

Your existing backup solution — whatever it is — gets connected to monitoring. We don’t usually rip and replace backup tooling in week 2; that’s a project for month two or three. Week 2 is about visibility. Are jobs running? Are they completing? When was the last successful restore test?

One of our Ringwood clients arrived with backups that had been “running fine” for two years according to their previous vendor. First week of monitoring revealed three of seven jobs had been silently failing since the previous Christmas. The vendor had been ignoring the alert emails. This is exactly the kind of thing co-managed IT catches in week 2.

NOC enrolment

By Friday of week 2, your environment is enrolled in the MSP’s NOC. That means 24/7 eyes on monitoring, with documented escalation paths back into business hours support. Test it. Genuinely. Pick a Saturday morning, simulate a server going offline, see what happens. If you don’t get a phone call within fifteen minutes, you’ve learned something important before it matters.

Week 3: Runbook writing

Week 3 is where co-managed IT separates from break-fix outsourcing. A break-fix vendor stops here — tools are in, tickets are flowing, what more do you want? A co-managed partner spends week 3 writing down how your specific environment is meant to operate.

BAU runbooks

Business as usual procedures get documented. The deliverables are short, practical documents — usually one page each — covering things like:

• New starter provisioning end-to-end (M365 licence, group memberships, line-of-business app accounts, hardware allocation, induction checklist)
• Leaver offboarding (account disable timing, mailbox conversion to shared, OneDrive handover, MFA token revocation, asset return)
• Password reset for the CEO’s PA (specific authentication checks because executives get targeted)
• VPN access request and approval workflow
• Standard hardware build and imaging procedure

These runbooks live in shared documentation. Both teams update them. They’re owned by the MSP’s service delivery manager but the internal IT lead has edit rights. If your MSP keeps runbooks in a vault you can’t access, you’ve recreated the original lock-in problem you were trying to solve.

After-hours playbooks

The after-hours playbook is what the NOC reads at 2am when something breaks. It needs to be opinionated. “If the primary firewall is unreachable, do X, then Y, then call Z.” Not “investigate and escalate appropriately.” The whole point of co-managed IT is that the NOC engineer at 2am — who has never met your team — can act decisively because the playbook tells them exactly what your business considers acceptable risk.

Three things the after-hours playbook must include:

1. Reboot authority — what services can the NOC restart without calling anyone, and which ones need human approval no matter what time it is?
2. Escalation contacts in priority order, with both mobile and alternate numbers
3. Communication rules — when does the business want a phone call versus a text message versus an email-tomorrow?

We’re firm with clients on this: if you don’t give the NOC reboot authority for non-critical services, you’re paying for 24/7 cover and getting a 24/7 paging service. Different things.

Escalation tree

Published, visible, dated. Both teams should know that P1 incidents go to the internal IT lead first, then to the operations manager, then to the business owner. P2 follows a different path. P3 doesn’t wake anyone up. The escalation tree gets reviewed and re-signed at every QBR.

Week 4: Shakedown and the first QBR

The final week of onboarding is about live testing and setting up the steady-state cadence.

Live ticket testing

By week 4, real tickets are flowing. We deliberately introduce a few synthetic ones to test the full pipeline — a fake password reset, a simulated phishing report, a planned “service down” drill. The goal is to find the gaps in the workflows we built in weeks 2 and 3 before a real incident finds them for us.

Failover drill

If your environment includes any kind of failover — secondary internet link, virtualised server cluster, cloud-hosted backup of an on-prem database — we test it during week 4. Pull the cable. See what happens. The Footscray distribution client we onboarded last year discovered during their week 4 drill that their secondary internet link had been incorrectly configured for eighteen months. The failover had never worked. They’d have found out the hard way during the next storm.

QBR preparation

The first Quarterly Business Review happens 90 days after go-live, but the pack starts coming together in week 4. The QBR pack should cover:

• Tickets raised, resolved, escalated — broken down by category
• SLA performance against contract
• Open security or compliance findings from the week 1 audit, with remediation status
• Recommended projects for the next quarter, ranked by business value
• Budget tracking against your IT operating budget

A useful QBR is opinionated. The MSP should have a view on what you should do next, with reasoning. If your QBR is a slide deck of green ticks and nothing else, you’re getting account management, not strategic advice.

The 90-day plan

Week 4 closes with a signed 90-day plan listing the projects the MSP and internal IT will tackle together. Usually 3-6 items. Things like “migrate file server to SharePoint,” “replace ageing firewall,” “implement conditional access policies in M365.” Each one has a budget, an owner and a target completion date.

A real example: a 90-staff engineering consultancy in Cremorne

We onboarded a structural engineering consultancy in Cremorne last quarter — 90 staff, two offices, one internal IT manager who’d been there nine years and was three weeks from going on long service leave. The brief was specific: get fully operational before he walked out the door.

Week 1 went mostly to plan. The audit surfaced two unsupported Server 2012 R2 boxes still running production workloads, a Hyper-V cluster with a failed disk that nobody had been alerted to, and an Active Directory with 47 stale user accounts including three former IT contractors with Domain Admin.

Week 2 was where it got interesting. The internal IT manager — entirely reasonably — wanted to be the one to flip every switch. We worked around him, scheduled deployments during his preferred hours, and accepted the slower pace because the alternative was a worse handover. Don’t underestimate this. Co-managed IT is a relationship, and the internal lead’s psychological investment matters.

Week 3 we hit a scope creep moment. The CFO asked whether we could “just have a quick look” at why the M365 e-discovery search wasn’t returning results, which turned out to be a configuration project worth about two weeks of engineering effort. We declined to absorb it into onboarding, scoped it as a separate project, and got it approved as the first item on the 90-day plan. That’s what the RACI is for.

Week 4 the failover drill found that their secondary internet link’s BGP advertisement had a typo in the AS path, so failover would have black-holed traffic. Fixed inside the drill window. The internal IT manager went on long service leave on day 31. Steady-state for the past four months has been clean.

What good MSPs do differently in onboarding

If you’re comparing MSPs and trying to read between the lines of their onboarding pitches, here’s what to listen for.

They want to talk to your existing IT person before signing

A serious MSP wants a 30-minute call with your internal IT lead during the sales process, not after. They’re trying to understand whether the handover will be co-operative. If your prospective MSP shows no interest in your incumbent until the contract’s signed, expect a difficult onboarding.

They have a written onboarding methodology

Ask to see it. If they email you a Visio diagram and a six-page document, good sign. If they wing it from a sales deck, less good. Our methodology lives in the same documentation system clients use post-onboarding — they can see exactly what we’re going to do because we’re going to ask them to use the same system afterwards.

They quote a per-user fixed price for steady-state

Onboarding work is project-priced. Steady-state should be per-user per-month with a clear inclusions list. If your MSP quotes hourly for everything post-onboarding, your costs will balloon unpredictably the moment you actually need them. Our co-managed IT pricing breakdown walks through how this should be structured for Australian SMEs.

Their engineers answer the phone

Not a call centre, not a triage queue with three levels before you reach someone who can help. TechAssist runs 13 engineers, all Australian-employed, and the person who picks up your P1 call at 11pm can usually fix the problem themselves. That model has limits at scale, but at SME scale it’s the right one. Our managed IT services page lays out the staffing model in more detail.

The most common onboarding failures (and how to avoid them)

After eleven years of doing this, the failure modes are pretty consistent.

The incumbent won’t share credentials. Addressed above. Requires executive sponsorship and a frank conversation about resilience.

The RACI doesn’t get signed. Everyone agrees in principle, nobody puts ink on paper, and by week 3 the scope is whatever the loudest person says it is. Insist on signature before week 2 starts.

The MSP deploys tooling without tuning it. Visible in week 2 alert volumes. If your inbox is on fire by Friday of week 2, the MSP isn’t doing the configuration work.

Runbooks get skipped to “save time.” Week 3 is the easiest week to compress because it’s all writing. It’s also the week that pays the biggest dividends in months two through twelve. Don’t let it get squeezed.

The first QBR doesn’t happen. If 90 days come and go and nobody’s booked the QBR, the engagement has already drifted into break-fix territory. Push for the date in week 4.

Scope creep on day 8. The “could you just have a look at” parade. Every co-managed engagement faces this. The answer is “yes, and here’s the scoped quote” — never “yes, we’ll absorb it.”

What this should cost

Onboarding for a 50-150 staff Melbourne business typically lands between $8,000 and $22,000 as a one-off project, depending on environment complexity. Steady-state per-user pricing then sits in the range we’ve documented in our pricing guide. You can also see our standard SLA terms on the pricing and SLA page.

What you should not see is a low onboarding fee paired with hourly steady-state rates. That’s the model where MSPs make their money on the surprise invoice in month three. Per-user fixed monthly with a clear inclusions list is the only model that aligns incentives properly.

Where to from here

If you’ve just signed a co-managed IT agreement, share this article with your new MSP and ask them to walk you through their version of each week. If their methodology looks materially different, get them to explain why. Different isn’t wrong — but it should be defensible.

If you’re still evaluating, our overview of co-managed IT support covers the broader engagement model, and the co-managed IT for Melbourne SMEs piece goes deeper on why the internal-plus-external structure works for businesses in our market.

If you want to talk through your specific environment, the team at TechAssist is on 1300 028 324, or use the form on our contact page. We’re based in Melbourne, our NOC runs out of Tecoma in the Dandenong Ranges, and we’ve been doing co-managed IT for Australian SMEs since 2014. No call centres. No overseas escalation. Just engineers who answer the phone.

FAQs

How long should co-managed IT onboarding actually take?

Four weeks for a typical 30-200 staff Melbourne business. Longer if your environment is unusually complex (multiple sites, heavy compliance requirements, line-of-business applications with no current documentation) or if there’s friction with the incumbent IT staff. If your MSP is quoting more than six weeks for a standard SME environment, ask what’s driving the extra time — it’s usually a sign their process isn’t tight.

Do we need to replace our existing tools during onboarding?

No. Week 2 is about getting visibility, not ripping and replacing. If your existing backup, EDR or RMM is genuinely fit for purpose, a good co-managed partner will connect it to their monitoring and leave it in place. Tool replacements get scoped as separate projects in the 90-day plan, with proper cost-benefit analysis. Anyone who tries to replace everything in week 2 is selling licences, not service.

What if our internal IT person resists the engagement?

Common, and usually fixable. Most resistance comes from job insecurity rather than genuine disagreement. A clear RACI matrix that shows the internal lead remaining responsible for strategic and relationship work — while the MSP absorbs the monitoring, after-hours and overflow — almost always wins them over within the first month. If resistance persists past week 2, that’s an executive conversation, not an IT one.

Will we get the same engineer every time?

For day-to-day work, you’ll get a small team of two to four engineers who know your environment, not a random round-robin from a queue. After-hours and P1 incidents go to whoever’s on the NOC roster, which is why the runbooks matter — they make sure any of our 13 engineers can act decisively on your environment even if they’ve never been on-site. Sub-15-minute P1 response is the standard we hold ourselves to.

What happens if onboarding falls behind schedule?

It happens. About one in five engagements slip by a week, usually because of credential or documentation friction in week 1. A serious MSP will flag the slip immediately, explain the cause, and adjust the plan rather than pretending everything’s on track. The worst outcome is silent slippage — week 4 arrives and nobody’s done the runbooks, but the invoicing has switched to steady-state. Insist on weekly status updates during onboarding and don’t let week 4 close without the deliverables checklist signed off.

For most Melbourne SMEs, co-managed IT cost sits between $55 and $140 per user per month, with the average mid-market quote landing around $85-$110 per user. Hourly retainers usually run $180-$260 per hour. The spread comes down to tooling, security stack, and how much after-hours cover you actually need.

That’s the short answer. The longer answer is where the money actually goes, what’s quietly missing from cheap quotes, and how to read an MSP proposal without getting stitched up. This post walks through real AUD pricing for co-managed IT in Australia, the three pricing models you’ll see quoted, and the variables that genuinely move the number up or down.

The Three Co-Managed Pricing Models You’ll See Quoted

Australian MSPs essentially use three structures for co-managed IT. Most quotes you receive will be a variant of one of these.

1. Per-User Fixed Monthly

This is the model TechAssist uses, and it’s where the market is heading. You pay a flat monthly fee per active user — usually anyone with a corporate email or device. Includes a defined scope of work: monitoring, patching, helpdesk, security stack, vendor liaison.

Typical Melbourne range: $55-$140 per user per month, depending on what’s bundled.

Why it’s becoming standard: budgeting is predictable, and incentives align — the MSP doesn’t earn more when things break, they earn more when you grow. It also scales cleanly through onboarding/offboarding cycles.

2. Per-Device

Common with older MSPs and infrastructure-heavy environments. You pay per endpoint: workstations $35-$70/month, servers $150-$350/month, network devices $25-$80/month each.

It can work out cheaper if your staff share devices (warehouse, retail, shift work), but it gets messy quickly. Users on multiple devices, mobile-heavy workforces, and BYOD all distort the maths. Most knowledge-work SMEs pay more under per-device than per-user once you total it up honestly.

3. Hourly Retainer / Block Hours

You buy a block of hours per month (say 20, 40, 60) at a discounted rate. Standard hourly rates in Melbourne sit at $180-$260/hour, with retainers typically discounting that 10-20%.

Suits businesses with a strong internal IT team who only need escalation, project work, or vendor management. The catch: when something goes wrong, you’re watching the clock burn. It also doesn’t include 24/7 monitoring or automated patching unless those are layered on separately — which they almost always need to be.

What Drives the Per-User Number Up or Down

If two MSPs quote you $65 and $115 per user for “co-managed IT”, they’re not selling the same product. Here’s what actually moves the number.

The Security Stack

This is the biggest variable in 2026. A baseline co-managed quote with Microsoft Defender, basic MFA, and standard email filtering will sit at the lower end ($55-$75 per user). Add EDR/XDR (CrowdStrike, SentinelOne, Defender for Business Premium), DNS filtering, advanced phishing protection, dark web monitoring, and a SIEM, and you’re at $95-$130 per user before anything else.

Hours of Cover

Business hours only (8am-6pm) is the cheap option. Extended hours (7am-9pm) adds roughly $8-$15 per user. True 24/7 with on-call engineers — like TechAssist’s NOC at Tecoma — adds $15-$25 per user but matters enormously when ransomware hits at 2am on a Sunday.

Compliance Requirements

Essential 8 Maturity Level 1 adds $5-$12 per user in tooling and reporting overhead. Maturity Level 2 adds $15-$25. ISO 27001-aligned environments — common in legal, financial services, and government supply chain — typically run $25-$40 per user over baseline. This isn’t optional padding; it’s audit logging, immutable backups, application allowlisting, and the engineering hours to maintain them.

Project Work

Co-managed contracts usually exclude project work — migrations, office fit-outs, major upgrades. This is generally billed at $180-$240 per hour or as a fixed-price scope. If your MSP quietly includes “5 hours of project work per month”, it’s already priced in and you’re paying for it whether you use it.

Realistic Pricing Comparison: What You’re Actually Buying

The table below reflects current Melbourne SME pricing as of mid-2026. These are per-user-per-month figures for organisations of 30-150 staff.

For context on where co-managed sits structurally compared to other models, see our breakdown of co-managed vs fully managed vs internal-only IT.

What’s IN Scope vs OUT of Scope (and the Hidden Costs)

This is where ugly surprises live. A clear scope document should explicitly list both sides. If yours doesn’t, push back before signing.

Typically IN Scope

• Helpdesk tickets within stated hours
• Monitoring and alerting on covered devices
• OS and third-party patching
• Antivirus/EDR management
• Backup monitoring (not restoration drama)
• M365 / Google Workspace administration
• Vendor liaison with ISPs, software vendors
• Monthly reporting

Typically OUT of Scope (Charged Separately)

• Hardware purchases and replacement
• Software licences (M365, security tools — usually pass-through at cost or +10%)
• Major projects (migrations, fit-outs, server replacement)
• Onsite visits beyond a stated allowance
• After-hours work outside contracted cover
• Data recovery from non-backed-up systems
• Training delivery

The Hidden Costs That Catch People

Three recurring ones:

Onboarding fees. Some MSPs charge a one-off discovery and onboarding fee of $3,000-$15,000 depending on environment complexity. This is reasonable for the documentation and tooling rollout work involved, but it should be on the quote, not sprung after signature.

Licence mark-ups. M365 and security tool licences are often resold. A 5-10% mark-up is industry standard. A 25-40% mark-up is gouging. Ask explicitly what the mark-up is.

“Per-incident” fees on top of the monthly. Some cheaper contracts charge per ticket or per hour over a baseline. You think you’re paying $55/user — you’re actually paying $55 plus whatever your team rings up that month. Compare total cost of ownership, not headline rates.

How Pricing Scales With Security and Compliance

This catches a lot of SMEs off-guard. The same 80-user business can have wildly different co-managed pricing depending on what regulators or insurers require.

A general professional services firm with no compliance obligations: $75-$95 per user is fair.

The same firm needs Essential 8 ML1 because they’re tendering for state government work: add $5-$12 per user.

They win a federal contract requiring Essential 8 ML2: add another $10-$15.

They go for ISO 27001 to win enterprise clients: add $20-$30 more per user, plus a one-off implementation cost of $40,000-$120,000.

That same 80-user business has gone from $6,000/month to over $14,000/month — and the MSP isn’t ripping them off. The work, tooling, and audit overhead is genuinely that much greater.

Co-Managed vs Fully Managed: The Real Price Difference

People assume co-managed is significantly cheaper than fully managed because you’re keeping internal IT. The actual gap is smaller than expected — usually 25-40%, not 60-70%.

Why? Because the expensive parts of fully managed IT — the security stack, 24/7 monitoring, tooling licences, NOC infrastructure — don’t get cheaper just because you have an internal sysadmin. The MSP still runs the same RMM, the same EDR, the same SIEM. What you save is the helpdesk volume and Tier 1/2 work that your internal team absorbs.

A realistic comparison for an 80-user Melbourne business:

Co-managed almost never beats fully managed on raw cost. It wins on control, institutional knowledge, faster internal response, and the ability to scale internal capability over time. We’ve covered this in more depth in why Melbourne SMEs choose co-managed over the other models.

What Cheap Co-Managed Actually Means

When someone quotes you $45/user for “full co-managed IT support”, something has to give. Here’s what it usually is.

Junior Techs Doing Senior Work

Cheap MSPs run lean on senior engineering. Your tickets get handled by Tier 1 staff who escalate slowly because escalation is expensive for the MSP. Complex issues sit in queue. By contrast, TechAssist runs 13 Australian-employed engineers with proper Tier 2/3 depth — you get the right person on the ticket, not the only person available.

Tooling Cuts

Real RMM, EDR, SIEM, and backup tooling costs the MSP $25-$50 per endpoint per month in licences before they’ve done any work. When the quote is $45/user, the maths doesn’t add up unless they’re using thin tooling — usually a basic RMM, free-tier antivirus, and no SIEM. You’re paying for monitoring that doesn’t actually monitor.

No Real After-Hours

“24/7 support” at the cheap end usually means a voicemail that gets actioned next business day. Compare that to a real NOC with engineers on shift — TechAssist’s NOC operates 24/7 from Tecoma, with sub-15-minute response on Priority 1 tickets and clearly published SLA terms.

Offshore Helpdesk

Nothing inherently wrong with offshore — but it’s almost always cheaper because of labour costs, not better service. If you’re paying $50/user, your tickets are probably being handled in Manila or Cebu. Fine for password resets. Not fine when your file server is down and the engineer can’t access your network without three hours of permission escalation.

Concrete Example: A 70-Staff Law Firm in South Yarra

A Melbourne law firm we worked with had been paying a cheap MSP $4,200/month ($60/user) for “fully managed IT”. They had one internal IT manager who’d inherited the relationship.

The reality:

• EDR licences they were “paying for” turned out to be a free antivirus, white-labelled
• Backups hadn’t been test-restored in 14 months
• Three sets of dormant admin credentials still active from former staff
• MFA only on email — not on the practice management system or VPN
• “24/7 support” took 6 hours to acknowledge a Saturday outage

We moved them to a co-managed arrangement at $96/user/month ($6,720/month) including proper EDR, M365 Business Premium management, 24/7 NOC cover, Essential 8 ML1 reporting, and monthly security reviews. Their internal IT manager kept ownership of strategy and user-facing work; we picked up monitoring, security, escalations, and after-hours.

Headline price went up 60%. Total IT risk went down by an order of magnitude — and their professional indemnity insurer dropped their premium by $11,000/year because of the improved security posture. Net annual cost increase: roughly $19,000. Worth every cent compared to the ransomware claim they were one bad click away from.

How to Read a Co-Managed Quote Honestly

Five questions to ask every MSP quoting you:

1. What’s the exact tooling stack (RMM, EDR, backup, SIEM) and what does it cost you in licences per endpoint?
2. What are the response SLAs in writing, and what penalties apply if you miss them?
3. Where are your helpdesk staff based, and what hours do they work?
4. What’s onboarding cost, what’s project work charged at, and what’s the licence mark-up?
5. Will you provide three reference clients of similar size and industry?

An MSP that can’t answer these crisply isn’t being deliberately evasive — they probably don’t know. That’s its own answer.

FAQ

Is co-managed IT cheaper than hiring more internal staff?

Usually yes, until you reach about 200-250 staff. A single mid-level sysadmin in Melbourne costs $110-$140k base plus 20-25% in on-costs and tooling. For under $9,000/month, a co-managed arrangement gives you a full engineering team, 24/7 monitoring, and proper security tooling. Past 200 staff, the maths shifts and a larger internal team with selective external support tends to win.

Why do MSP quotes vary so much for the same number of users?

Because “co-managed IT” isn’t a defined product. Two MSPs at $65 and $115 per user are selling fundamentally different things — different tooling stacks, different security depth, different cover hours, different escalation paths. Compare scope line-by-line, not headline price.

Can we start small and add services later?

Yes. Most MSPs (including us) will start you on a base tier and layer in EDR, 24/7 cover, or compliance work as you need it. The cleaner approach is to define what you actually need upfront with a proper discovery, but staged adoption works fine if budget is the constraint.

What’s a fair onboarding fee for a 50-100 user environment?

$5,000-$12,000 depending on documentation state and tooling rollout. Less than $3,000 usually means corners are being cut on discovery. More than $20,000 needs a very clear breakdown of what’s included.

How long should a co-managed contract be?

12 months is standard. Some MSPs push 24-36 month terms for discounts — read the exit clauses carefully. A confident MSP will offer month-to-month after the initial 12, because they don’t need to lock you in.

The Bluntly Honest Summary

Co-managed IT cost in Melbourne lands at $75-$110 per user for most professional services SMEs, climbs to $110-$140 with serious security and compliance, and drops to $45-$70 only if you’re willing to accept thinner tooling and slower response. Anyone quoting outside those ranges should justify exactly why.

The headline rate is the least interesting number on the quote. What matters is the tooling stack, the response SLAs in writing, who actually picks up the phone at 11pm, and what’s hiding in the “out of scope” column. Get those four right and the per-user number will fall where it should.

If you’d like a straight breakdown of what a co-managed arrangement would cost for your specific environment — no sales theatre, just numbers — have a chat with us. You can also read more about how our co-managed model works, or how we approach managed IT services across Melbourne.

Under 15 staff with no IT person — fully managed IT usually fits. 30 to 150 staff with one or two internal techs drowning in tickets — co-managed vs managed IT tilts toward co-managed. 200+ with complex apps and strict compliance — a proper internal team, often backed by a partner, is the right call.

That’s the short answer. The rest of this post is the working — what each model actually means once the sales deck closes, what it costs in real AUD, where each one falls over, and a decision matrix you can take into your next board meeting.

We’ve helped Melbourne SMEs across Cremorne agencies, Dandenong manufacturers, and Box Hill medical practices move between all three models. None of them are inherently better. They suit different shaped businesses, and the wrong fit is expensive in ways that don’t show up on the invoice.

What each model actually means in practice

The three terms get used loosely, and MSPs are guilty of muddying the water. Here’s what’s really on offer when you strip out the marketing.

Internal IT

You employ your own IT staff. Could be one person doing everything from password resets to Azure tenant design, or a structured team with a help desk, sysadmins, and an IT manager reporting to the CFO or COO.

The pitch is control and institutional knowledge. Your IT person knows where the bodies are buried, sits in the lunchroom, and can be tapped on the shoulder. They learn your line-of-business apps deeply because they live with them every day.

The reality is that one person can’t cover everything. A solo internal hire is on-call 24/7 by default, can’t take a fortnight off without something burning, and is unlikely to be equally strong at Microsoft 365 hardening, network design, backup verification, server patching, and end-user support. You’re paying senior money for someone who’ll spend two thirds of their day on tickets a Level 1 should handle.

Fully managed IT

You outsource the lot to an MSP. They run your help desk, manage your devices, patch your servers, monitor your network, handle your backups, and own the relationship with Microsoft, your ISP, and your line-of-business vendors. You get a single number to call.

The pitch is predictable cost, broad skill coverage, and after-hours support without paying overtime.

The reality, when it’s done properly, matches the pitch. The reality when it’s done badly is ticket queues, junior engineers cycling through your account, and a feeling that nobody actually knows your business. The difference comes down to engineer-to-client ratios, whether the MSP is Australian-employed or offshored, and whether there’s a named technical lead on your account.

At TechAssist we run with 13 engineers, all Australian-employed, and clients get a named lead engineer who knows the environment. We charge per user, fixed, with no surprise hourly billing. The model only works if the MSP is genuinely incentivised to fix root causes rather than churn tickets.

Co-managed IT

You keep your internal IT person or team, and an MSP plugs in alongside them. Roles get carved up explicitly. The internal team usually owns user-facing work, line-of-business app knowledge, and project liaison. The MSP owns the heavy lifting — 24/7 monitoring, after-hours coverage, backup verification, security operations, escalations, and the deep technical work the internal person doesn’t have time for.

The pitch is “your internal IT, supercharged.” It’s accurate when the boundaries are clear and the MSP doesn’t try to land-grab. It falls over when nobody documents who owns what, and tickets fall between the cracks.

Co-managed is the fastest-growing of the three models in the Melbourne SME market, and it’s where we’re seeing the most thoughtful conversations. We’ve written a longer piece on how it works specifically for Melbourne SMEs that runs alongside this one — see co-managed IT for Melbourne SMEs: internal plus external for the operational detail.

Who each model actually suits

Forget headcount-only rules of thumb. The right model depends on a handful of factors that interact.

Fully managed: the sweet spot

Best fit: 5 to 50 staff, no internal IT, standard tech stack (Microsoft 365, some line-of-business SaaS, maybe a file server or two), and a leadership team that wants IT to “just work” without thinking about it.

Concrete example: a 22-person accounting firm in Camberwell running Xero Practice Manager, FYI Docs, and Microsoft 365. They don’t need a full-time IT person — that’d be 60% idle. They need someone to onboard new staff in a day, keep the laptops patched, run the backups, respond when someone can’t print, and lift their security posture so the cyber insurance renewal doesn’t bite. Fully managed is the obvious call. See our managed IT services for what’s included.

Also a strong fit: professional services firms, allied health practices, smaller manufacturers, and not-for-profits where IT isn’t a competitive differentiator and reliability matters more than bespoke control.

Co-managed: the sweet spot

Best fit: 30 to 150 staff, one to three internal IT people, and either a growth trajectory that’s outpacing the team or a skills gap (usually security, cloud architecture, or after-hours).

Concrete example: a 75-person engineering consultancy in Richmond with a solo IT manager. He’s good — knows the CAD pipeline, knows the Revit licensing, knows which director hates Teams. But he’s the only one. He can’t take leave, his security knowledge is patchy, and the directors won’t sign off on hiring a second IT person at $110k when they’re not sure it’s justified.

Co-managed lets him keep owning the user-facing work and the CAD environment, while an MSP runs 24/7 monitoring, handles after-hours incidents, owns backup verification, and gives him senior engineers to escalate to when something’s beyond his depth. He stops being a single point of failure, and the directors get sub-15-minute response times around the clock without hiring a second body. Our co-managed IT support page covers how the role split works in practice.

Also a strong fit: mid-sized law firms, multi-site retail, manufacturers with shift work needing after-hours coverage, and any business where the internal IT person is the bottleneck on growth.

Internal IT (sometimes plus a partner): the sweet spot

Best fit: 200+ staff, complex environment (multiple line-of-business apps, integrations, dev teams, regulated industry), and IT genuinely is a strategic function rather than a cost centre.

Concrete example: a 350-person specialist healthcare provider with multiple clinics across Victoria, a custom patient management platform, HL7 integrations with pathology and imaging providers, and ADHA compliance requirements. They need an IT manager, a help desk, sysadmins, and probably a developer or two. An MSP can’t run this — too much institutional knowledge required, too much custom work, decisions that need to be made in real time with clinical context.

What they often do have is a partner for specific functions: a security-focused MSSP for SOC services, a cloud partner for Azure architecture reviews, or an MSP backstop for after-hours help desk overflow. Pure internal is rare at this size; pure outsourced is dangerous.

Also a strong fit: financial services with regulatory complexity, large healthcare networks, businesses with significant in-house software development, and any organisation where the IT function is genuinely a strategic asset.

What each model costs (real AUD ranges)

Prices below are Melbourne market ranges as of mid-2026, for a representative SME profile. Your numbers will vary with complexity, but these are the right order of magnitude.

Internal IT cost

A solo internal IT generalist in Melbourne: $85k to $120k base salary, plus super, leave, training, and tools. All-in cost to the business is roughly $115k to $160k per year. Add the cost of the gear they need (admin licences, monitoring tools, backup software if you go DIY) and you’re closer to $130k to $180k.

For a 30-person business, that’s $360 to $500 per user per month, just for one person. And you’ve still got a single point of failure, no after-hours coverage, and skill gaps.

A structured internal team (IT manager + two help desk + one sysadmin) for a 200-person business: $450k to $650k all-in, or roughly $190 to $270 per user per month before tools and gear.

Fully managed IT cost

Quality Melbourne MSPs charge between $120 and $220 per user per month for fully managed, depending on scope, security inclusions, and whether 24/7 is bundled in. The cheap end ($60 to $100) usually means offshore help desk, shared engineer pools, and project work billed separately on top. The expensive end usually includes a vCIO function, security operations, and bundled project hours.

TechAssist sits in the middle — fixed per-user pricing, no hourly billing for in-scope work, 24/7 NOC included, and named engineers per client. Full breakdown on our pricing and SLA page.

For a 30-person business: roughly $3,600 to $6,600 per month, or $43k to $80k per year all-in. Less than half the cost of a solo internal hire, with broader coverage and no leave gaps.

Co-managed IT cost

Co-managed pricing varies more because the scope varies. Typical Melbourne ranges are $50 to $130 per user per month for the MSP portion, on top of your existing internal IT salary cost.

For the 75-person engineering consultancy above: $110k for the internal IT manager, plus roughly $4,500 to $9,000 per month for co-managed coverage. All-in cost in the $165k to $220k range, versus $220k+ for hiring a second internal person to fill the gaps.

The maths usually works out in favour of co-managed at this size, and you get 24/7 coverage, deep specialist skills on tap, and resilience the second hire wouldn’t have provided.

The comparison matrix

This is the table to take to your next leadership meeting. One row per decision factor, one column per model.

What breaks under stress in each model

Every model has a failure mode. Knowing them up-front saves grief.

Internal IT failure modes

The single-point-of-failure problem is the big one. When your solo IT person resigns, takes long-service leave, or gets hit by a bus, the institutional knowledge walks out the door. We’ve been called into Melbourne businesses where the internal IT manager left with three weeks’ notice and nobody else knew the admin passwords, the backup configuration, or which Azure tenant did what. Recovery takes months.

The other failure mode is skills atrophy. A solo IT person can’t be expert at everything. Their security knowledge gets stale, their cloud architecture is whatever they learned five years ago, and their backup verification is “I assume it’s working.” This bites hardest during incidents.

Fully managed IT failure modes

The classic failure is the help desk ticket queue. You log a ticket, it sits with a Level 1 engineer who doesn’t know your environment, it gets escalated, then re-escalated, and four days later somebody actually fixes it. This happens when the MSP’s engineer-to-client ratio is too high, or when accounts get bounced between engineers with no continuity.

The other failure is scope arguments. “That’s not in your agreement, that’ll be billable” gets old fast. The fix is choosing an MSP with broad fixed-scope inclusions and not the cheap-and-cheerful end of the market.

The third failure, less talked about, is loss of internal capability. After three years of full outsourcing, your team has forgotten how anything works. Switching providers or bringing it back in-house becomes a major project.

Co-managed IT failure modes

The biggest one is unclear boundaries. If the RACI matrix isn’t documented and reviewed quarterly, tickets fall between the cracks. The internal person thinks the MSP owns it, the MSP thinks internal owns it, the user waits two days, and trust erodes.

The second failure is ego. Some internal IT people see the MSP as a threat to their job. Some MSPs treat the internal person as a junior to be worked around. Either kills the model. It needs to be a partnership, with the internal IT person treated as the senior on-site contact and the MSP as the deep-bench backstop.

A worked example: which model would a Cremorne creative agency choose?

Imagine a 45-person creative agency in Cremorne. Adobe Creative Cloud across the studio, big shared storage for video projects, Microsoft 365 for everything else, hybrid working, and one part-time IT contractor who comes in two days a week.

The contractor handles user issues and the studio storage. He’s competent but works in a silo. The directors are nervous about security after a competitor got hit with a ransomware incident last year. They’ve never tested a backup restore. After-hours support is whatever the contractor picks up on his mobile.

Three honest options:

• Hire a full-time IT manager. $115k all-in. Still a single point of failure. Still no genuine after-hours. Probably overkill for the day-to-day load.
• Move to fully managed. Replace the contractor entirely. Roughly $6,500 a month all-in for a quality MSP. Lose the contractor’s accumulated knowledge of the studio storage and Adobe setup.
• Move to co-managed. Keep the contractor (maybe bump him to three days a week) and bring in an MSP for monitoring, after-hours, security operations, backup verification, and escalation. Roughly $4,500 to $5,500 a month for the MSP portion, on top of the contractor.

For this business, co-managed is usually the right answer. The contractor’s studio knowledge is valuable. The MSP fills the security, after-hours, and resilience gaps. The total cost is lower than hiring a full-time IT manager, and the risk profile is much better than the status quo.

For a different business — say, a 12-person Hawthorn architecture practice with no internal IT at all — fully managed would be the obvious answer, not co-managed.

How to actually decide

If you’re staring at the matrix and still not sure, work through these questions honestly.

Do you have someone internal already?

If yes, and they’re competent, the conversation should start with co-managed. Replacing a good internal IT person with an MSP almost always costs you institutional knowledge that’s hard to rebuild. Co-managed lets you keep what works and patch what doesn’t.

If no, fully managed is the default unless you’re large enough (200+) to justify building an internal team from scratch.

What’s your growth trajectory?

If you’re growing fast — say, doubling staff in 18 months — fully managed scales the easiest. You add users to the agreement. Internal hiring lags growth by months, which means IT becomes the bottleneck.

If you’re stable, the question is more about fit and cost.

How much does after-hours matter?

If you’re shift-based, multi-state, or your business loses meaningful revenue during downtime, after-hours coverage is non-negotiable. Internal-only struggles here. Both managed and co-managed models include 24/7 monitoring and response from a proper NOC.

What’s the compliance picture?

If you’re in healthcare, financial services, government-adjacent, or you handle sensitive client data with regulatory implications, get specific about what controls you need. Essential Eight maturity, ISO 27001, ADHA, APRA — these change the conversation. A good MSP will speak this language. An MSP that doesn’t is a red flag regardless of which model you choose.

FAQ

Can I switch from managed to co-managed later if I hire an internal IT person?

Yes, and a decent MSP will welcome it. The scope shifts — your internal person takes on the user-facing work, and we re-carve the responsibilities. Pricing usually drops because we’re doing less of the day-to-day, though not as much as you might expect, because the high-value work (monitoring, security operations, after-hours) stays with us. Get the boundary changes documented before the new hire starts.

What’s the minimum business size where fully managed makes sense?

Around 5 staff. Below that, the per-user pricing model can feel steep relative to the actual support load, and ad-hoc engagements often suit better. From 5 staff upward, the maths starts working — you’re getting a help desk, monitoring, patching, backups, security, and after-hours for less than you’d pay a junior IT person.

Does co-managed mean my internal IT person gets demoted or sidelined?

If it’s set up properly, no — the opposite. The internal person typically becomes the technical owner of the relationship, the person who decides priorities, and the senior point of contact. The MSP works to their direction on most things. Where it goes wrong is when the MSP tries to take over, or when leadership treats the internal person as redundant. Set the framing early and revisit it quarterly.

How do I tell if an MSP is good before signing?

Ask for the engineer-to-client ratio, where the engineers are employed (Australia or offshore), whether you’ll get a named technical lead, what’s actually in scope versus billable, and what their average response time is for high-priority tickets. Ask for two reference clients of similar size and industry. If they hedge on any of these, walk. At TechAssist we publish our response targets (sub-15-minute on high-priority), our team size (13 Australian-employed engineers), and our pricing structure publicly because we’d rather have those conversations up-front.

Can I run fully managed for the main business and internal IT for a specific division?

Yes, and it’s more common than people realise. A manufacturing business might run fully managed across head office and the warehouse, but keep an internal IT person dedicated to the production floor systems. A medical group might outsource the corporate office but keep clinical IT internal. The key is clean boundaries and a single point of accountability for cross-domain issues.

The honest answer

There’s no universally right model. There’s a right model for your business at its current size, with its current internal capability, in its current growth phase, with its current compliance burden. Two years from now the answer might be different.

The wrong model is usually expensive in ways that don’t show up immediately. A solo internal IT hire in a 25-person business looks like control — until they resign. A bargain-basement MSP in a 60-person business looks like savings — until the third major incident in a quarter. Hiring an internal team in a 40-person business looks like maturity — until you realise you’re paying $400k for capabilities a $90k-a-year MSP would have covered better.

If you want a second opinion that doesn’t end with us trying to sell you something you don’t need, give us a call on 1300 028 324 or get in touch via our contact page. We’ll tell you honestly which of the three models fits, even if it’s not us. If you’re specifically weighing up MSP options in Melbourne, our Melbourne managed IT services page lays out exactly what we cover, what we charge, and what the SLAs look like.

An internal IT team overwhelmed by demand looks like this: a growing ticket backlog, the same problem fixed for the third time this month, projects perpetually “next quarter”, and a senior tech who hasn’t taken a proper holiday since 2023. Work gets done — barely — but nothing improves.

If that sounds familiar, you’re not alone. We see it constantly across Melbourne — particularly in firms that grew from 30 staff to 120 over a few years without rebuilding the IT function to match. This article is for business owners, GMs and CFOs who already have an internal IT team of one to three people and are starting to notice the cracks. It’s a different problem from businesses with no formal IT support at all — those firms need a starting point. You need to fix something that’s already there.

Why this matters now

An overwhelmed internal IT team is one of the most expensive problems in a mid-sized business, and it’s almost always hidden. The salaries are already paid. The tickets are eventually closed. From the outside, IT looks “fine.” But underneath, three things are happening: security work is being skipped, your best technical person is quietly burning out, and the business is paying senior-engineer wages for help-desk work.

None of that shows up on a P&L line until something breaks. Then it shows up as a ransomware incident, a key resignation, or a $90,000 project that overruns by six months.

What “overwhelmed” actually looks like

Forget the abstract definitions. Here are the observable signs we walk into when a Melbourne business calls us about co-managing their IT.

1. The ticket backlog never shrinks

Healthy internal IT teams clear what comes in each week, with a slow-burn project queue running underneath. Overwhelmed teams have a backlog that grows steadily — 40 open tickets becomes 80, then 150. The team isn’t lazy. They’re triaging the loudest problem, fixing it, then moving to the next loudest. Nothing strategic gets touched.

A useful test: ask your IT manager how many tickets are older than 30 days. If they don’t know, or the number is above 10% of monthly volume, you have a capacity problem.

2. Projects have been “next quarter” for a year

Server replacement. Entra ID tenant cleanup. Backup verification. Migrating off that one legacy app nobody wants to touch. These projects sit on the roadmap because everyone agrees they’re important, but the team is too busy fixing today’s problems to start them. This is the clearest sign that the day-to-day load has consumed the team’s strategic capacity.

3. Security work is the first thing to get skipped

Patching schedules slip. MFA rollouts stall at 70%. Conditional access policies never get tightened past the defaults. The internal team knows it matters — they’re not negligent — but security work is usually invisible until it isn’t, so it loses every battle for time against a user who can’t print.

4. Everything breaks when Mark goes on holidays

Key person dependency is the dead giveaway. If your senior tech takes two weeks off and the team can’t function — passwords can’t be reset for certain systems, the firewall config is a mystery, nobody else knows how the backup actually works — you don’t have an IT team. You have one person and some helpers. This is fragile and it gets worse over time, because Mark stops documenting things he doesn’t have time to document.

5. Documentation is non-existent or three years stale

Ask to see the network diagram. Ask where the admin credentials are stored. Ask for the runbook on restoring email if the tenant goes down. If the answer is “it’s in Mark’s head” or “we had one but it’s old,” your team is past capacity. Documentation is the first thing that goes when people are flat out, and the absence of it makes everything slower.

6. After-hours work has become routine

Patching on Saturday nights. Answering Teams messages at 9pm. The senior engineer logging in from home on Sunday to fix the accounting export before Monday morning. Occasional after-hours work is part of the job. Routine after-hours work means the team is doing two jobs in one week and one of them is being done on personal time. It ends in resignation, usually with three weeks’ notice.

7. Your IT manager is doing tier-1 tickets

If the person you hired to run IT strategy is resetting passwords and unjamming printers, you’re paying $140k for $60k work, and the strategy isn’t happening. This usually means the team is short one or two technicians and the manager has been absorbing the gap.

8. Vendors are managing the team instead of the other way around

The internet provider, the phone system vendor, the line-of-business app support team — they’re all calling the shots about when things happen, because the internal team doesn’t have time to push back or coordinate. You start finding out about changes after they happen.

A concrete example

A professional services firm in South Yarra came to us last year. About 85 staff, two internal IT people — a manager and a junior. On paper, that’s a reasonable ratio. In practice, the manager was working until 7pm most nights, taking calls on weekends, and hadn’t started the Microsoft 365 security baseline project that had been approved 14 months earlier.

The junior was good but couldn’t operate without supervision on anything past tier-1. When the manager took annual leave over Christmas, the firm had three outages in two weeks because nobody else knew the environment.

The owner’s first instinct was to hire a third person. That would have helped, eventually — but the recruitment timeline alone was three to four months, and onboarding another six weeks before they were useful. Meanwhile the manager was 90 days from resigning. We don’t say that hypothetically; he told us so on the second meeting.

We ended up co-managing with them. Our team took over the after-hours load and the tier-1 ticket queue. Their manager kept ownership of strategy and the relationship with the business. Within six weeks the backlog was down 70%, the security project was running, and the manager was taking weekends off again. He’s still there.

Your three real options

When an internal IT team is overwhelmed, there are realistically three responses. The honest answer is that the right one depends on your situation — there’s no universal best.

When hiring is the right call

If your business is genuinely growing — adding 20+ staff per year, opening new sites, expanding the application stack — and you’ve got the management bandwidth to onboard and supervise, hiring is often correct. A third internal tech who knows the business deeply is worth a lot. Just be honest about the timeline. You’re not going to feel relief for six months.

When promoting works

Sometimes the team is fine but the structure is wrong. The senior tech is doing manager work informally, the junior is ready for more, and a quick reshuffle plus clearer responsibilities solves 60% of the problem. This works best in smaller teams where the issue is role ambiguity rather than headcount.

When co-managed makes sense

If your internal team is solid but drowning, co-managed IT is usually the fastest way to relief. The MSP takes over the predictable, repeatable work — tier-1 tickets, after-hours coverage, patching, monitoring — and your internal team gets back to the strategic work they were hired for. Done well, your manager keeps their job satisfaction and your business keeps the institutional knowledge.

This isn’t the same as fully outsourced managed IT, which replaces the internal team. Co-managed augments them. The distinction matters when you’re talking to staff about what’s changing.

What to look for in an MSP if you go co-managed

If you do head down the co-managed path, the wrong MSP will make your problem worse. They’ll squabble with your internal team over territory, fail to document what they do, and slowly position themselves to replace your internal staff. The right MSP behaves like a senior colleague to your IT manager, not a competitor.

• Australian-based engineers. Co-managed only works with tight collaboration, and that’s harder across time zones. TechAssist runs with 13 engineers, all Australian-employed.
• Real after-hours coverage. Not a voicemail and a callback. Our 24/7 Network Operations Centre at Tecoma in the Dandenongs handles overnight monitoring and incident response, which is exactly the load that’s killing your internal team.
• Fast response on critical issues. We target sub-15-minute response on critical tickets. If your internal team knows that backup is there, they sleep better.
• Clear scope. You should be able to draw a line between what the internal team owns and what the MSP owns, and update it as things evolve.
• Documentation discipline. The MSP should be feeding documentation back to your team, not hoarding it as job security.

If you’d rather discuss your specific situation, our team in Melbourne is happy to have a no-pressure conversation. Call 1300 028 324 or use the contact page. We’ve been doing this since 2014 and we’ll tell you honestly if co-managed isn’t the right fit.

What not to do

A few patterns we see that don’t end well:

• Hiring a junior to “help” a drowning senior. The senior now has less time, because they’re supervising the junior, and the junior can’t take work off their plate for six months.
• Buying tools instead of capacity. A new RMM platform or ticketing system doesn’t fix the problem. It just gives you better visibility into the backlog.
• Asking the team to “be more efficient.” They’re already running flat out. Telling overwhelmed people to work smarter is how you get a resignation.
• Ignoring the documentation gap. If you don’t fix it, the day Mark resigns is the day you discover what you don’t know.

How to decide

Pick a quiet week and do three things. First, sit with your IT manager for an hour and ask them honestly what they’d change if they could. Second, look at the ticket data — volume, age, recurrence. Third, look at the project roadmap and ask which things have been on it for more than six months and why.

If the answers point to “we need a person who can take ownership of this whole function long-term,” hire. If they point to “we need predictable capacity now, especially after hours,” look at co-managed. If they point to “the whole IT function is broken and we don’t have anyone capable of running it,” that’s a conversation about fully outsourced IT support.

FAQ

How do I know if my internal IT person is overwhelmed or just bad at their job?

Look at trajectory. A good person who is overwhelmed will be doing things in the right order — critical first, easy wins next — and will be honest about what’s not getting done. A bad hire will be busy on the wrong things, defensive about backlog, and surprised by problems they should have seen coming. If you’re not sure, get an outside review of the environment. The state of documentation, patching and backups will tell you quickly.

Won’t bringing in an MSP make my internal team feel threatened?

It can, if you handle it badly. The framing matters. Co-managed IT is being introduced because the business has grown beyond what one or two people can sustain — not because the internal team has failed. The good ones are usually relieved. The ones who feel threatened often turn out to be the ones quietly hoping nobody finds out what they haven’t been doing.

How much does co-managed IT cost compared to hiring?

A mid-level Melbourne technician costs around $90-110k loaded once you add super, leave, training and overheads. Co-managed engagements vary by scope, but for a 50-100 staff business expect to spend less than a full-time hire while getting after-hours coverage, multiple skill sets and no recruitment risk. The honest answer is to get specific quotes against your environment.

Will my internal IT manager lose authority if we bring in an MSP?

Not if the scope is clear. In a proper co-managed setup, the internal manager owns strategy, vendor relationships and business context. The MSP owns execution capacity, after-hours coverage, and specialist skills they wouldn’t otherwise have access to. The manager becomes more effective, not less.

How fast can we actually get relief?

Faster than hiring. A reasonable co-managed onboarding is 4-6 weeks to fully embedded, but a good MSP will be absorbing tickets and after-hours load within the first two weeks. Compare that to a 3-4 month recruitment timeline plus onboarding. For a team that’s already burnt out, that gap matters.

The honest summary

An overwhelmed internal IT team is a solvable problem, but only if you name it early. The longer it runs, the more you lose — first in projects, then in security posture, then in your best person walking out the door. Hiring, restructuring and co-managed are all valid responses. Pick the one that matches your actual situation, not the one that feels least disruptive.

If you’d like a Melbourne-based perspective on which option fits your business, the team at TechAssist is happy to walk through it. We’ve been doing this since 2014 and we’d rather tell you honestly what we’d do than win work we shouldn’t have.

Co-managed IT makes sense when your internal IT person is drowning in user tickets and hasn’t touched the firewall in six months, when you’re growing past 80 staff and the after-hours pages are killing morale, or when your one IT hire just resigned and you can’t risk another single point of failure. It’s a split, not a replacement.

That’s the honest version. The marketing version — “best of both worlds, all the benefits, none of the trade-offs” — is what most MSPs will tell you. Sometimes it’s true. Often it isn’t. This piece is the conversation we have with Melbourne SMEs who ring us at 1300 028 324 asking whether co managed it services are right for them, and the answer is genuinely “it depends” — but the dependencies are knowable.

We’ve been running this model with Melbourne businesses since 2014. Some engagements have been outstanding. A handful have been awful. The difference between the two is almost never the technology and almost always the operational split and the politics around the internal IT person. So that’s what we’ll spend most of this on.

What co-managed IT actually is (and isn’t)

Co-managed IT means you keep your internal IT person or small team, and you bring in an MSP to handle specific parts of the stack alongside them. The internal team isn’t replaced. The MSP isn’t a back-up they call when things break. Both parties work on the environment continuously, with clearly divided responsibilities.

What it isn’t: an MSP that your internal IT person escalates tickets to when they’re stuck. That’s “ad hoc support,” and it’s a fine model, but it’s not co-managed. The difference is ownership. In a proper co-managed setup, the MSP owns whole categories of work outright — they don’t wait to be asked.

It also isn’t a stepping stone. Some businesses use co-managed as a polite way to phase out an internal IT person they don’t want to fire directly. That tends to end badly for everyone. If you want to fully outsource, look at fully managed IT services and have a direct conversation with your IT hire about what’s happening. Don’t drag an MSP in to do the awkward part.

When co-managed actually makes sense

Here are the specific triggers we see in Melbourne SMEs that point to co-managed being the right call. Not “you might consider this if” — actual triggers that move the needle.

You’re between 50 and 300 staff with one or two IT people

This is the sweet spot. Below 50 staff, you generally don’t need internal IT at all — a properly run MSP handles everything. Above 300 staff, you usually need a real internal team (3+ people) with proper specialisation, and the MSP role shifts toward niche work or project capacity. The 50-to-300 band is where one or two internal people simply can’t cover the surface area, no matter how good they are.

Your IT person is doing user support all day and infrastructure work never gets done

Classic. A construction firm in Hawthorn rang us last year — 110 staff, one IT manager, lovely bloke. He was answering 30+ tickets a day, mostly Outlook and printer issues. He hadn’t patched the Hyper-V hosts in four months. The backup hadn’t been test-restored since 2024. He knew it was a problem; he just couldn’t get to it. That’s not a competence issue, it’s a capacity issue. Co-managed fixed it: he stayed on user-facing work and projects, we took backups, patching, monitoring, security and after-hours.

You need 24/7 coverage but can’t justify a second IT hire

Paying a second internal engineer $110k+ to cover nights and weekends — when most nights nothing happens — is hard to justify. An MSP with a proper 24/7 NOC (ours runs out of Tecoma in the Dandenongs) spreads that cost across many clients. You get genuine after-hours coverage for less than half what a second hire costs.

You’ve got compliance pressure you can’t meet alone

Law firms, healthcare practices, businesses chasing ISO 27001 or working with government — the security and compliance workload is genuinely too much for one person to do well alongside everything else. Co-managed lets the internal person focus on the business while the MSP runs the security operations, patching cadence, vulnerability management and audit prep.

Your IT person is good but lonely

This one is underrated. A single IT person in a 90-staff business has no peers, no one to bounce decisions off, no one to cover holidays properly. We’ve had internal IT people tell us — quietly — that the best part of co-managed is having actual colleagues again. They ring our engineers to discuss a tricky migration the way they would have rung a workmate at their last bigger employer. Retention goes up.

When co-managed does NOT make sense

Equally important. Don’t sign up for co-managed if:

• You have fewer than 30 staff. The overhead of coordinating two teams isn’t worth it. Just go fully managed.
• Your internal IT person is openly hostile to the idea. We’ll come back to this. Forcing it never works.
• You’re trying to save money by reducing the MSP scope. Co-managed is usually cost-neutral or slightly more expensive than full management at the same staff count. If budget is the only driver, you’ll be disappointed.
• You don’t have a clear reason your internal IT person should exist. “We’ve always had one” isn’t a reason. If the role exists out of habit, fix that first.
• Your internal IT person is the business owner’s nephew. Sorry. This always ends badly. The political dynamics are unworkable.

The operational split that actually works

This is the most important section. Get the split right and co-managed sings. Get it wrong and you’ll have two teams pointing at each other when things break.

The split we use with most Melbourne SMEs:

Notice how few items are “joint.” That’s deliberate. Strategy and documentation have to be shared because they touch everything, but for any specific task someone is named as the owner. The MSP doesn’t wait to be asked to patch the firewall — patching the firewall is theirs. The internal person doesn’t escalate Outlook tickets to us — those are theirs.

The reason this works is that it eliminates the “who’s doing this?” question. When the backup fails at 2am, our NOC engineer at Tecoma sees the alert and starts working it. They don’t ring the internal IT manager first. When a user can’t print, the internal IT person handles it. They don’t open a ticket with us first.

The operational split that fails

The model we see fail most often is “everyone shares everything.” It sounds collaborative. It’s a disaster.

If you can’t draw a clear line through every operational responsibility and put one name on each side, the co-managed setup will rot within six months. Diffused ownership is worse than no ownership, because everyone thinks the work is being done.

The political problem nobody warns you about

This is the section your prospective MSP probably won’t write for you. We’ll be blunt about it because we’ve seen it kill engagements that should have worked.

When you bring an MSP in alongside an existing internal IT person, that person will feel — at minimum — uncertain about their job, and at worst, openly threatened. It doesn’t matter how many times you tell them otherwise. They’ve seen “co-managed” used as a phase-out tactic at other companies. They’ve heard the rumours. They will, consciously or otherwise, look for ways to demonstrate that the MSP is unnecessary.

What this looks like in practice:

• The internal IT person doesn’t share documentation, passwords or context with the MSP. “Oh, I’ll handle that one.” It happens for weeks.
• When the MSP recommends a change, the internal IT person finds reasons it won’t work in this specific environment.
• User complaints about the MSP — real or fabricated — get passed up to leadership without the MSP being told.
• The internal IT person quietly does work that’s the MSP’s responsibility, then mentions to leadership that they had to “fix it themselves.”
• Critical alerts get acknowledged by the internal person and not actioned, so the MSP looks slow.

This isn’t villainy. It’s a human response to feeling threatened. But it will absolutely destroy a co-managed engagement, and we’ve walked away from clients where leadership wouldn’t address it.

How to actually fix the political problem

A few things that work, in our experience:

1. Involve the internal IT person in selecting the MSP. If they were part of the decision, they own it. If it was imposed on them, they’ll resent it. Have them on the calls. Take their objections seriously.
2. Be explicit about job security in writing. If their role is safe, put it in writing. If it isn’t, don’t pretend otherwise — be honest about what co-managed means for the role over 12 to 24 months.
3. Give the internal person the more interesting work. They keep projects, strategy, user-facing wins. The MSP gets the unglamorous 2am patching and the security paperwork. They should feel like co-managed made their job better, not smaller.
4. Don’t have the MSP report on the internal person. The MSP reports on the environment. Leadership manages the internal person. Mixing those creates a snitch dynamic that poisons everything.
5. Pay attention to whether the internal person is actually engaging. If three months in they still won’t add the MSP to the documentation system, that’s a signal. Have the conversation.

Pricing — how co-managed compares

Honest pricing conversation. Co-managed isn’t cheaper than fully managed in most cases. Sometimes it’s slightly more, because you’re paying for the internal person AND the MSP, and the MSP scope only shrinks a bit (we still own the infrastructure, security, after-hours and tooling — that’s the bulk of the cost anyway).

The reason businesses pay the premium for co-managed isn’t cost savings — it’s capability and resilience. You get an IT function that doesn’t collapse when your one IT hire takes leave or resigns. You get genuine 24/7 coverage. You get specialists for things one generalist can’t keep up with (security, networking, cloud architecture). And you keep someone on site who knows the business intimately.

Our co-managed pricing follows the same per-user fixed monthly model as our fully managed service — we just adjust scope based on what the internal team owns. Full pricing transparency is on our pricing and SLA page, including the sub-15-minute response commitment for critical incidents.

A real example — a logistics business in Dandenong

To make this concrete. A logistics business in Dandenong came to us in 2023 — 140 staff across the warehouse and office, two internal IT people (a manager and a junior), running on a mix of on-prem servers, Microsoft 365, and a Warehouse Management System integrated with their TMS. Trucks moving 24/7. Tight margins.

The problem: the IT manager was burnt out. He was on-call 24/7, the junior was answering tickets all day, and any time something serious went wrong with the WMS overnight, the IT manager was woken up. He’d been there nine years. He was about to resign.

What we changed:

• Took over all infrastructure, network, security, backup and patching. Internal team handed over root credentials, joined our documentation system, and stopped doing infrastructure work entirely.
• Picked up 24/7 on-call. Our NOC at Tecoma handles all after-hours alerts and the first response on overnight WMS issues. They escalate to the IT manager only if it’s genuinely something only he can fix — which, with proper documentation and runbooks, is now maybe once a month instead of three times a week.
• The junior kept ticket queue, user onboarding, hardware refreshes, and got time to actually develop skills.
• The IT manager moved to strategy, vendor management, project work (a big WMS upgrade) and proper holidays.

Two years in, the IT manager is still there. The junior has been promoted. The business hasn’t had an after-hours outage that wasn’t resolved within the SLA. The IT manager rings us when he wants a second opinion on something, and our engineers ring him when they need warehouse context. It works.

What made it work: the IT manager was part of the decision. The scope was clear. Leadership didn’t ask us to report on him, and didn’t ask him to report on us. We solved a capacity and resilience problem, not a competence problem.

How to evaluate whether you’re ready

Quick self-assessment. If you answer yes to three or more, co-managed is worth exploring properly:

• Do you have one or two internal IT people supporting more than 50 staff?
• Has critical infrastructure work (patching, backup testing, security review) slipped in the last 6 months?
• Is your internal IT person on call 24/7 with no real backup?
• Have you had an outage in the last year where the response was slower than it should have been because the right person wasn’t available?
• Is your internal IT person also expected to handle strategic projects, but never seems to get to them?
• Are you worried about what happens if your IT person resigns tomorrow?
• Do you have compliance pressure (ISO, Essential Eight, sector-specific) that’s not being properly addressed?

If you said no to most of these and things are running smoothly, don’t fix what isn’t broken. If you said yes to most, you’re already paying the cost of an unsustainable IT setup — it’s just hidden in burnt-out staff, deferred work, and risk that hasn’t materialised yet.

What to ask a prospective MSP about co-managed

If you’re talking to MSPs about co-managed IT, here are the questions that actually surface whether they know what they’re doing. Most won’t.

1. How do you handle the relationship with the internal IT person, specifically? If they don’t have a clear answer involving early involvement and explicit scope, they’ve never properly done this.
2. What does the responsibility split look like, written down? They should be able to show you something close to the table above. If it’s vague, walk away.
3. How do you escalate when our internal IT person isn’t available? Co-managed only works if the MSP can act independently in defined areas. If everything has to route through the internal person, you don’t have co-managed, you have a slow help desk.
4. What happens if our internal IT person leaves? A good MSP can absorb the full scope within 30 days. If they say “we’d need to re-scope significantly,” they don’t have the depth.
5. Where’s your after-hours coverage actually based? “Offshore partner” usually means a slow, scripted response. We run our NOC out of Tecoma with 13 engineers, all Australian-employed. Different model, different result.

If you’d like to read more on our broader service approach, see managed IT services in Melbourne and our dedicated co-managed IT support page for how we structure these engagements. The IT support overview covers what day-to-day support looks like across both models.

Common failure modes — a checklist

If you do go co-managed, watch for these. Any of them showing up in the first six months means the engagement needs a reset conversation, not a quiet drift into dysfunction.

• Documentation in two places, neither complete.
• The internal IT person hasn’t logged into the MSP’s ticketing or documentation system in 30+ days.
• The MSP is asking the same access questions repeatedly because credentials aren’t being shared.
• Tickets are being closed by one team that the other team should have owned.
• Leadership is getting different stories from the two teams about the same incident.
• Either team is doing work outside their scope without telling the other.
• The internal IT person has stopped attending the monthly review meeting.
• Alerts are firing but nobody’s acknowledging them within SLA.

None of these are fatal individually. All of them are signals. Fix them when they’re small.

Frequently asked questions

Is co-managed IT cheaper than hiring a second internal IT person?

Almost always, yes — at least for the first 12 to 24 months. A second internal hire is $110k+ in salary plus on-costs, recruitment, equipment and ramp-up time, and you still don’t get true 24/7 cover from one extra person. Co-managed gets you specialist coverage, after-hours, and redundancy for less. Past a certain headcount (usually 250+) the maths shifts and a second internal hire becomes worth it alongside the MSP.

Will our internal IT person resent us bringing in an MSP?

Possibly, especially if they weren’t involved in the decision. The fix is to bring them in early, be honest about the scope, and make sure the work they keep is the work they actually enjoy. We’ve had internal IT people who initially resisted become the biggest advocates within six months — but only because leadership handled the introduction well.

What if our internal IT person resigns after we sign up?

A well-structured co-managed engagement can absorb the full scope within 30 days, because the MSP already owns the infrastructure, security, after-hours and documentation. You’d lose user-facing support and project capacity temporarily — but you wouldn’t have a crisis. That continuity is one of the main reasons businesses go co-managed in the first place.

How quickly can co-managed be set up?

Discovery and scoping takes about two weeks for a typical 100-staff Melbourne SME. Transition — getting the MSP onto the environment, documentation done, monitoring deployed, runbooks written — takes another 30 to 45 days. Most clients are running steady-state within 8 to 10 weeks of signing.

Do you require us to use specific tools?

For things we own (RMM, EDR, backup, monitoring, ticketing), yes — we run a consistent stack so our engineers can move fast across clients without constantly relearning environments. For things the business owns (line-of-business apps, productivity suites, internal tools), the internal team keeps choosing those.

Where to from here

Co-managed IT is the right answer for a real chunk of Melbourne SMEs in the 50-to-300 staff range, and the wrong answer for plenty of others. The difference comes down to the operational split, the politics, and whether the internal IT person is bought in. Tooling matters far less than most MSPs will admit.

If you’ve got an internal IT person and you’re wondering whether co-managed makes sense for your business, have a chat with us. We’ll tell you honestly whether it’s the right fit — including the cases where it isn’t and you’d be better off with fully managed or staying as you are. You can reach us via the contact page or on 1300 028 324. No sales pressure, no obligation, just a straight conversation about your setup.