Role-based Claude training built around the workflows your people actually run — so the week after the training looks different from the week before.
Member of the Claude Partner Network
We train teams on Claude, find the workflows worth changing and ship them to production, backed by training and technical support from Anthropic’s partner program.
Target audience
Managers, engineers, analysts and business users in the same company, at very different levels of AI maturity — which is exactly why a single all-hands course does not work.
The business problem
The reason most corporate AI training does not stick is that it is taught in the abstract. People leave impressed, return to a full inbox, and go back to doing the work the way they always did — because nobody showed them this specific task, done this way.
Use cases and curriculum
Modules are assembled per cohort. These are the ones most organizations end up wanting.
For everyone, regardless of function.
People who can get a reliable result, and who can tell when they have not.
Separate tracks per function, taught on your own material.
Confident teams using Claude in their daily work.
Engineers and certification
Most organizations buying Claude training need three things from one supplier: role-based learning for business users, real Claude Code instruction for engineers, and a credential at the end that means something internally. Buying those from three vendors is how a programme ends up with inconsistent standards.
Engineers sit in the same programme but on a different syllabus. If your engineering organization is already using Claude Code and needs standards rather than an introduction, that runs as its own engagement.
Assessment is against your own workflows, so the credential says someone can do the work here — not that they watched a video. Pathways run from foundation to enterprise.
Process
Two to five days of delivery, with scoping before and an observation window after.
Scoping
Roles, maturity, tooling and the workflows that matter.
Curriculum design
Cohorts split by role; examples drawn from your work.
Delivery
Hands-on sessions, on-site or remote.
Playbooks handed over
Prompt library, role playbooks, safe-use standard.
Observation window
What actually changed — and what to build next.
Expected outcomes
Before and after
Enablement is only worth buying if the week after looks different from the week before. Stated per role, and then for the three things that decide whether it holds — what it costs, what data it touches, and how you would know it worked.
Manager or team lead
Approves AI use case by case, with no agreed line on what is acceptable.
Works to a written safe-use standard and can say yes or no without escalating.
Analyst
Rebuilds the same summaries, comparisons and briefing notes by hand each cycle.
Runs them from a shared prompt library and spends the time on the judgement call instead.
Business user
Reaches for Claude when they remember to; results vary widely from person to person.
Follows a role playbook, so output quality holds across the team rather than per individual.
Operations
Handles the same exceptions repeatedly, with no record of how they were resolved.
Has the recurring ones written down and flagged as candidates worth automating.
HR and L&D
Buys training and has no way to tell whether anything changed afterwards.
Runs a repeatable curriculum with adoption measured in the weeks after delivery.
Token economics
Usage arrives as one invoice line. Nobody can say what a task, a team or a habit actually costs, so nothing can be optimised.
Teams learn which patterns are expensive — re-pasting whole documents, restarting instead of refining — and cost per task becomes something you can look at.
Data handling
People decide case by case what is safe to paste in, usually under time pressure, with no written answer to fall back on.
A classification of what may and may not be sent, agreed with your security team, taught in the room and practised on real examples.
Productivity
Gains are claimed anecdotally and argued about. Nobody agreed what to measure before the training, so nothing can be settled after it.
A baseline captured before delivery on tasks you nominate, and the same tasks re-measured afterwards. We do not promise a number; we make one observable.
Before you ask
Two to five days of delivery depending on how many role tracks you need. Cohorts are kept small enough that everyone works hands-on rather than watching — the exact number depends on the room and the format, and we agree it during scoping.
It is the normal case, and it is why cohorts are split by role and maturity rather than by seniority or department. A finance analyst who has never used Claude and an engineer who uses it daily should not be in the same session.
Yes, and the training is significantly better when we do. What may be used, and under what handling rules, is agreed with your security team during scoping — that conversation is also what produces the safe-use standard you keep afterwards.
Claude is our depth and our default as a Claude Partner Network member. The fundamentals — how to prompt, when to verify, what not to send — transfer to other models, and we say so plainly rather than pretending the skills are Claude-specific.
Only if you want it. The observation window is included; turning what it finds into built workflows is a separate engagement covered on the adoption consulting and workflow implementation pages.
Focus20 Labs delivers all three from one team, which matters because buying them from three vendors is how a programme ends up with inconsistent standards. Role-based learning runs as separate tracks per function — sales and marketing, finance and analysis, operations and support, HR and internal comms, product and delivery — taught on your own material rather than a stock syllabus. Engineers take a different syllabus in the same programme, covering Claude Code, MCP, subagents, testing discipline and repository guardrails. Certification runs foundation, practitioner, engineering and enterprise, assessed against your workflows so the credential says someone can do the work here.
Yes, in kind rather than in quality. A public course teaches a general syllabus to an anonymous audience and certifies attendance. This is delivered to your cohorts on your own material, the role tracks are built from the workflows your people actually run, and assessment is against those workflows. The trade-off is honest: a public course is cheaper per seat and available today. If your goal is individual upskilling, take the course. If your goal is a team that changes how it works — and a credential your own managers trust — that needs delivery against your context.
Start here
Tell us who needs training and where they are today. We come back with a proposed cohort split, a curriculum outline and what we would need from your side.