We gave five teams access to Claude. Engineering has been using it for about 9 months. The wider business rollouts started 4 months ago as structured enablement sessions, though pockets of people were already using it before that. We built automations around their actual workflows and measured what changed.

Here's what happened, team by team.

SDR

This was the first team we rolled out. The SDR team was doing outbound in a competitive mid-market. Before Claude, they were averaging 6 calls per hour. A lot of that time went on research, finding context on prospects, figuring out what to say, writing follow-ups after calls.

We gave them Claude with access to HubSpot, Gong, and LinkedIn. Built seven automations: discovery call write-ups, customer research, MQL analysis, AE handover documents, a few others. Small, discrete automations that each did one thing well. Nothing monolithic.

One SDR went from 6 calls an hour to 10. Not because he was working harder. Research, call prep, follow-up notes, all the stuff that used to eat half the day just collapsed into minutes. The rest of the team took longer to get there, but the direction was the same. More time on the phone, less time on admin. The SDR lead told me the biggest shift wasn't speed though. It was confidence. They were walking into calls actually knowing something about the person on the other end.

One thing that didn't work: the tone. First version of the call write-ups sounded like ChatGPT wrote them. Em dashes everywhere, corporate language nobody on the team would actually say. We caught it, rewrote the guidance, and baked tone rules into every automation after that. Lesson learned early, which was lucky.

Marketing

The marketing team produces campaigns, webinars, blog content, and case studies. The constraint was never ideas, it was production time. They couldn't get assets out fast enough for the campaigns they wanted to run.

We set up Claude with access to their CRM data, event analytics, and AskEva (our internal knowledge base). The marketing lead independently built a blog repurposing skill during our second session, which was exactly the kind of adoption you want to see. Not waiting for IT to build something. Just doing it.

Now their workflow runs roughly: campaign brief, AI-assisted research, Claude produces about 80% of first-draft assets, humans refine, then distribute. They went from bottlenecked on production to bottlenecked on distribution, which is a much better problem to have.

People and Finance

These two teams started together, then split into separate tracks because the use cases were so different.

Finance was the hardest team to get over the line. They're analytical people who trust spreadsheets. If the output doesn't exactly match their existing report format, column for column, they won't even consider it. So that's what we did. We built a ChargeBee reporting automation that pulls data across 46 columns with live refresh, and the first thing we had to prove was that the numbers matched. Exactly. Once that trust was there, they started exploring other use cases. The finance team now uses Claude for Power Query code generation, credit control emails, and invoice chasing. They prefer Claude for agentic work and ChatGPT for research. We don't force a single tool.

On the People side, our People Officer built a sickness absence report that calculates Bradford Factor scores and generates an executive summary as a Word document. She then went further and built a skill for our internal newsletter that pulls content from Slack, Gong calls, and LinkedIn to research themes and suggest articles. She moved the newsletter from email to a Slack Canvas, and the 100th edition was produced using Claude last week. All of that happened without engineering involvement. I helped with the initial skill structure, but she iterated on the logic, fixed the bugs, and owns it now. That's the real signal that adoption is sticking. When people build their own tools without being asked to, you know it's working.

CSM

The most recent rollout. Eight team members, and the vision is what I'd call a "virtual CSM" that handles the grunt work: data gathering, report generation, customer health snapshots, and QBR preparation. The CSMs then spend their time on the relationship and value delivery, not pulling data out of four different systems.

Early days here. We've identified a language mismatch problem where contract terms don't match platform feature names, which means you need explicit mapping in every prompt. That's the kind of thing you only discover when a real team tries to use it on real data. We're also exploring building an MCP server for our tenant management platform so CSMs can pull full licence and feature details for each contract without jumping between systems. We're working through it.

Engineering

This one's different because it wasn't a structured rollout in the same way. Engineering tried both Claude Code and Codex to work out what was actually better, or whether there was a benefit to mixing and matching. In the end Claude Code won out, for now at least. We use it across code review, test generation, PR summaries, and architecture evaluation. The results showed up in cycle time.

Across 800 Jira issues between September 2025 and March 2026, engineering cycle time dropped 41%. From 8.5 days to 5 days average. It wasn't even across the board. One squad hit 53%, another 33%, and the third saw 15% but they were also shipping a major feature release in the same period. I'd expect their numbers to improve now that's out the door.

I'm not going to pretend all of that is Claude. Better processes, better backlog discipline, and a strong Head of Engineering running delivery all contributed. But AI-augmented development was a real factor, and the trajectory is clear.

What I'd do differently

If I were starting this again, three things:

First, tone and voice guidance from day one. We learned this the hard way with SDR. Every team needs guardrails on how their AI output should sound, or it all reads like the same generic bot.

Second, start with the smallest possible automation. Our best results came from discrete, single-purpose tools. Every time we tried to build something ambitious upfront, it took too long and people lost interest.

Third, let people build their own. The teams that adopted fastest were the ones where individuals started creating their own skills. You can't mandate that kind of ownership. But you can make it easy, show them how, and then get out of the way.

And one thing nobody warned me about: AI magnifies everything. Good habits get significantly better. Bad habits get significantly worse. If a developer already had a tendency to put too many changes in a single PR, now they're submitting PRs with hundreds of files. The speed is real, but it amplifies whatever was already there. You need to fix the process problems first, or AI just makes them louder.

The numbers, all in one place

None of this required a massive team or a huge budget. It required structured rollouts, real measurement, and the patience to fix what didn't work. We're still iterating on most of it. That's the point. This isn't a project with an end date. It's how we work now.