Contractors Are Not Half-Users: How MSPs Should Price Messy Client Headcount

A client says they have 80 employees and 22 contractors.

Then comes the question every MSP has heard:

"Do contractors count as full users?"

Sometimes the honest answer is no. A seasonal worker with one shared kiosk login and no helpdesk expectation is not the same as a finance contractor with a laptop, email, MFA, VPN, apps, and urgent access requests.

But a lot of clients use "contractor" as a pricing word, not an operational one. They are asking you to discount ambiguity.

That is where MSP margins get weird.

The payroll label is not the pricing model. Support burden is.

If the person can create tickets, touch sensitive systems, require onboarding and offboarding, fail MFA, lose a device, or need app access, they need to be priced like a supported identity. Maybe not always a full user. But definitely not a casual footnote.

If you already wrestle with per-user vs per-device pricing, contractor pricing is the same fight with worse vocabulary.

The mistake: pricing the job title instead of the work

Contractor. Part-time employee. Intern. Seasonal worker. Vendor user. Shared mailbox owner. Field tech. Temp.

Those labels tell you how HR thinks about the person. They do not tell you what the MSP has to support.

An MSP does not absorb cost because someone receives a W-2 instead of a 1099. Cost shows up when that person needs:

• Identity creation and lifecycle management
• Microsoft 365 or Google Workspace access
• MFA setup and reset support
• Device configuration
• VPN or remote access
• Security policy enforcement
• Line-of-business app access
• Shared mailbox or distribution group changes
• Helpdesk support
• Offboarding and access removal
• Audit evidence that proves the account was handled correctly

A contractor with all of that is not half a user. They are a user with a different tax form.

The client may not be trying to be difficult. They may honestly think, "They only work 20 hours a week, so why would I pay full price?"

That sounds reasonable until you remember your helpdesk does not charge by the employee's weekly schedule. Your RMM bill, identity risk, security process, and offboarding responsibility do not magically drop by 50% because the person works Tuesdays and Thursdays.

Use support classes instead of arguing over fractions

Stop debating whether a contractor is 0.25, 0.5, or 0.75 of a user.

Fractional math feels precise. It usually turns every renewal into a courtroom where the client argues that this person is less real than that person.

Use support classes instead.

Class 1: Full supported user

Use this when the person has normal access and normal support expectations.

Typical signs:

• Named email account
• MFA and password reset support
• Company-managed laptop or phone
• VPN or remote access
• Access to business apps
• Can open helpdesk tickets
• Needs onboarding and offboarding
• Creates security or compliance exposure

Price this as a full user.

Do not apologize for it. If the contractor can create the same tickets, risk, and access work as an employee, the MSP cost is the same shape.

Class 2: Limited-access identity

Use this when the person needs an account, but the scope is narrower.

Typical signs:

• Email or app access only
• No managed device
• Limited ticket rights
• No general workstation support
• Support handled through a client point of contact
• Clear offboarding process
• Specific access duration

This can justify a lower monthly rate or a named line item.

The important part is the boundary. If the client wants a lower price, they also need lower scope. Not lower scope in theory. Lower scope in writing.

Class 3: Device or app-only exception

Use this when the support object is not really a user.

Typical examples:

• Shared kiosk account
• Warehouse terminal
• Single-purpose device
• Vendor account with one app
• Room system
• Scanner or tablet used by many people

This should not be shoved into per-user pricing just because the agreement needs a count. Price it as an exception: device support, app support, shared identity handling, or a monthly access management fee.

That gives the client a cleaner bill and gives your team a cleaner boundary.

The discovery questions that decide the class

Do not ask, "Are they a contractor?"

Ask questions that expose the work.

Use these in sales, onboarding, and renewals:

1. Does this person have a named email account?
2. Do they use MFA, SSO, VPN, or conditional access?
3. Do they use a company-managed device?
4. Do they use a personal device to access company data?
5. Can they submit tickets directly to the MSP?
6. Are password resets included?
7. Who approves their access changes?
8. What applications do they need?
9. Are they included in security awareness training?
10. Are they included in compliance or audit evidence?
11. Who tells us when they leave?
12. How fast does access need to be removed after departure?
13. Do they need after-hours or urgent support?
14. Are there seasonal spikes in contractor count?
15. What happens if they cannot work because access is broken?

That last question is the one clients feel.

If the contractor being locked out creates business impact, then the client expects real support. Real support needs real pricing.

Put the limits in the quote, not in someone's memory

A pricing class only works if the quote says what it means.

If your sales team says "limited-access contractor" and your service desk hears "normal user," you did not create a pricing model. You created future resentment.

Use quote language like this:

Limited-access identity includes account creation, MFA enrollment, approved application access, and offboarding for named contractor users. It does not include workstation support, personal device troubleshooting, direct end-user helpdesk access, after-hours support, or support for applications not listed in this agreement.

That paragraph does more than describe the line item. It tells the client what they bought and tells your team what they are allowed to say no to.

For full supported users, write it plainly:

Full supported users include identity management, supported device assistance, helpdesk access, Microsoft 365 support, approved business application access, onboarding, offboarding, and security policy enforcement under the managed services agreement.

For device or app-only exceptions:

Device or app-only exceptions cover the specific shared device, shared account, or named application listed in this quote. Support is limited to that asset or application. User-specific support, personal device support, and general helpdesk access are excluded unless added separately.

This is the same discipline you need in an MSP scope of work. If the boundary only exists in conversation, it does not exist.

Watch the change triggers

Contractor pricing fails when the client changes the usage but expects the old price to hold.

A limited-access identity becomes a full supported user when:

• The person gets a managed laptop
• They start opening tickets directly
• They need VPN or broader app access
• They join security or compliance scope
• They need urgent or after-hours support
• They become a permanent employee
• The client wants onboarding or offboarding handled like a normal user

Put those triggers in the agreement.

Not because you want to nickel-and-dime the client. Because you want the account manager, service manager, and client contact to have the same rulebook.

If a contractor's access expands, the price changes on the next billing cycle. If the client wants to keep the lower price, the scope stays limited.

That is not hostile. That is clean.

The margin problem hides in onboarding and offboarding

MSPs often underestimate contractor cost because the monthly ticket volume looks low.

The work shows up around the ticket: Friday access requests, MFA resets before client deadlines, laptops nobody mentioned, vendor accounts that were supposed to expire, and shared mailboxes nobody removed.

That work is real. It also creates risk. Contractors are treated as temporary, which is exactly why lifecycle management needs to be tighter, not looser.

If your agreement includes onboarding and offboarding, contractor turnover can quietly eat the same margin as employee turnover. This is where pricing math matters. Count the work that happens around the user, not just the number of times they call the helpdesk.

When to refuse the discount

Some contractor discounts are fair.

A read-only app user with no device support, no helpdesk access, and a hard end date should not always cost the same as a full user.

But refuse fractional pricing when the client cannot accept the matching boundary.

If they want the contractor to get the same support, same response time, same access work, same security enforcement, and same offboarding process, the price should be the same.

The polite version is:

We can price contractors differently when the support scope is different. If they need the same access, security coverage, onboarding, offboarding, and helpdesk support as employees, we price them as supported users. That keeps service expectations clear and prevents surprise work from being hidden in the agreement.

That is a lot better than arguing about whether someone is 40% of a person.

A simple contractor pricing framework

Use this as a starting point:

Support class	Use when	Pricing shape
Full supported user	Normal identity, device, app, and helpdesk expectations	Full per-user managed services rate
Limited-access identity	Named account with narrow access and limited support	Reduced identity/access management rate
Device or app-only exception	Shared device, shared account, or one application	Asset, app, or exception line item

Then make three rules non-negotiable:

1. Every user class has written inclusions and exclusions.
2. Any scope expansion changes the class.
3. Offboarding responsibility is always named.

If you do only those three things, contractor pricing gets much less emotional.

Final take

Contractors are not automatically full users.

They are also not automatically discount users.

The right price depends on what your team has to support, secure, document, and clean up later.

Payroll status is trivia. Support burden is pricing.

If your quotes still turn contractor headcount into a fuzzy negotiation, fix the quote structure first. Clear user classes, written assumptions, and change triggers will protect more margin than another awkward discount debate.

Scopable is being built to help MSPs turn that messy discovery into cleaner quotes. If you want the workflow that turns support assumptions into quote logic, join Scopable early access.

Related reading

• MSP Pricing: Per User vs Per Device
• MSP Pricing Math for Managed Services
• MSP Quoting Mistakes That Kill Margins
• MSP Scope of Work Template