By
Mendy Green
June 9, 2021
•
20 min read
Business

In any business where you’re not billing Time and Materials, the amount of time you spend on a project directly correlates to how profitable you are. In an MSP, this applies even more. MSP Businesses were designed years ahead of their time, bringing into practice concepts such as recurring revenue, outsourcing, efficient resources, and more; before people even realized the value. It’s the reason that today the MSP Businesses are blowing up with everyone you meet starting their own. Unfortunately, there’s a complex side to the framework of an MSP that is very often overlooked, especially by those just starting out.
Let’s discuss how the MSP business model is built. MSPs pitch to their prospective clients that they can provide the same level (or often times better) IT Services to their organization than they themselves can find if they go with someone internally. They ask for less money, and offer a bigger team with greater experience. These same MSPs then have to turn around and hire the same people that would have been hired directly, and not just one, but two or three or more depending on the size of the MSP.
MSPs have to pay the same salary with a smaller budget. How can these numbers possibly work?
This is where efficient resources come in; an MSP needs to stack multiple clients reusing the same resources for each client so that together all the clients combined pay enough money for the MSP to pay the technicians salary and make a profit. The income also needs to cover all base expenses of the MSP which includes infrastructure such as an RMM, PSA, Email, Phones, over-night team for emergencies and so on.
With an internal IT resource, that resource would be solely focused on the business they were working for and getting paid a full salary of say $52k/year, now the same resource at an MSP is getting paid $52k/year and needs to stay on top of not one company IT needs, but actually 3 or 4 (or more depending on the contract size of each). This kind of expectation is unreasonable and when maintained results in high-stress work environments and eventual burn out for the technician. The saying “trial by fire” is very applicable to the technicians who work at an MSP. They are under constant barrage of tickets and stress, jumping from company to company each ticket wildly different from the next. This makes them unusually skilled and also rapidly exposes them to a wide range of experience they may not have received working for just one company. A good MSP technician of the lowest tier can easily go head to head in ability (if not knowledge) to a mid-tier internal IT resource.
Now keep in mind that when MSPs started we were a new phenomenon. There was no standard to follow, no existing business to copy, except for the existing internal IT department within a Company. We didn’t know what kind of pay structure was fair to offer a Tier 1 or Tier 2 technician because there was no “average pay” metric. The only thing we did know is that we are building a business with a stress on smaller dollar amounts per client, and more total clients. This means what we paid our technicians had to be less too, or that we keep the MSP as lean as possible with only the amount of technicians truly needed. Following the 80/20 rule we determined that 80% of the time with our clients running smoothly we would be fine and only 20% of the time when some kind “perfect storm” would occur we would need to motivate our technicians to put in more effort (or what was generally called “figure something out”).
What’s being described is not a sustainable long term plan. Simon Sinek likes to stress that business is an Infinite Game and that those who are not playing by those rules are doomed to failure eventually. The only way to stay in the game is by having resources, and the will to keep playing. We’ve already established that MSPs do not have the same pockets as a normal business, not without drastically imposing upon “will”, our employees, making them work in stressful environments and constantly being battered by the next broken issue.
The fix for this is easy, and its an iteration of what we already started. Efficient use of resources. Efficiency can help us spend less time per ticket, less time per client, and improve our technicians stress in the environment. There are two side to the efficient use of resources, one of which we already started (Sharing resources among companies) but the other is often overlooked “Work load management”. If we can make our work load efficient we can easily improve upon all the issues we just brought up. Here are some ideas that can be used to help facilitate the efficient workload.
Efficient resources is way more than just sharing resources. Making your workload efficient is just as important. Remember how profitable you are directly correlates to how efficient you can be
Remember, in the MSP business time isn’t a loss of potential profit, its actual profit lost as your contracted rate is the same every month. Automation and bulk actions are extremely important as the less time you spend doing something the more your Per Hour amount goes up.

Episode 20 of By the [run]Book dives into HaloPSA v2.214 with a mix of practical improvements and some quirky additions. Connor and Mendy walk through everything from new dollar variables and asset controls to Avalara fixes and portal enhancements—highlighting what actually matters for day-to-day MSP operations. This episode is especially useful for MSPs refining workflows, automation, and reporting accuracy in Halo.
Watch Now: By the [run]Book: Episode 20
For easier tracking, check out haloreleases.remmy.dev to filter and search HaloPSA updates by ID, version, and keyword.
Mendy and Connor noted this was very useful.
Highlighted during the user action demo as a practical workflow improvement.
Called out as a genuinely useful UI improvement.
Allows more flexibility in how incoming emails are matched to tickets.
Enables automation of asset configuration through API usage.
Introduces a new variable to output custom fields in Q&A format.
Improves visibility into asset changes over time.
Returns the email address of the user associated with a purchase order.
Enhances usability and visibility of search results in the portal.
Provides control over configuration synchronization.
Ensures correct popup behavior when multiple rules trigger.
Makes ticket source available for reporting and filtering.
Adds safeguards when configuring email matching tags.
Allows distribution lists to target all email addresses tied to a user.
Improves clarity in Avalara transaction records.
Adds control over visibility of user actions in the portal.
Improves flexibility when using Accounts and Prospects.
Enables dynamic fields based on asset lifecycle status.
Ensures asset tagging consistency during stock processes.
Adds control over Avalara synchronization scope.
Allows a predefined score for surveys.
Improves visibility when prorating billing items.
Automatically generates a ticket alongside sales orders.
Allows column width customization in list views.
Changes ordering of lists in the team view.
Adds asset status as a usable variable in buttons.
Improves flexibility when viewing lists.
Allows visual customization of buttons.
Enables distribution lists based on ticket criteria.
Adds control over forecast data ranges.
Enhances performance of Azure/Entra sync.
Improves visibility of ticket closure information.
Optimizes webhook performance and payload handling.
Refines permissions for asset management.

Episode 19 walks through HaloPSA v2.212 and v2.214, covering a wide range of quality-of-life improvements, admin controls, and workflow enhancements. Connor and Robbie highlight updates around ticket forms, invoicing, templates, and automation, making this especially useful for MSPs looking to tighten processes and improve day-to-day efficiency.
Watch Now: By the [run]Book: Episode 19
For easier tracking, check out haloreleases.remmy.dev to filter and search HaloPSA updates by ID, version, and keyword.
Allows assets to be linked directly to a client instead of only via a site.
Improves tracking of report usage across dashboards.
Adds control over end-user assignment in templates.
Prevents actions on tickets for stopped clients or sites.
Allows updating custom fields directly via actions.
Prevents approval of expired quotes.
Adds variables for original customer addresses.
Ensures hidden fields do not retain values.
Adds advanced relative date filtering.
Adds preview functionality for templates.
Allows editing of existing meter readings.
Improves grouping of invoice items.
Enables merging duplicate assets.
Displays number of related tickets.
Enhances monitoring integration mapping.
Adds more control to purchase order lifecycle.
Enables workflows triggered by agent emails.
Adds mapping and geolocation features.
Introduces guided project setup.
Allows updating ticket fields post-creation in chat.
Prevents deletion of populated top-level structures.
Improves timesheet usability.
Fixes inconsistent quote PDF behavior.
Aligns quote email behavior with configuration.
Adds access to billing profiles from invoice screen.
Allows use of quote data in actions.
Adds new automation trigger.
Adds rich text support for asset fields.
Prevents closure when tasks remain open.
Adds approvals to activity feed.
Removes agent login option from portal.
Adds ordering control to lookup codes.
Adds planning field to releases.
Enables guided onboarding tools.
Adds note field to consignment lines.
Expands team visibility.
Extends accessibility tools to main app.
Displays previous invoice values.
Exposes billing data to API.
Adds search to selection fields.
Aligns call screen logic with ticket settings.
Links credit lines to original sales orders.
Improves invoice ID handling.
Introduces role-based API identity.

In this episode of By the Runbook, the team continues through the HaloPSA 2.212 release notes and spends time unpacking what several of these changes actually mean in practice. The conversation covers workflow design, mail campaigns, ticket views, reporting, and automation behavior, with especially useful commentary for MSPs trying to decide what to enable, what to ignore, and what to be careful with.
Watch Now: By the [run]Book: Episode 18
For easier tracking, check out haloreleases.remmy.dev to filter and search HaloPSA updates by ID, version, and keyword.
Check out MSP Blueprint for info on runbooks: MSPBlueprint
This allows the ticket screen to automatically refresh when a background automation completes.
Expands qualification matching to include custom field criteria.
Adds delayed and retry-based webhook processing options.
This change limits the available “From” addresses on a ticket action to mailboxes the assigned team can actually access.
Adds Email Address as another attribute option for follower behavior on the portal.
Allows changes to Mail Campaigns after they have started.
Restricts pipeline stages based on opportunity type.
Adds webhook processing options including delayed and retry handling.
Adds the ability to hide tickets from the change calendar.
Adds Service Users as a selectable option in distribution and user lists.
Allows campaigns to be sent from sales mailboxes.
Adds a warning when an action email will fail.
Adds asset relationship mapping during SQL imports.
Adds an isRunning field to asset discovery.
Expands qualification matching with custom field rules.
Allows ticket view to auto-refresh after automation runs.
Adds ability to update currency values on quotes.
Requires comments for negative KB feedback.
Adds control for showing nested tickets.
Enhances AI reporting capabilities.
Restricts KB edits to owners only.
Adds translation support in the portal.
Adds secondary MAC address support.
Adds character limits to text fields.
Adds more fields for OLA and rule reporting.
Prevents approvals from email replies.
Extends field copying to deeper ticket levels.
Adds primary asset as a runbook condition.
Adds AgentID variable for lookups.
Adds reporting changes to config tracking.
Adds filter profiles to child ticket views.
Adds more configuration options to other open tickets view.