Rollout playbook
The staged path from one workflow in production to a company that runs on Harriet: choose the first workflow, pilot it with one team, verify, enroll team by team, hand over, and queue the next one. Each stage names an owner, a gate and what Harriet's team does.
The path at a glance
| Stage | Owner on your side | Gate before the next stage | What Harriet's team does |
|---|---|---|---|
| 0. Choose the first workflow | The person who knows the process best | One process, one team, one owner agreed | Maps the process with that person and picks the systems it touches |
| 1. Pilot with a small team | Pilot team lead, with IT | Identity works for every pilot user; one full business rhythm observed | Builds the skills and connectors with the team, in production on real work |
| 2. Verify integrations and skills | IT or security | Checklist below complete | Walks the checklist with you and fixes what it finds |
| 3. Enroll team by team | IT, with each team lead | First sync confirmed for the team before the next one starts | Builds each team's profile with you |
| 4. Hand over and queue the next | The named workflow owner | Setup documented, owner assigned, next workflow chosen | Documents the setup and hands over |
This is the operational version of the path on the deployment page. The buyer's view, with the phases and who approves what, is on How to roll out AI across a company.
Stage 0: Choose the first workflow
Start with one process that takes too much of one team's time, not with a company-wide plan. Good first candidates are repeat work with clear inputs and a person who already checks the output: ticket triage, invoice matching, account research before a call, a security questionnaire. See Identifying use cases.
Name the owner before anything is built. It is the person who does the work today, not IT. IT joins when the systems get connected.
Stage 1: Pilot with a small team
Do not announce anything company-wide yet. Pick the team that owns the first workflow, complete the Get started wizard yourself, then send that team enrollment invites from People. Each person opens the invite link and connects Harriet Desktop (or Claude Desktop, where your organization uses it).
Harriet's team builds the first skills and connectors alongside the pilot team, so the workflow runs in production on real work rather than in a sandbox. Anything that writes or sends waits for a person's approval; see approvals.
Before expanding beyond the pilot, confirm identity works: SSO or account linking should behave as expected for every pilot user, and roles should match who may configure integrations and skills versus who only consumes them.
Keep the pilot running long enough to see a full business rhythm. If a skill touches payroll or finance data, that means at least one complete cycle before you call it proven.
Stage 2: Verify integrations and skills
Run this checklist before you turn on any new connector or skill for a wider audience:
- Review queue ownership. Confirm who may submit, approve, or request changes for connectors and package skills. The submitter and reviewer should not be the same person unless your policy allows it. See the review queue.
- Data and compliance. Confirm data residency and DPA coverage for each vendor you connect, and grant least-privilege OAuth scopes or API keys, removing unused access. Model hosting region is set per team; see EU data residency.
- Tool behavior. After syncing tools on a new MCP connector, verify tool permissions and sandbox behavior match your risk appetite.
- Operational readiness. Write down who rotates credentials after go-live and who watches for failed syncs, rate limits, or expired auth.
- Read before write. Do not enable write skills in production until the read paths are stable.
- Budgets. Set a budget for the pilot team before the second team joins, so spend is a policy you set rather than a line you discover.
Stage 3: Enroll team by team
Expand one team at a time rather than opening the gates. For each team:
- Build the team's profile. Bundle the skills, connectors, and settings that team needs into a profile and assign it to the team. Every enrolled device on the team then receives the same configuration. The second team starts from the first team's skills, not from zero.
- Send enrollment invites. Add people in Manage users first, then send invites from People. Each invite is a secret link the person opens to connect a device.
- Or push through MDM. For fleets you already manage, enroll devices via MDM instead of individual invites.
- Confirm the first sync. Open the team in Teams and check members show linked devices and successful calls before moving to the next team.
Stage 4: Hand over and queue the next workflow
A workflow is handed over when three things are true: the setup is documented, a named person on your team owns it, and the security policies for it are configured. Harriet's team writes the documentation with you and steps back; your team runs and expands the workflow from there.
Then pick the next one. Every workflow in production shows what sits beside it, and the per-team usage on each team's detail page shows what each one is worth. Keep a short list of the next three, in order, and treat it as the roadmap.
Communicating with employees
A short employee-facing note per wave beats one big announcement. Say what changed, what they can now ask their AI to do, and what to do when something fails. Set expectations early: Harriet works from your company's skills and connected systems, not a general open-ended promise. Always give a fallback path, such as a ticket or an email alias, for sensitive or novel requests.
Train one or two champions per team on how to phrase requests and when to escalate. Champions absorb most early questions and surface the real gaps.
Measuring adoption
The Dashboard gives you the rollout scoreboard. The Adoption overview panel tracks three coverage bars: Users with device linked, Users with any assignment, and Teams with profile assigned. The Tool call activity chart shows MCP proxy successes and errors by day, so a wave that enrolled but never calls tools is visible within a week.
For cost and usage per team, open LLM Usage, or check the per-team usage panel on each team's detail page. See usage analytics and budgets.
After launch, watch review queue throughput weekly for the first month. Package skills submitted via Skilify are not auto-published, so if reviewers fall behind, authors stall and momentum dies quietly.