Tas Gray on Automation First MSP Scale and Why Relevance Now Depends on Operational Discipline
After 30 years building and scaling MSPs in Australia, Nick and I can tell you exactly where most service delivery pain comes from. It is not a lack of tools. It is inconsistency. One client is sold one way, another is delivered another way, and suddenly your PSA is full of exceptions, your technicians are making judgement calls they should never have to make, and your margins quietly bleed out through rework. In this episode of MSP Mastery: Ctrl Alt Deliver, we sat down with Tas Gray, founder of Axiom IT, to unpack what it looks like when an MSP commits to an automation first mindset properly. Not as a gimmick, not as a handful of scripts, but as an operating model designed for scale. Tas has built a business that keeps headcount lean, onboards quickly, delivers consistently, and runs without the owner needing to be physically present in the office. His story is a useful case study because it reinforces what we have seen repeatedly in thriving MSPs. Standardise first, then automate, then scale.
MSP Mastery
5/14/20268 min read
Tas Gray on automation first MSP scale and why relevance now depends on operational discipline
After 30 years building and scaling MSPs in Australia, Nick and I can tell you exactly where most service delivery pain comes from. It is not a lack of tools. It is inconsistency. One client is sold one way, another is delivered another way, and suddenly your PSA is full of exceptions, your technicians are making judgement calls they should never have to make, and your margins quietly bleed out through rework.
In this episode of MSP Mastery: Ctrl Alt Deliver, we sat down with Tas Gray, founder of Axiom IT, to unpack what it looks like when an MSP commits to an automation first mindset properly. Not as a gimmick, not as a handful of scripts, but as an operating model designed for scale. Tas has built a business that keeps headcount lean, onboards quickly, delivers consistently, and runs without the owner needing to be physically present in the office. His story is a useful case study because it reinforces what we have seen repeatedly in thriving MSPs. Standardise first, then automate, then scale.
Standardisation is the real foundation, not automation
The MSP Mastery view on why automation fails in messy businesses
Most MSPs try to automate too early. They bolt automation onto a service catalogue that is not clearly defined, across a client base that is not aligned, with delivery teams who are still making it up as they go. That is not automation, that is chaos at speed. When we see automation initiatives stall, it is almost always because the underlying service is not consistent enough to automate.
Our framework is simple. If you cannot deliver it the same way every time, you cannot automate it responsibly. Standardisation is not about being rigid. It is about removing decision fatigue and removing preventable variation so your team can perform.
How Tas built consistency by learning to say no
Tas was candid about the early years of Axiom IT. Like many founders, he and his business partner started by saying yes to everything, then slowly realised that every exception became a permanent tax on delivery. The turning point was not a new tool. It was a discipline shift. Tas talked about moving toward a customer base where the vast majority of what they do is consistent across clients, which then makes automation dramatically easier.
That is the lesson we want MSP owners to sit with. You cannot automate your way out of a bespoke service model. You have to choose the model first. Tas described the internal tension many of you will recognise, where sales wants flexibility and delivery wants repeatability. The businesses that scale resolve that tension by designing an offering they can deliver well, then selling that offer confidently.
Automating the client experience, not just the technician workload
Why the best automation improves the customer journey
We have always believed that service delivery maturity shows up in client experience first. Not in your internal dashboards. Clients do not care that a ticket is in the right queue. They care that outcomes happen quickly, consistently, and with minimal friction. When you automate from the client perspective, you are not just saving technician minutes. You are creating trust.
Too many MSPs treat onboarding, offboarding, and access changes as annoying tickets to be cleared. Mature MSPs treat them as moments that shape the relationship. These are the moments where clients decide whether you are organised, whether you are safe, and whether you are worth your fee.
Tas as a case study in self service done properly
Tas shared that Axiom IT built a client portal where customers can submit standard service requests such as onboarding, offboarding, temporarily delegating mailbox access, or blocking sign in to an account. The automation runs behind the scenes, reducing reliance on email threads and reducing the flood of notifications that come out of a PSA when a process is stitched together manually.
What we like about this is not the portal itself. It is the intent. A portal forces clarity. It forces naming conventions, it forces required fields, it forces the client to think through what they are asking for, and it forces your MSP to define the process. It also protects your team from having to interpret vague requests like John starts next week, sort it out, with no surname, no start date, and no clear access requirements.
Tas also highlighted an important point that aligns with our own experience. Even small inconsistencies, like how an email address is formatted, can turn into long term operational drag. Standardised inputs create standardised outputs, and that is where quality becomes scalable.
The hero moment: offboarding decisions removed from the help desk
Why offboarding is where most MSPs leak risk
If we were forced to nominate one recurring ticket type that exposes operational maturity, it would be offboarding. Offboarding is repetitive, time consuming, and full of risk. It touches identity, access, data retention, licensing, and client governance. It also lands at the worst times, often urgent, often emotional, sometimes involving termination, and usually with incomplete instructions.
Nick raised a scenario we have both seen many times. A client says delete everything, then years later a legal matter appears and they need historical emails. The MSP ends up in an awkward position, even if they followed instructions, because the client remembers the outcome, not the decision trail.
How Tas designed the system to protect both parties
Tas described an approach we strongly agree with. Do not leave these decisions to individual technicians. Make the decision once at the leadership level, bake it into the automated process, and deliver it the same way every time. This removes the situation where one technician converts a mailbox to a shared mailbox, another deletes it, and a third archives it differently, leaving you with inconsistent outcomes and client confusion.
Axiom IT has built logic into their portal so that if an email address is entered that matches a previously offboarded user, the system prompts the client to reactivate rather than create from scratch. That is a small detail, but it is a brilliant example of designing for reality. People return. Contractors cycle. Organisational memory is messy. Your process needs to anticipate that without relying on a technician remembering what happened six months ago.
Tas also shared that their default approach includes converting mailboxes to shared mailboxes and using backup with unlimited retention. The key lesson here is not the specific tools. It is the layered thinking. A well designed offboarding process reduces the chance of irreversible decisions being made in a rush. It also reduces future disputes because the process is consistent and defensible.
Lean headcount as an outcome of maturity, not a badge of honour
What we have learned about profitability and resourcing
Every MSP owner has a story about being busy but not profitable. Busyness is not the goal. Profitability funds stability, staff development, better client experience, and leadership capacity. One of the biggest myths we see is that growth automatically requires proportionate headcount growth. In mature businesses, the relationship between revenue and headcount changes over time because processes improve and delivery becomes repeatable.
That does not mean people are not important. It means you protect your people by removing the work that should not require human effort.
Tas perspective on automation decisions and the juice being worth the squeeze
Tas explained that they use a simple prioritisation approach that weighs time savings, error reduction, and the impact of mistakes against the difficulty of implementing automation. That is exactly how we advise MSPs to think. Automate what is frequent, what is high risk, and what requires consistent outcomes. Be careful about spending months automating something that happens once every two years, especially when the environment will change before the automation pays back.
We also liked that Tas embedded the mindset into the team early, encouraging technicians to flag repetitive tasks for automation, and then eventually dedicating a role to automation work using a structured delivery method. That transition is a hallmark of an MSP moving from ad hoc improvement to deliberate operational engineering.
Remote ownership only works when the operating system is real
The MSP Mastery reality check on remote leadership
There is a romantic version of running an MSP from anywhere, and then there is the operational version. The romantic version is a laptop and a beach. The operational version is clear agreements, documented standards, predictable rhythms, and a leadership team that does not rely on the owner to unblock every decision.
Nick and I have seen both. The difference is discipline. Remote work does not create maturity. It reveals whether you already had it.
Tas move to Jakarta and what it signals about the business
Tas shared that the move from Melbourne to Jakarta required very little change because the business had already adapted to a remote model during COVID, and because the service model did not depend on him being physically present. He described face to face meetings as increasingly rare and not essential for most clients, which aligns with what we see across the market.
What matters here is not whether you are in the office. It is whether your business can operate without you being the connective tissue. If your clients need you specifically in the room to feel secure, that is usually a sign your service delivery and account management functions are not mature enough yet. This episode is a reminder that remote ownership is achievable when you have done the unglamorous work first.
Tas also described a streamlined approach to hardware procurement and deployment, using a single supplier for procurement and imaging, then drop shipping to clients and enrolling via Intune. Again, the insight is not the vendor name. It is the consistency of the workflow. The more steps you remove, the less you rely on heroics and the less you rely on physical logistics that slow everything down.
AI and automation are now a relevance issue, not a nice to have
Our view on what MSPs risk if they do nothing
Every industry has moments where the baseline shifts. AI and automation are shifting the baseline for service businesses. The risk is not that your existing clients leave tomorrow. The risk is that new prospects stop seeing you as modern, efficient, and valuable. Relevance is a competitive advantage, and irrelevance is a slow business death.
If your MSP still relies on people to do repetitive work manually, you will feel it in margins first. Then you will feel it in pricing pressure. Then you will feel it in staff burnout and churn. Finally you will feel it in growth stalling.
Tas warning on efficiency, cost, and the speed of change
Tas was direct. AI and automation lift efficiency and drive costs down, and businesses are already looking for meaningful ways to cut costs. In his view, MSPs that do not adapt will either be priced out of the market or become unprofitable.
Nick also shared a practical moment from this episode that brought the point home, describing how Tas introduced him to Claude Code and helped him move from hours of frustrating trial and error to a working outcome in minutes. That is a small story, but it illustrates the broader shift. The tools are getting more powerful, and the gap between adopters and non adopters is widening quickly.
Closing thoughts from Jeni and Nick
This episode reinforces what we have been teaching MSP owners for decades. Scale is built on standardisation, clarity, and consistent execution. Automation then becomes a natural extension of a well designed service, not a desperate attempt to rescue an inconsistent delivery model. Tas Gray and Axiom IT are a strong example of what happens when you commit to that path and keep committing, even when it requires saying no, simplifying the offer, and removing human decisions from places where they create risk.
If this episode of MSP Mastery: Ctrl Alt Deliver prompted you to rethink how your MSP is operating, take a moment to be honest about where inconsistency is costing you margin and energy. Then consider where standardisation would unlock automation, and where automation would unlock a better client experience.
If you would like to talk it through with people who have built and scaled MSPs over 30 years, reach out to Nick and me and the MSP Mastery team. We are always up for a practical conversation about making your business work better for you, your team, and your clients.
