Buying seats before deciding tiers
Committing to a per-seat contract for the whole company before you know who needs frontier models locks in the most expensive version of your own rollout.
Guide
How to roll out AI across a company
Four phases, in order, and the mistakes that make each one expensive. Most companies can finish the technical work in an afternoon.
Quick answer
The four phases
Rolling out AI across a company takes four phases, and most teams can complete them in an afternoon if identity and devices are already managed centrally. First, decide who gets what: map teams to model tiers before touching any tooling, so a vague AI project becomes a concrete provisioning plan with a predictable first invoice. Second, connect your identity provider, so the group rules you already maintain become AI access policy and joiners and leavers are handled automatically. Third, ship the assistant through your existing MDM, the same way you distribute every other managed app, so there are no installs to chase and no API keys in spreadsheets. Fourth, watch the first two weeks and adjust per team rather than per company, looking for low adoption that needs a nudge and high spend that needs a different model mix. The common failure is skipping phase one and buying seats before deciding who needs which models.
the golden path
Do them in this order
The order matters more than the speed. Every expensive rollout we have seen went out of sequence, usually by buying before deciding.
-
Decide who gets what
Before you touch any tooling, map teams to model tiers.
This is the phase people skip, and skipping it is why AI bills surprise finance three months later. Most companies find that a small group genuinely needs frontier models, usually engineering and a few analysts, and everyone else does excellent work on faster models that cost a fraction as much. Write that mapping down before you buy anything. It turns a vague AI project into a concrete provisioning plan, it makes the first invoice predictable, and it gives you something to adjust in phase four rather than a single company-wide setting to argue about.
Decide the mapping, not the vendor. The mapping outlives whichever model is best this quarter.
-
Connect your identity provider
Group membership becomes AI access policy, with no new admin.
Connect the identity provider you already run, whether that is Okta, Microsoft Entra, or Google Workspace. The rules you maintain anyway, departments, seniority, contractor status, become the access policy for AI. Nobody maintains a second list. Joiners get access on their first day because they are already in the right group, and leavers lose access the moment they are deprovisioned, at the same time they lose email. This is also the phase that quietly solves your shadow-AI problem: when the sanctioned assistant is already on the laptop and already signed in, personal accounts stop being the path of least resistance.
If you can answer "who is in the marketing group" from your IdP today, this phase is configuration, not a project.
-
Ship it through MDM
Distribute the assistant like every other managed app.
Push the desktop app through the tooling you already use, Jamf or Kandji for macOS, Intune for Windows. Employees open their laptop and the assistant is there, already knowing who they are and which models their team is allowed. There are no installs to chase, no onboarding webinar required, and no API keys handed out in spreadsheets. This is the difference between a rollout that lands in an afternoon and a pilot that is still limping along in month three because forty people never got round to installing anything.
No new infrastructure. If you run an IdP and an MDM, you already have everything this phase needs.
-
Watch the first two weeks
Adjust per team, not per company.
The first fortnight tells you almost everything. Look for two signals. Teams with unusually low adoption usually do not need a policy change, they need one concrete use case demonstrated by someone in their own department. Teams with unusually high spend usually do not need a budget cut, they need a different model mix, because someone is running frontier models for work a fast model handles perfectly. Change those two things per team, without redeploying anything, and the rollout settles. Companies that instead set one company-wide policy end up either overpaying for everyone or throttling the people doing the most valuable work.
Two weeks of real usage beats two months of planning meetings about hypothetical usage.
Failure modes
What usually goes wrong
Running a pilot that never ends
A twenty-person pilot proves that twenty people like AI. It does not surface the governance, spend, or support questions that only appear at company scale, so the real rollout starts from zero anyway.
Treating it as a training problem
Adoption failures are usually access failures. If the assistant is not already on the laptop and already signed in, no amount of enablement sessions will fix the drop-off.
One policy for everybody
Finance and engineering do not need the same models, and a single company-wide setting means you are either overpaying for most people or throttling the ones creating the most value.
FAQ
Questions teams ask first.
How long does an AI rollout take?
If you already manage identity and devices centrally, the technical work is an afternoon: connect your identity provider, import teams, set a default policy per team, and push the app through MDM. The phase that takes real thought is the first one, deciding which teams get which model tiers, and that is usually a single meeting with someone from finance in the room. Companies that take months are almost always stuck in an extended pilot rather than blocked on the deployment itself.
Should we start with a pilot?
A short pilot is useful for choosing between tools. It is much less useful as a rollout strategy, because a twenty-person pilot only proves that twenty motivated people like AI. It will not surface the questions that decide whether the rollout succeeds: how spend behaves at scale, what governance and audit your security team needs, and what happens when someone leaves. Those only appear at company scale. If you can provision through identity and devices, going company-wide is usually less risky than a pilot that quietly never ends.
Who should own the AI rollout?
IT owns the mechanics, because identity and device management are already theirs, but IT should not own the model-tier decision alone. That first phase is a joint call between IT, finance, and the team leads who know what their people actually do all day. The most common organisational failure is handing the whole thing to IT as a tooling project, which produces a technically clean deployment that nobody adopts because no department ever agreed what it was for.
How do we keep the AI bill under control?
Two levers do most of the work. The first is the tier mapping from phase one: default everyone to capable, fast models and reserve frontier models for the teams that genuinely need them. The second is hard budget caps per team and per user, so overspend is prevented rather than discovered on an invoice. Watching the first two weeks is what connects the two, because that is when you find the team whose usage does not match its tier.
What does this cost with Harriet?
Harriet is priced per organisation, scoped to the people it actually provisions, with no seat minimum and no annual commitment, so the rollout is not gated on a long procurement cycle. Model usage is separate and runs either through your own provider API keys, keeping any committed-spend deals you already have, or through managed credits for a single invoice with access to all the frontier labs as well as high-quality open-weight models.
Run the four phases this week.
Book a 20-minute call and we'll map the four phases to your identity provider and MDM.