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 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.

Episode 17 warps up the breakdown of version 2.21 and begins 2.212, highlighting impactful updates across billing, SLA visibility, and ticket management. The team dives into major improvements like dynamic ticket filters, default billing templates, and better billing tab access controls. This episode is especially useful for MSPs looking to tighten billing accuracy, improve reporting visibility, and streamline ticket workflows.
Watch Now: By the [run]Book: Episode 17
For easier tracking, check out haloreleases.remmy.dev to filter and search HaloPSA updates by ID, version, and keyword.
The Billing tab is now visible to agents without requiring full billing permissions, with actions locked based on access.
Tickets on hold can now be included in SLA breached filters.
You can now define a default billing template applied automatically when creating a new customer.
Dynamic filters can now be used on ticket lists for more flexible querying.
This helps keep recurring invoices aligned when item third-party IDs change.
Recurring invoices now get the same due date option already available at customer setup.
This adds more control to portal-based approval workflows.
This extends alternate invoicing behavior down to the site level.
This helps prevent tickets from disappearing into inactive-agent limbo.
More ticket list criteria means more practical operational views.
This update improves the ManageEngine Endpoint Central integration.
Halo now supports generic OpenID Connect SSO.
You can now duplicate item bundles instead of rebuilding them manually.
This adds more naming flexibility to the UI.
This makes SLA breach reporting more honest and more useful.
A major improvement for standard billing configuration.
This adds more flexibility to meter-driven recurring billing.
Dynamic ticket filters add a much stronger filtering experience.
Cloning custom fields speeds up admin work.
This update improves chart label readability.
This update refines the encryption update workflow.
This improves call handling context.
This gives more control over quantity precision.
This improves flexibility when linking work records from sales orders.
This adds better billing visibility without fully exposing billing controls.
Spreadsheet imports can now target existing tickets by ID.
A small UI cleanup on the ticket details pane.
This adds flexibility for co-managed support models.
This improves control over CSP user mapping behavior.
This adds clarification around tax rate usage in Xero-linked setups.
This makes Avalara tenant cleanup easier from the client billing tab.
This is a strong automation improvement.
Custom table row deletion gets more precise.
This cleans up recurring invoice visibility.
This is a documentation/config clarity improvement.
Ticket rule assignment now supports more role-based options.
Approval rule logic gets another useful condition.
Supplier-related configuration gets more flexible.
Project templates now get more dynamic input from sales-order-driven creation.
This expands visibility in quote and sales order line views.
This makes customer/site control more precise.
The API docs continue to improve.
This improves ticket logging layout flexibility in the agent app.
This is an important reliability improvement for payment processing.
This adds more flexibility when services are generated from assets.
This improves parent/child ticket data behavior.
Third-party ID linking is now available across more entities.
Query Builder gets another field for reporting logic.
This expands visibility of account/prospect records in top-level views.
Custom buttons now get access control.
This adds polish to the opportunity creation experience.
This is one of the biggest integration-facing updates in the episode.