MSP & IT ServiceGlossary

An outsourced IT department — a company that manages your technology proactively for a flat monthly fee. The MSP is responsible for keeping things working, handling support tickets, applying updates, and advising on what to buy next.

Why it matters: Hiring an MSP usually costs less than employing one full-time IT person, gives access to a broader skill set (security, cloud, networking, compliance), and shifts IT from a reactive cost center to a predictable line item.

Related: MSSP, RMM, PSA, Managed Services, Co-managed IT

Like an MSP but specialized in cybersecurity — runs your SOC, manages your SIEM, monitors threats 24/7, responds to incidents. Often layered on top of (or built into) a traditional MSP relationship.

Why it matters: Cybersecurity demands depth that general-purpose MSPs may not have in-house. An MSSP fills that gap — particularly important for regulated industries, businesses with cyber-insurance requirements, or organizations with high-value targets.

Related: MSP, SOC, SIEM, MDR

An arrangement where your internal IT team works alongside an external MSP — you keep day-to-day support and institutional knowledge in-house, the MSP provides depth (specialized expertise, after-hours coverage, vacation backup, project resources) on demand.

Why it matters: Co-managed avoids the trade-off of "hire enough internal IT to handle every situation" vs. "fully outsource and lose institutional knowledge." Common for businesses with 1-2 internal IT staff and growing needs.

Related: MSP

The opposite of managed services: IT provider only gets called (and paid) when something breaks. No monthly retainer, no proactive monitoring, no scheduled maintenance. You pay by the hour for what gets fixed.

Why it matters: Break-fix sounds cheaper than managed services until you add up the unplanned downtime, the after-hours emergency rates, and the lack of prevention. It's a legacy model that mostly persists for very small businesses or one-off projects.

Related: Managed Services

The general category of outsourced IT services delivered on a recurring basis — monitoring, support, maintenance, advice — for a predictable fee. The model that MSPs deliver. Distinct from "break-fix" (transactional) and from staffing arrangements (people hired through a contract).

Why it matters: Most modern business IT runs on a managed-services model. The predictable cost, proactive prevention, and embedded expertise are the value — businesses spend less time worrying about IT and more time using it.

Related: MSP, Break-fix

Software that lets a managed IT provider remotely monitor your computers and servers, push security updates, deploy software, and fix issues without needing to physically be there.

Why it matters: RMM is what makes proactive IT management possible. Without it, your provider only sees problems after you call them.

Related: MSP, PSA, Patch Management, NOC

The business management platform a managed IT provider uses internally — ticketing, time tracking, billing, project management, contracts. The system that runs the MSP itself.

Why it matters: A well-run PSA is invisible to clients but ensures issues are tracked, billing is accurate, and nothing falls through the cracks.

Related: MSP, RMM, Ticket

A centralized team (and the technology platform supporting it) that monitors network and system health 24/7 — performance, availability, alerts from monitoring tools. Distinct from a SOC (which focuses on security events); the NOC focuses on operational events.

Why it matters: Many MSPs use an outsourced NOC to provide 24/7 monitoring at a price small businesses couldn't justify staffing internally. Whether to label it MSP-internal or external rarely matters to the client; what matters is that someone is watching at 3am.

Related: SOC, RMM

The single point of contact users call (or email or chat with) when they need IT help. The Help Desk handles tickets directly, escalates anything beyond their scope, and is usually the most visible part of an MSP's service to end users.

Why it matters: Help Desk responsiveness defines the user experience of IT services. A well-run Help Desk catches small issues before they become big ones; a poor one trains users to suffer silently and accumulate problems.

Related: Ticket, Tier 1/2/3, SLA

A tracked record of an IT request or incident — created when someone reports a problem or asks for help, updated as work progresses, closed when resolved. Tickets are the unit of work for IT services and the data behind SLA reporting, billing, and trend analysis.

Why it matters: "Did you put in a ticket?" is the operative question because tickets are how work gets prioritized, tracked, and audited. Side-channel requests (hallway conversation, direct text to a tech) usually drop on the floor and aren't billable.

Related: PSA, Help Desk, Severity Levels

The contractual commitment from an IT provider about service quality — typically defining target response times, resolution times, and uptime guarantees, often differentiated by severity level. May include financial penalties for missing the commitment.

Why it matters: Without an SLA, "we'll respond when we can" is the implicit standard. With one, both sides know what "acceptable" looks like and there's something concrete to measure against during contract reviews.

Related: Response Time, Resolution Time, Severity Levels, Help Desk, Escalation

The elapsed time between a ticket being submitted and a technician's first substantive response — acknowledgment alone usually doesn't count. SLAs typically guarantee response times that vary by severity (P1 might be 15 minutes; P4 might be 8 hours).

Why it matters: Response time is the most visible SLA metric to end users — they know immediately whether their issue is being looked at. Beats resolution time as a customer-satisfaction predictor.

Related: SLA, Severity Levels

The elapsed time between a ticket being submitted and the underlying issue being fully resolved (not just acknowledged or worked-around). SLAs may guarantee resolution times for higher-severity tickets but rarely for routine ones.

Why it matters: Resolution time depends on many factors outside the IT provider's control — vendor responsiveness, hardware shipment, user availability. SLAs usually exclude these. Tracking actual resolution time over many tickets is the better measure of capability.

Related: SLA, MTTR

Two related meanings: (1) new-client onboarding — the process an MSP runs to take over IT for a new customer (discovery, documentation, tool deployment, staff introductions); (2) new-employee onboarding — provisioning accounts, devices, and access for a new hire.

Why it matters: Both kinds of onboarding are where MSPs prove their process discipline. A chaotic onboarding sets the tone for the whole relationship; a smooth one builds trust and surfaces issues early.

Related: Offboarding, MSA

The process of disabling departing employees' accounts, recovering company devices, backing up their data (especially OneDrive and mailbox), and removing their access from systems. Both a security control (preventing access by former employees) and a compliance step (proving access was revoked).

Why it matters: Unchecked offboarding is a leading cause of data loss and security incidents. Active accounts of departed employees are a common attack vector for both external attackers and disgruntled ex-staff.

Related: Onboarding

A layered support model: Tier 1 (front-line, handles common issues — password resets, basic troubleshooting), Tier 2 (more experienced, handles harder cases that Tier 1 escalates), Tier 3 (senior engineers, system architects — handles the hardest problems and project work).

Why it matters: The tiered model lets MSPs deliver good service economically — most issues don't need a senior engineer. The trade-off: anything routed through multiple tiers takes longer than going straight to Tier 3. Good MSPs minimize escalation friction.

Related: Escalation, Help Desk

Moving a ticket up to a more senior tier (technical escalation) or up the management chain (hierarchical escalation) when it can't be resolved at the current level or hasn't been resolved within an expected time. Escalation paths should be defined before they're needed.

Why it matters: Smooth escalation is a quiet competence: tickets get routed to the right person quickly, the user feels heard, and outcomes improve. Broken escalation leaves tickets stuck in Tier 1 with no path forward and a frustrated customer.

Related: Tier 1/2/3, SLA

Tickets are typically classified by severity: P1 (critical — everyone is down or major data is at risk), P2 (high — significant impact on multiple users), P3 (medium — single-user or non-critical issue), P4 (low — informational or routine request). Severity drives response-time targets and escalation paths.

Why it matters: Severity classification is what makes SLAs work — you can't have a 15-minute response time for everything. Mis-classified tickets (everything marked P1) undermine the whole system; honest classification is the discipline.

Related: SLA, Ticket, Response Time

An MSP billing model where the recurring fee is calculated per user covered by the service. Predictable for both sides; cost scales with headcount. Often paired with separately-billed device counts or project work.

Why it matters: Per-seat is the dominant MSP billing model because it aligns cost with usage — bigger company, more cost. The downside is that businesses with high device-per-user ratios (manufacturers with shared workstations) may pay more under per-seat than per-device.

Related: Per-Device Pricing, All-You-Can-Eat

An MSP billing model where the recurring fee is based on the number of devices managed — laptops, desktops, servers, phones. Aligns cost with what's actually being managed; useful for businesses with many shared devices or asymmetric user-to-device ratios.

Why it matters: Per-device works well for businesses where headcount and device count don't match — manufacturing floors, retail with shared POS systems, fleet operations. For pure knowledge-worker offices, per-seat is usually simpler.

Related: Per-Seat Pricing

An MSP billing model where the flat monthly fee covers unlimited support — every ticket, every project (within scope), every after-hours call. No per-incident charges. Often called "unlimited support" or "managed services flat fee."

Why it matters: All-you-can-eat shifts risk to the MSP: they're betting their cost to serve will be lower than your fixed payment. Good MSPs invest in automation and prevention to make this profitable; bad MSPs nickel-and-dime everything that's "out of scope." Read the contract scope carefully.

Related: Per-Seat Pricing, Block Hours

A billing model where you pre-purchase a defined number of support hours (a "block") at a discounted rate, then draw down against it as work is performed. Unused hours may roll over or expire depending on the contract.

Why it matters: Block hours work for businesses with unpredictable or seasonal IT needs — pay for capacity in advance, use it when you need it. Doesn't fit well for businesses that want predictable monthly costs; managed services usually serves them better.

Related: Project Work, All-You-Can-Eat

IT engagements with a defined scope ("migrate the office to Microsoft 365") and a defined budget — usually billed separately from the monthly managed-services fee. Project work has a Statement of Work (SOW) that lists deliverables, timeline, and acceptance criteria.

Why it matters: Most major IT changes (migrations, new hardware deployments, security implementations) happen as project work, not as part of routine managed services. A clear SOW prevents scope creep and surprise invoices.

Related: SOW, Block Hours

The overarching contract between an MSP and a client that defines the business relationship — payment terms, liability, intellectual property, confidentiality, dispute resolution. Specific projects and services then sit underneath the MSA via shorter Statements of Work.

Why it matters: The MSA is the legal foundation of the relationship. Once signed, you generally don't re-negotiate it for individual projects — new work goes under a new SOW. Worth a careful read up front (and ideally legal review).

Related: SOW, AUP, Onboarding

A document that defines the specific work to be performed under an MSA — scope, deliverables, timeline, acceptance criteria, and price. Each project typically gets its own SOW; ongoing managed services may be described in a single SOW that runs continuously.

Why it matters: The SOW is the contractual definition of "done." Vague SOWs lead to scope-creep disputes and surprise change orders. Detailed SOWs feel like overhead at signing time and protect both sides during execution.

Related: MSA, Project Work

A document that defines what users are and aren't allowed to do with the IT systems they have access to — typically covering things like personal use, sharing credentials, installing unauthorized software, and accessing inappropriate content. Often required by cyber insurance and compliance frameworks.

Why it matters: An AUP signed by every employee is the policy hook that lets HR and IT take action when something goes wrong. Without it, "we didn't know we couldn't do that" is a defensible position; with it, the rules were known.

Related: MSA, AI Policy, AI Acceptable Use