Catalogue › Copilot Cowork › cowork-use-case-assessment

Cowork use-case assessment

Assesses whether a specific piece of work suits delegation to Copilot Cowork, or is better served by Copilot Chat, an agent, an automation, a Copilot Code build or no AI, by testing outcome clarity, verifiability, context access and consequence. Use when a person or team proposes handing a task to Cowork, when Cowork results disappoint, or when a team cannot decide between Cowork and an agent.

Department

Copilot Cowork

Lifecycle

Envision, Deliver

Maturity

adopter, builder, scaler, ai-enterprise

Risk tiers

0, 1, 2, 3

Platforms

copilot-cowork, copilot-chat, m365-copilot, m365-agents, power-platform

Editions

starter, scale, enterprise

Reviewers

design-authority

Status

draft

Copilot Cowork

Copilot Cowork plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

Copilot Cowork is attractive because it promises to take a whole piece of work off someone's desk. That promise makes it easy to delegate the wrong things: tasks whose outcome nobody can describe, work whose result nobody can check, or recurring processes that should be an automation or an agent. This skill tests one proposed task against a short set of criteria and gives a clear verdict: suits Cowork, suits Cowork with conditions, or belongs elsewhere, with the reason recorded. It goes wrong when the verdict is driven by enthusiasm for the tool rather than by the shape of the work.

When to use

• A person or team proposes delegating a specific task to Cowork and wants a sense check first.
• A Champion or adoption lead is triaging candidate Cowork scenarios from a team.
• Cowork has been tried on a task and the results were poor, and someone asks whether the task was ever a good fit.
• A team cannot decide whether a need is a Cowork task, an agent or an automation.

When not to use

• Deciding at intake whether a framed business opportunity needs AI at all, across every pattern - use opportunity-management:ai-suitability.
• Assessing whether a reusable agent is warranted for a defined audience - use m365-agents:agent-opportunity-assessment.
• Deciding whether an outcome needs software built with Copilot Code - use copilot-code:code-use-case-assessment.
• Splitting a task that already suits Cowork into delegated and human-held parts - use copilot-cowork:work-delegation-design.
• Assessing a fixed, rule-based process for automation - use automation:automation-assessment.

Questions to ask first

1. What is the finished output, in one sentence, and how would the person who asked for it know it is right?
2. How often is the task done, by whom, and does it vary each time or follow the same steps?
3. Which files, mail, meetings or data does the work draw on, and can the person delegating already open all of them?
4. What happens if the output is wrong and nobody notices: an awkward draft, a wasted hour, or a decision, payment or message with real effect?
5. Is there already an agent, automation, published prompt or tested Cowork task design that does most of this?

Required inputs

• A plain description of the task and its finished output, from the person who would delegate it.
• The frequency of the task and the roles who do it today.
• The sources of information the task uses, at the level of "the project site and the supplier mail folder".
• The organisation's current position on Cowork use, from copilot-cowork:cowork-governance where it exists.

If the person cannot describe the finished output, the assessment stops there and the task goes back for clarification. Never assume Cowork is enabled, licensed or permitted for a team; mark it to confirm.

Decision framework

Score the task against each criterion. A task suits Cowork when every row is at least "acceptable".

Route by the failing row: unclear outcome goes back to the requester; single questions go to Copilot Chat; fixed sequences go to automation; daily shared needs go to an agent; outcomes that are working software go to Copilot Code; consequential decisions about people go through risk classification before anything else.

Practitioner approach

Begin with the output, not the task. Ask the person to describe what will be on their screen when the work is finished: a briefing pack, a comparison table, a set of draft replies, a reconciled tracker. If they describe activity ("go through the supplier emails") rather than an output, keep asking until there is a thing that can be judged. Delegation without a defined output produces long, plausible work that nobody can accept or reject.

Then test verifiability honestly. The value of delegating comes from the gap between the effort to produce and the effort to check. If checking a supplier comparison means re-reading every contract, the gap has closed and Cowork adds risk without saving time. Ask the delegator how they would spot an error, and whether they would be the right person to spot it.

Look at the shape of the work. Cowork earns its place on multi-step work that mixes finding, reading, judging and drafting across several sources. A one-off question is better asked in Copilot Chat. A process that runs the same way every time on structured inputs is better as an automation, because it will behave identically on each run and can be monitored. A capability that a whole department needs every day is better as an owned agent with tested knowledge.

Check context early. Cowork works with what the delegating person can reach, so stale folders, overshared sites and mail threads with conflicting versions become stale, overshared or conflicting outputs. If the sources are clearly in poor shape, the verdict is "suits Cowork with conditions" and the condition is copilot-cowork:grounding-readiness.

Weigh consequence last, because it changes the controls rather than the fit. Draft outputs a person reads and edits suit Cowork well. Outputs that send, publish, file or change something need explicit approval steps, designed with copilot-cowork:human-checkpoint-design. Work that would inform decisions about individuals, money or rights needs a risk tier from opportunity-management:risk-classification before anyone delegates it.

Finally, look for reuse. Ask the Champion network or CoE whether a tested task design, agent or flow already exists. Record the verdict, the criterion that decided it, any conditions and the route for work that does not fit. Keep the record short: a few lines per task is enough, and similar tasks can share a precedent.

Product capability changes often. Before ruling a task in or out on a specific Cowork feature, plugin or limit, check the current source records rather than relying on memory.

Outputs

• A Cowork fit verdict per task: suits Cowork, suits Cowork with conditions, or route elsewhere, with the deciding criterion.
• For tasks that fit, the conditions to meet first and the hand-off to delegation and context design.
• For tasks that do not fit, a referral to the right route with a one-line reason the requester can understand.

Microsoft platform considerations

Copilot Chat, Copilot in the Microsoft 365 apps, Copilot Cowork, agents and Power Automate overlap at the edges. Use the shape of the work to choose, then confirm current Cowork capability, customisation through plugins, skills and custom instructions, and availability in the source records (ms-copilot-cowork-customise, ms-agents-extensibility). Do not promise a feature to a team until the source record and the organisation's governance position both confirm it.

Adoption considerations

A "route elsewhere" verdict is still help: tell the requester where to go and why. Teams who hear only "no" stop experimenting. Collect good-fit tasks as candidate scenarios for copilot-cowork:cowork-adoption.

Knowledge considerations

Fit depends on the condition of the sources the task draws on. Name them in the verdict and flag obvious problems (duplicates, out-of-date material, unclear owners) for copilot-cowork:grounding-readiness.

Security and privacy considerations

Cowork acts with the delegating person's access. If the task would surface content that person should not see, or move information to an audience who should not see it, the task does not fit until access is fixed. Route doubts to security-privacy:data-exposure-review.

Responsible AI considerations

Tasks that inform decisions about people, money, safety or rights are not ruled out automatically, but they need a risk tier and explicit human decision points before delegation. Some tasks should not be delegated at all; say so plainly.

Evaluation requirements

Not applicable at assessment stage beyond the verifiability criterion; evidence that a task works reliably is gathered later in copilot-cowork:workflow-validation.

Value measures

Record the current effort and delay for the task (from the team's own estimate or records) as the baseline, and the measure the team will use, such as turnaround or rework. Measure at team or role level, never for individuals.

Scale notes

Starter

A short conversation and a few lines per task, held by whoever leads AI adoption. Most early tasks are drafting and summarising work that fits well with a final human review.

Scale

Champions run the assessment with teams using the shared criteria, and the CoE keeps a library of precedents so similar tasks get the same verdict across business units.

Enterprise

Business-unit spokes assess locally against the shared criteria; anything at risk tier 2 or above, or any task that sends, files or changes records, is confirmed by the hub before delegation.

Hand-offs

• To copilot-cowork:work-delegation-design when the task suits Cowork.
• To copilot-cowork:grounding-readiness when sources are a condition.
• To opportunity-management:risk-classification when the output could affect people, money or rights.
• To m365-agents:agent-opportunity-assessment, automation:automation-assessment or copilot-code:code-use-case-assessment when the work belongs elsewhere.

Reviewer gates

From risk tier 2, the verdict is open to challenge by design-authority through design-authority:platform-fit-review for choosing Cowork where an owned agent or automation would be safer or more reliable. Below tier 2, the CoE lead or adoption lead records the verdict.

Failure modes

• A task is delegated because the tool is new, not because the output can be defined and checked.
• A recurring process is run through Cowork by many people with different instructions, producing inconsistent results that an automation would have avoided.
• The delegator cannot verify the output, so errors pass straight through into decisions.
• Cowork is promised for a team before the organisation has decided its governance position or confirmed availability.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Approve a task for Cowork when nobody can describe its finished output.
• Treat Cowork as the answer for a recurring, rule-based process that an automation would run more reliably.
• Delegate work that decides something about a person without a risk tier and an explicit human decision.
• Assert Cowork availability, licensing or limits from memory.