Customer job
Name the workflow, user, decision, baseline, and expected operating change.
MSP service economics
Price an MSP AI service only after the delivery model is real
An AI service needs a defined business job, approved data boundary, model and vendor cost, implementation work, human review, monitoring, support, and a measurable owner outcome. Package discovery, deployment, recurring operation, and change work separately.
What the decision depends on
FactorWhat to check
Data and risk
Define approved data, retention, access, review, and escalation.
Delivery model
Discovery, integration, testing, training, monitoring, support, and change requests.
Unit economics
Model usage, vendor minimums, labor, rework, customer size, and margin sensitivity.
A package the buyer can understand
Which business workflow changes, who reviews the output, and what happens when usage or quality moves outside the agreed range?
How to package it
Sell a fixed discovery that defines the workflow and data boundary, a milestone-based implementation, and recurring operation with usage and support bands. Put new integrations and workflow changes through a separate change order.
Margin stress case
Recalculate for a low-usage customer that still needs intensive support and a high-usage customer whose model cost and human review both rise. A single token markup will not cover either case reliably.
Worked example
Illustration: a $4,000 monthly AI operations package carries $2,200 of normal vendor, monitoring, review, and support cost, leaving 45% gross margin. If support and human review lift cost to $3,300, margin falls below 18%. A usage band alone will not fix the package unless support and workflow changes also have limits.
Questions owners ask
Should an MSP price AI by user, workflow, or usage?
Choose the unit that best tracks customer value, then protect delivery economics with usage, support, and change bands rather than relying on one vendor meter.
How should discovery be priced?
Use a fixed scope for workflow mapping, data boundaries, baseline measures, technical feasibility, and an implementation recommendation. Discovery should produce a decision even when deployment should wait.
What counts as a change request after launch?
New data sources, integrations, decision logic, user groups, review duties, or material workflow changes should trigger an explicit estimate instead of disappearing into recurring support.
Get a second opinion on this decision
Send your website and the decision you are weighing. We will confirm the price, then send the payment link and a short intake.