EP. 60: Delano Collins on Data Driven Decisions, Automation and Building a More Profitable MSP
When an MSP owner tells us they need more automation, Nick and I usually start with a different question: can you trust the information your business is producing? Over 30 years of building and scaling an Australian MSP, we learned that adding technology to an unclear process rarely creates clarity. It simply allows the confusion to travel faster. The real opportunity is not to automate everything. It is to understand where effort is being wasted, where service delivery is slipping and where apparently healthy client relationships are quietly consuming your margin. That requires reliable data, clear ownership and a team that understands why those things matter. In this episode of MSP Mastery Podcast, returning guest Delano Collins, Chief Operating Officer at Electronic Office, shared how his team has been developing that foundation. His experience reinforces a principle Nick and I keep coming back to: operational maturity comes from making better decisions consistently, not collecting more tools.
MSP Mastery
10/12/20265 min read
When an MSP owner tells us they need more automation, Nick and I usually start with a different question: can you trust the information your business is producing? Over 30 years of building and scaling an Australian MSP, we learned that adding technology to an unclear process rarely creates clarity. It simply allows the confusion to travel faster.
The real opportunity is not to automate everything. It is to understand where effort is being wasted, where service delivery is slipping and where apparently healthy client relationships are quietly consuming your margin. That requires reliable data, clear ownership and a team that understands why those things matter.
In this episode of MSP Mastery Podcast, returning guest Delano Collins, Chief Operating Officer at Electronic Office, shared how his team has been developing that foundation. His experience reinforces a principle Nick and I keep coming back to: operational maturity comes from making better decisions consistently, not collecting more tools.
Make the Numbers Meaningful Before Making Them Visible
Nick and I have seen that dashboards only change behaviour when people understand what the numbers mean. A screen full of red indicators might attract attention, but it does not automatically explain what needs to happen next. Leaders must connect each measure to a client outcome or a business consequence.
At Electronic Office, Delano wanted to move beyond emailed reports towards visible dashboards showing service performance. His team began with a small selection of measures, including ticket resolution, ticket ageing and engineer utilisation, then added others as their understanding developed.
The important part was not the display itself. It was the coaching behind it. Delano explained how accurate time entry and consistent processes produced information the business could actually use. Sharing those results helped team members understand the value of their own contribution.
Nick recognised this from our experience. Once he explained how an activity affected the client or the business, rather than simply instructing technicians to follow a process, their behaviour changed.
For MSP owners, the lesson is to make accurate information useful to the people entering it. Show your team what their records reveal and what decisions those records support. Data quality improves when the process has a visible purpose, not just a compliance requirement.
Measure the Whole Cost of Serving a Client
One of the most dangerous assumptions in an MSP is that technical labour tells the whole profitability story. Nick and I know that a managed agreement can look reasonable until you include the account conversations, purchasing administration, repeated follow ups and other effort surrounding it.
Delano described combining information from MSP Bots, ConnectWise, financial reports and management context, then using Copilot to help organise and analyse it. Crucially, he reviewed and verified the results before building a priority list.
That exercise identified specific actions across 17 clients, including reviewing written off time, excessive labour, pricing for embedded engineers and product discounts. Instead of treating low margins as one general problem, the team could assign different issues to the people responsible for resolving them.
Electronic Office also records client related effort beyond engineering. Delano gave the example of a workstation order requiring repeated attention because approvals, payments and changing prices created delays. Without recording that work, the operational cost would remain hidden.
Nick’s perspective was clear: industry benchmarks can provide a starting point, but they cannot fully account for your client mix, team structure or service model.
Do not copy another MSP’s ratio and assume it describes your business. Establish consistent time categories, understand what your figures include and investigate the relationships consuming disproportionate effort. Better pricing decisions begin with an honest picture of delivery costs.
When Automation Fails, Examine the Process Beneath It
Nick and I have both learned that a sensible automation can still produce a poor client experience. The rule may work exactly as configured while the people, ticket statuses or customer expectations feeding it remain inconsistent.
Delano shared a useful example. Electronic Office introduced an automated process for tickets awaiting a client response. It sent reminders before closing the ticket after a specified period.
The problem was that some engineers used the waiting status incorrectly. Clients received messages saying the MSP was waiting for them when they were actually waiting for the MSP. Understandably, those clients were frustrated.
The team investigated, tried adjustments and ultimately stopped using that status. A dispatcher continued following up with clients and deciding when closure was appropriate.
This was not evidence that automation had no value. It showed that introducing a rule and sending an explanatory email had not established reliable use of the underlying process.
Nick shared how our own reminder process needed adjustment after consultation with hospitals whose staff worked different shift patterns. A short response window did not fit their operating reality.
Before automating a client communication, confirm what triggers it, who controls that trigger and whether the timing suits the client. Test realistic exceptions. A cleaner ticket board is not a success if the client feels blamed or abandoned.
Protect the Service Desk From Becoming a Dumping Ground
Service delivery maturity requires more than closing tickets quickly. Nick and I have always treated the service desk as a function with a defined purpose, not a holding area for every unresolved client requirement.
During this episode, Delano described clients declining projects and then submitting the same work through support. His response was to coach engineers to raise the issue with their manager rather than negotiate scope themselves. Leadership could then explain why the work needed a properly structured project.
That distinction protects both profitability and outcomes. A project delivered through scattered service desk attention may appear cheaper, but interruptions and delays can make the experience worse for everyone involved.
Nick also shared a practical measure we used: tickets with no activity. Rather than only looking at total age, we monitored tickets without time entries, updates or notes for roughly two business days. The coordinator, manager or team leader then asked what was happening.
This created a regular intervention before forgotten work became a longstanding problem.
For owners and service managers, the takeaway is to separate unresolved support issues from future improvements and project requirements. Give engineers a clear escalation path, review inactivity and make someone accountable for the next action. Do not leave commercial conversations sitting in a technician’s queue indefinitely.
Turn Improvement Into a Leadership Discipline
Nick and I see automation as an ongoing management responsibility, not an occasional technical project. Without a clear business problem and someone accountable for progress, it is easy to replace implementation effort with enthusiasm for the next product.
Delano’s approach reinforced this. His team began with data visibility, then developed reminders and controls around specific behaviours. One example detected project time incorrectly recorded against managed agreements, prompting correction and escalating unresolved entries before billing.
The value was not simply saving someone from sending a reminder. It was protecting the integrity of the information used to manage the business.
In our current business, Nick had an EOS quarterly priority to automate five problem areas. That commitment encouraged me and our marketing colleague, Bagus, to identify friction in our own processes. One result was an internal application supporting the podcast workflow, from guest coordination through production and release.
The lesson is to give improvement a place in your leadership rhythm. Identify the problem, assign ownership and review whether the change genuinely helps.
That discipline must also include responsible AI use. Nick emphasised the importance of an AI policy, appropriate handling of client information and educating the team. Delano’s financial analysis retained human verification. Faster output does not remove leadership accountability, and an internal prototype should not be mistaken for a finished, externally offered product.
Build Confidence in the Business You Already Have
The strongest message from this episode is that reliable automation grows from reliable operations. Nick and I would encourage any MSP owner to start by examining the quality of their data, the full cost of serving clients and the clarity of their service processes.
Choose a problem worth solving, involve the people doing the work and build confidence through practical improvements. Keep human judgement involved, particularly where client communication, commercial decisions or sensitive information are concerned.
If these questions reveal gaps in your own business, connect with Nick, me and the MSP Mastery team at mspmastery.blog. We would love to continue the conversation about building a more profitable, capable and fulfilling MSP.
