A colleague of mine built the same workflow three different ways over three months. Version one pulled data from an inbox and put it into a dashboard. Version two skipped the dashboard and sent the data straight into the project board where the team actually worked. Version three added a drafted follow-up email on top of that, ready for a human to check and send.
Look at what actually changed between versions, because it was not the data. Version one produced something people had to go check on their own. Version two put the output where the work already happened, so nobody had to remember to look. Version three drafted the next action itself and left only the decision to a person. Each version moved the workflow one step closer to the moment a human choice actually matters, and cleared out everything before it.
That is the real subject here. The point isn’t building something once. It’s knowing how to schedule AI workflows at work so they keep running without you, and knowing what your job is once they do.
How to Schedule AI Workflows at Work
If a workflow works, the next question is not “what else can I build.” It is “does this need to run on its own.” Most of what you have already built probably does.
Here is what it actually looks like to schedule AI workflows at work, boiled down to a simple test. Does the job run on a rhythm, daily, weekly, every Monday before a meeting? Do the inputs show up on their own, without you gathering them? Does the output look roughly the same shape every time? If yes to all three, you are the only manual part left, and you are the part that forgets, goes on vacation, and gets pulled into something else. Scheduling is not about saving effort. It is about removing the least reliable part of the workflow, which is your memory.
In Claude, scheduled tasks live in Cowork. In Copilot, you can schedule a prompt directly in chat, or schedule a task in Copilot’s own Cowork as well, depending on how simple the job is. Either way, the point is the same: you built it once, you do not want to run it by hand every single week.
Ask about cost at the same time you ask about scheduling AI workflows at work. Every recurring run spends tokens, and a workflow that checks everything from scratch each time costs more than one that only looks at what changed since the last run. If you already built an update record for this workflow (that’s the update record from Post 5), use it to scope each run down to what is new. That adds up fast once something runs daily or weekly instead of once.
You Will Get Told When It Is Done, Just Not the Same Way
Notifications work differently from tool to tool, and it is worth knowing the difference before you rely on it. As of this writing, Copilot can email you or drop a message in Teams when a scheduled task finishes, and Claude Cowork shows you a pop-up. Vendors change notification behavior often, so check what your version actually does.
This is not just a small detail. The notification is the handoff point, the moment the workflow gives the work back to you. A scheduled task that finishes silently is worse than one you ran by hand, because at least the manual version could not finish without you noticing. If the notification lands somewhere you never look, one of two things happens. Either the output sits unreviewed, or you slowly stop thinking about the workflow at all, and now something is running in your name that you have not checked in weeks.
So set up the one your actual day already runs through, or you will miss the notification entirely and never know the workflow ran.
Two Workflows, Two Very Different Reasons They Work
Here is a real one I built. Every day, it checks email for team members who completed AI enablement training, and drafts a note to that person’s direct manager letting them know. I still review before it sends. Something going out with my name attached gets a human check, no exceptions. It works on the first try every time, because it is simple: one input, one output, no judgment calls in the middle.
Here is a more complicated one. I built a customer meeting prep workflow with a CS team: every Monday, it pulls the last Gong recording (Gong records customer calls) and the email thread since the previous meeting, and builds a deck with talking points and open action items, ready before the call starts. The CSM reviews it before it goes out, not me. That one took real iteration to get right. Complex workflows almost always do. Simple ones tend to work the first time. The ones stitching together a deck, talking points, and a data pull need a few rounds before the output is actually what you wanted.
The difference is judgment calls. The training note has none. The meeting prep workflow is full of them: which parts of the recording matter, which action items are already resolved in the email thread, what belongs on a slide versus what is noise. Every judgment call is a place where the first version will guess wrong, and you only find out which guesses were wrong by looking at real output. That is not a flaw in the tool. It is just what “complex” means.
Notice one more thing about those two workflows: who approves is not the same person. I review the training note because my name is on it. The CSM reviews the deck because the customer relationship is theirs. Approval belongs to whoever owns the consequences of the output, not whoever built the workflow. When you set up the approval step, that is the real question: not who built this, but whose name is on what goes out.
Once a workflow is right, ask AI one more question: should this be a reusable skill the rest of the team can run too. If you built it once and it is useful, do not keep it to yourself.
Something like: “I have now done this same task three times, the same way each time. Here is what stayed consistent: [describe it]. Should this become a reusable skill? If yes, write the skill instructions for me, and flag anything in my process that is still inconsistent between runs before you lock it in.”
That last clause matters as much as the first part. A skill built from an inconsistent process just makes the inconsistency reusable too.
The Reusable Version Comes Last
The order matters here, and it is easy to do backward. Do not build the shareable version first. Do the task for real once, with a real draft, a real spreadsheet, a real folder. Fix the output until it is correct. Then save that as the reusable skill. Build it cold, before you have run it for real even once, and you get something generic that mostly does not fit.
The work worth turning into a skill is the kind your team keeps re-explaining to each other, the same request handled the same way every week. A one-off is not it. A pattern is.
Sometimes a big workflow has one small step inside it that is useful on its own. Pull that step out as its own little job, and let the bigger workflow call on it when it needs it. The small piece stays easy to fix by itself, without you cracking open the whole workflow and risking the rest of it. Smaller and more focused is easier to reuse, swap, or repair.
Then there is sharing. As of this writing, on Claude’s paid Team and Enterprise plans, an admin can switch on a setting that lets people share skills across the whole organization, and when you update a shared one, everyone using it gets the change automatically. On a free or individual plan, keep the instructions in a shared file, a drive folder everyone can reach, that teammates copy into their own setup. Plan names and what each tier includes change often, so confirm what your plan currently offers.
This is not a Claude-only trick. Copilot Cowork runs on the same underlying technology, and shareable skills work the same way there. Build it, save it, hand it to your team, in either tool.
The Loop Is Not “Walk Away”
People hear “automate it” and picture stepping back entirely. That is the wrong picture. The actual loop is: automate, schedule, get notified, approve. Four steps, and the last one never goes away.
Each step answers a different question. Automate answers can this run without me doing the work. Schedule answers can this start without me remembering. Notify answers will I know it happened. Approve answers does this ship. The first three exist to protect the fourth. You automate and schedule so your only remaining job is the one that actually requires you: judgment on the output.
The workflow runs on its own. You still read the output. Your name still goes on what goes out. If something is wrong, you are the one who catches it, not the tool. That has been true since the first post in this series, and scheduling something does not change it. It just changes when you show up in the process, not whether you show up at all.
Iterate as Trust Builds
You do not need the finished version on day one. Start simple, get comfortable, then add the next step, the way my colleague did across three versions of the same workflow.
“Get comfortable” is doing real work in that sentence. It means the current version has stopped surprising you. You review the output and there is nothing to fix, again and again, until reviewing starts to feel almost boring. Boring is the signal. Boring means the workflow has earned the next step. If you are still catching mistakes in version one, version two is not ambition, it is just a faster way to produce mistakes.
Trust is built by output, not by setup. No amount of careful prompting on day one substitutes for watching real results over real weeks. That is why my colleague’s path took three versions, not one. Each version ran long enough to prove itself before the next manual step came out.
Each addition should remove one more thing you were doing by hand. If an addition does not remove manual work, it is probably decoration, not progress.
It is running without you now. Which is exactly when a quieter question shows up.
Next up: if you just built the thing that does your work, what stops someone from noticing they no longer need you?
Leave a Reply