Connect technical work to a scalable service business.
35 min3 lessons3 retrieval drills
The promise
What you will be able to do by the end of this module
Ask the one reconciliation question that exposes margin leakage in almost every MSP, and know when to skip this entire conversation.
Ask the one reconciliation question that exposes margin leakage in almost every MSP.
Use parent-and-child policy structure to run one service standard across many client estates.
Date a stale objection — ITAM and PSA reached general availability in 12.0 — and reopen a lost evaluation.
Attack the manual reconciliation seam rather than attacking the incumbent PSA.
Recognise when to skip this entire conversation because you are talking to enterprise IT, not a service provider.
Start from what you already know
For an MSP the platform is not a cost centre, it is the thing the invoice is derived from. That changes which questions matter — and for an enterprise buyer, this whole topic is noise.
01
Category fluency
RMM runs technology; PSA runs delivery
RMM observes and manages client technology. PSA organizes service work, time, knowledge, and business process. Billing turns governed delivery and quantities into financial workflow.
An MSP needs reusable policy and automation without losing client boundaries. Discovery should cover tenancy, delegation, branding, service catalog, exceptions, security roles, integrations, and reporting.
For an MSP, product value appears as fewer manual touches, consistent service, faster technician onboarding, accurate billable quantities, and room to support more endpoints without proportional headcount.
Field move
Translate a device condition into automation, ticket evidence, time capture, documentation, and billing impact.
Each item is tagged with how far it can be trusted. Verified means checked against official documentation; field means it is our recommendation, not a vendor claim; unpublished means NinjaOne does not state it at all.
Multi-tenancy is expressed through the organization hierarchy
verified
The same Organization → Location → Device model that governs an enterprise governs a client estate. Delegation and scope are the same primitives, which is why one hierarchy discussion serves both audiences.
Policy inheritance is how you scale a standard across clients
field
A parent policy is your service standard; per-client children carry only the deviations. That structure is what makes a hundred-client estate auditable rather than a hundred snowflakes.
ITAM and PSA reached general availability in NinjaOne 12.0
verified
Relevant when a customer's understanding of the platform predates that release — their objection may be about a version that no longer reflects the product.
The billable count and the managed count should be one number
field
When device counts are maintained separately for operations and billing, they diverge, and the divergence is always in the customer's favour. This is the highest-value question in an MSP discovery.
Discovery
Ask these, then listen
“Is your billable device count the same number as your managed device count?”
Listen for: Any hesitation is margin leaking. This one question often carries the meeting.
“How long does month-end billing take, and who does it?”
Listen for: Manual reconciliation hours convert directly to a business case.
“Do you know your margin per client, this month?”
Listen for: 'At year end' means they are flying blind on the thing that determines the business.
Demo path
Three moves, in this order
1
The same standard policy applied across two client organizations.
“One standard, per-client deviation, still auditable.”
2
Ticket time landing against a contract.
“The work and the invoice come from the same record.”
3
Asset counts feeding billing.
“One number, not two people maintaining two spreadsheets.”
Objection handling
What they say, what you say, how you prove it
“We already have a PSA.”
Then the question is the seam. Where do device counts, ticket time, and contract terms reconcile today, and who owns that reconciliation?
Proof method: The seam is where the hours go. Do not attack their PSA; attack the manual join.
“We looked at NinjaOne before and it did not have this.”
When did you look? ITAM and PSA went generally available in 12.0. If your evaluation predates that, you evaluated a different product.
Proof method: Dating their objection is often enough to reopen the deal.
Where SEs blow it
Do not say these
Skip this module entirely for enterprise IT. Drawing an MSP billing layer for a corporate team signals you do not know your audience.
Keep PSA distinct from NinjaOne's own professional services. They are different things with confusingly similar names.
Do not assume an MSP wants to replace their PSA. Most want the reconciliation fixed, not a migration.
From NinjaOne's channel
Watch it explained
Short clips from NinjaOne's own channel that reinforce the mechanics above. Each one says why it is here and what it backs up. These are supporting context, not product demonstrations — the sourced claims stay in the mechanics section.
Why this is here: Where the evidence layer becomes a client-facing business conversation.Watch on YouTube ↗Why this is here: Ticket time is the input to both service delivery and the invoice — the reconciliation question.Watch on YouTube ↗Why this is here: Translating technical state into the language the person signing the contract uses.Watch on YouTube ↗Why this is here: The consolidation argument, honestly framed — capability preserved, not features counted.Watch on YouTube ↗
Retrieval practice
Rapid fire
Answer aloud before opening each response.
01PSA versus RMM?+
PSA governs the service business; RMM governs managed devices and automation.
02Why integrate ITAM with billing?+
Asset and license quantities can reduce manual counting and reconciliation.
03Core MSP design tension?+
Reuse standards across tenants while preserving client isolation, exceptions, and reporting.