Hands-on work run against your tools and your repeated work, either with the few people who own a process or across the wider team. Start with whichever you need. People leave with prompts and workflows they built during the session, not notes about someone else's use case.
Quoted scoped on a call · you get it in writingThe gap is rarely access to a model. It is knowing which work is worth handing over, how to describe that work clearly, when to trust the output, and when to stop and check. Those are learnable skills, and they are faster to teach against real examples than against a tutorial.
Pick by what you need first. Fewer people means we get further into one process. More people means more of the team walks out with something running. Neither one is a prerequisite for the other.
For the people who own a process end to end. We work through it with them at their own keyboard, on real files, and the output is a written map of that workflow: the steps, where judgment belongs, what should be automated, and what should be left alone.
For getting a group off zero at once. Less hands-on with each person because there are more of them, so no per-person map, but everyone leaves with prompts and a workflow of their own that already runs. Sharper if a working session mapped the work first, but it does not require one.
Either format runs against work your team already does. We set the length with you on the call, and teams split it however suits them: one afternoon, two mornings, or weekly blocks while the work is still fresh.
We ask what your team repeats every week and gather concrete examples: the emails, documents, reports, reviews, and requests that consume time. The session is built from those.
Participants work on their own tasks with guidance, so the output is a set of prompts and workflows that already fit the way their work is described internally.
The prompts, workflows, and operating notes stay with your team. Nothing about the session depends on us being in the room again.
Tool knowledge goes stale in a quarter. The skills below do not, which is why the session is built around them rather than around a feature tour.
The core skill is reading output critically: knowing which parts to verify, which to rewrite, and which tasks should never have been delegated in the first place.
Most bad output traces back to a vague request. Teams practice stating inputs, constraints, format, and what a good result looks like.
Where approval is required, what data stays out, and how to keep a human on the outbound side of anything customer-facing. Related: AI governance lite for small teams.
Sessions usually surface one or two processes that should not be done by hand at all. Those become a workflow audit, then possibly an automation.
Tell us the audience, the tools, and the workflows you want covered. On-site across Tampa Bay, or remote.