NOTE: To use this checklist, copy the content using the “Copy page” button above, then fill in the owners and dates for your organisation.

Claude Enterprise: your first 90 days

This checklist turns the first 90 days after signing Claude Enterprise into a plan your sponsor and board can follow. It is built on The Kowalah Way, the phase-gated method we use with clients, and it works whoever runs it.

For the reasoning behind each step, read the companion guide: Claude Enterprise rollout plan: the first 90 days.

The shape of the 90 days

Before week 1: set up

• Executive sponsor named. Chairs the steering committee and defends priorities.
• Programme lead named. Owns the plan, status reporting and the adoption workstream.
• Business outcome agreed. One number the board recognises (hours returned, cycle time, cost per case). Write down its baseline today.
• Data rules agreed with the DPO. Which data classes Claude may process, and the UK data residency position for each route you plan to use.
• Organisation-wide spend limit set. Your backstop against an unexpected invoice.
• User groups created to mirror cost centres, with SCIM provisioning where available.
• Default model and thinking level set to a capable, lower-cost option; the largest models restricted to the groups that need them.
• SSO connected and audit logging reviewed with your security team.
• Scattered accounts consolidated (extra Team plans, expensed personal plans) into the one organisation.
• Steering committee cadence booked (fortnightly for the first quarter).

Weeks 1 to 2: scope the programme

• Run a structured scoping workshop with the sponsor and function heads (we run a Vision Map Workshop).
• Vision map produced: use case clusters, grouped and phased.
• Roadmap produced: quarter-by-quarter milestones and the metric each serves.
• First use case chosen on business value, feasibility and the appetite of the team who will use it.
• Business owner named for the first use case.
• Target architecture drafted: Claude surfaces, integrations, identity and security model for the first release.
• Success metrics written: the business measure plus weekly leading indicators.
• Proposal or plan approved by the sponsor.

Weeks 3 to 5: define, design and check

Define

• Kick-off held with the client-side team: vision, governance, responsibilities.
• Workshops held with the team who will use the first release.
• User stories written with acceptance criteria the business owner has agreed.
• Definition of ready and definition of done agreed.
• First written status report issued (RAG, progress, risks, decisions needed).
• First steering committee held.

Design

• Solution design complete: agents, workflows, integrations, Claude capabilities.
• Design checked against your Microsoft 365 or Azure estate and identity model.
• Release plan and build cadence agreed (two-week sprints for integration work, two-day bursts for standalone agents).
• User acceptance testing plan agreed, with named testers from the business.

The checkpoint: go or no-go

Do not start the build until every line is ticked.

• All stories approved by the business owner.
• Architecture reviewed and signed off.
• Security review of data handling and connector permissions complete.
• Compliance position confirmed (UK GDPR, data residency, internal policies).
• People available for the build and for testing.
• Scope changes since week 2 formally agreed.
• Change readiness assessed: Guides identified, communications drafted.
• Steering committee decision recorded: go / no-go.

Weeks 5 to 8: build, test and deploy the first agent

• Build running in the agreed cadence, with a written update each week.
• Testing complete: unit, end-to-end and user acceptance.
• Security review signed off before production.
• Compliance check signed off before production.
• No open critical defects.
• User guidance, admin documentation and a support runbook delivered.
• Go-live approved by the business owner.
• First agent live in production.
• Adoption baseline captured on launch day.

Weeks 9 to 13: measure, report and plan the next quarter

• Usage tracked per person per week, by team.
• Business metric compared with its baseline.
• Flat or falling usage investigated with the team; workflow fixed, not just reported.
• Use cases collected from across the business and scored on impact, confidence and ease.
• Next two or three use cases chosen.
• Day-90 report delivered to the steering committee and the board (outline below).
• Next quarter’s plan and budget approved.

The adoption workstream, week by week

Adoption runs alongside the build from the first week.

Owners table: who decides what

Adoption tracker

Copy one row per team, per week, from launch day.

Steering committee report outline

Use the same four headings at every steering committee and in the day-90 board report.

1. What is live, and who uses it. Releases in production; active users and uses per person per week, by team.
2. What the business metric has done. Current value against the baseline agreed before week 1.
3. Risks, issues and decisions needed. RAG status, with anything the committee must decide this meeting.
4. What is next. The next release, the next use cases, and the budget needed.

Implementation notes

• Keep the first release small. One use case, one team, one measurable outcome. Breadth comes in the next quarter.
• Write status before you speak it. The steering committee should never hear bad news for the first time in the meeting.
• Treat adoption data as a trigger. Flat usage in a team is a prompt to talk to that team this week.
• Keep the checkpoint real. A no-go at week 5 is cheaper than a failed go-live at week 8.