How to pick the right workflow, design useful skills, and prove the work got better
Matt Wolodarsky, a principal program manager at Microsoft, has led an early access program, testing out how skills in SharePoint can drive value for customers.
You can roll AI out and still have nothing to show for it. We've all seen the headlines about companies spending big on AI and getting little back. But it doesn't have to go that way. Over the past few months, I've worked alongside teams doing the opposite - one got a usable proposal draft in a fraction of the time it used to take; another got a clear read on where a project actually stood, when the information they needed was scattered across documents and hard to surface. What ultimately set these teams apart was how intentionally they applied Copilot to real work.
This is where skills matter. In SharePoint, skills transform Copilot from a general-purpose assistant into a specialist grounded in your content, policies, and business logic - enabling it to perform meaningful work on your behalf. They capture the repeatable judgment your teams already use to make decisions and move work forward. The rules your legal team applies when reviewing marketing content before it goes live? That’s a skill. The rules that determine whether a vendor is approved, needs additional review, or can move forward? That’s a skill. The process your project team uses to identify risks and turn them into action? That’s a skill.
Each skill is valuable on its own - it does a specific job well and delivers immediate impact. But the real power comes from how they work together. When you start chaining skills together in SharePoint, you move from solving individual tasks to solving the full workflow.
I’ve spent the last few months working with a handful of customers doing exactly this. I started to see patterns - which workflows create momentum, and which ones look promising in a demo but struggle when real users and real content get involved. A few things consistently show up:
- Pick the right workflow. Most failures start here.
- Build it the way work actually happens. Not the way it should.
- Make it stick. Adoption and proof decide whether it keeps running after the pilot.
Pick the right workflow
This is where most workflows either take off or stall. Get the workflow right, and everything else has a chance to work. Get it wrong, and it rarely gets off the ground.
You see it when you start working through real scenarios. Some workflows don’t just look promising - they solve the problem in front of you. You can trace the inputs through to a clear outcome, and the value is obvious. Others never quite get there.
At that point, it’s not a tooling problem - it’s a selection problem. Before you build anything, pressure test it. I use a simple three-question filter to decide which workflows to enhance with Copilot in SharePoint:
- Is it worth building? There’s enough repeatability to justify the effort, and enough value to make reuse worthwhile.
- Is it a content-centric process? When the work is driven by content, Copilot in SharePoint can access the right source material, follow the rules encoded in the skill, and produce an output the team can review, reuse, and build on.
- Is there a clear, repeatable way to get to the right outcome? Repeatable doesn't mean identical - each draft or decision differs - it means there's a known standard for what "good" looks like and a consistent path to reach it. That's what a skill encodes and applies at scale.
When you run those three questions, certain patterns show up:
What passes:
- Proposal drafting
- Contract or policy compliance verification
- Procurement or vendor evaluation
- Risk identification and mitigation planning
- Launch readiness or go/no-go reviews
What fails:
- One-off creative work - no repeatability, nothing to compound
- Open-ended brainstorming or ideation - no fixed target and no shared standard for a "right" result, so there's nothing for a skill to encode
Proposal automation is a good example. The work repeats, the source material usually lives in SharePoint, and strong proposals follow a clear playbook: answer the RFP, hit the win themes, reuse approved content, and stay on voice. I’ve seen teams aim for a 60% complete first draft, with AI skills extracting requirements, mapping them to approved content, and flagging compliance gaps before the first review. That can save hours and give the pursuit team a stronger starting point.
The RFP Response Engine sample shows this proposal automation pattern in practice. You can find the sample skills in the pnp/sharepoint-skills GitHub repo, under Skills, by looking for the folders prefixed with rfp-response-. They can be used individually or adapted together as a connected proposal workflow.
Build it the way work actually happens
Once you have picked a workflow worth building around, the next question is whether the skill matches the real shape of the work.
The tempting version of proposal automation is: “Give AI the RFP and draft the response.” But in real workflows, writing is often not where the work starts. The first challenge is turning a messy RFP, scattered across paragraphs, tables, appendices, and evaluation criteria, into a working checklist. A useful skill starts there: extracting requirements, normalizing overlaps, flagging inconsistencies, and categorizing items.
Now the team is not starting with a blank spreadsheet and a long, messy document. They are starting with a structured first pass they can review, correct, assign, and build on.
A strong skill does not just produce an impressive output. It turns messy work into structured work, captures repeatable judgment, and gives the next person a clearer decision to make.
Once you see it that way, a few building lessons fall out.
- Skills beat prompts the moment judgment needs to be consistent
Ad-hoc prompts work for one person, one time. But when the same decision or output needs to be repeated consistently, the judgment needs to be codified. In a proposal workflow, that might mean prioritizing approved references from the same industry, flagging unsupported claims, and escalating anything that requires pricing, legal, or delivery-owner input.
- Build around the handoff, not the AI task
The natural instinct is to define skills around what AI can do: summarize this, draft that, extract these fields, generate this response.
But the better starting point is the handoff: what does the next person in the workflow need to move the work forward?
In an RFP workflow, the useful skill may not be “draft the answer.” It may be “create the response checklist,” “map requirements to approved source content,” or “prepare the reviewer’s decision packet.”
That shift matters. AI tasks produce outputs. Good handoffs move the work forward.
- Design the human checkpoint before you design the automation
In one vendor evaluation scenario we worked through with a customer, the skill scored responses and produced a ranking with rationale. On paper, the reviewer still had the final say. In practice, the output looked complete and re-evaluating it took more effort than accepting it.
That is the trap. A checkpoint only works if the reviewer has a real decision to make, clear evidence to inspect, and a reason to override when something looks wrong.
The fix is not more review. It is better review design: confirm the criteria up front, show the evidence behind the recommendation, and require a reason for approvals or overrides.
Skills that work long-term do not remove the human from the loop. They put the human where judgment matters most.
- Site memory turns one-shot AI into shared proposal context
Copilot in SharePoint does not have to start from zero every time someone uses it. With site-level memory, a team can capture rules and lessons once and apply them across future work on the site.
A lost bid is a good example. If the feedback was, “Evaluators could not tell what they would actually receive at the end of each phase,” the team can turn that into a reusable rule: future implementation plans should include a phase deliverables table with named outputs, formats, and approvers.
The next proposal writer does not need to know about the lost bid or remember the instruction. Every proposal can start stronger because the site remembers what the team learned last time.
Make it stick
Building the workflow is not the finish line. In some ways, it is where the harder work starts.
Even a good skill can fail to become part of the team’s normal workflow. Usually, it fails for one of two reasons.
The first is abandonment. People try it once or twice, decide it is interesting but not essential, and drift back to the old way of working. If the skill doesn't clearly make a core part of the job faster, easier, or better - something people do often and genuinely care about - it stays a nice-to-have, and nice-to-haves get dropped the moment things get busy. The skills that survive are aimed at work central enough that skipping them costs more than using them.
The second is fuzzy proof. The team believes the skill helped, but cannot show how much time it saved, how much rework it reduced, or whether the output got meaningfully better.
I would not treat adoption and measurement as launch-plan items. They need to shape the workflow from the start.
Adoption breaks in four places
When I look at the workflows that stick, they usually get four things right:
- Value: Does the skill make the work faster, easier, or better?
- Effort: Do people get through their first few uses without feeling slower than before?
- Trust: Can they see sources, rationale, and checkpoints clearly enough to review the work?
- Fit: Does it match the real handoffs, exceptions, and decision points in the workflow?
For a proposal team, legal team, or project team, the pattern is the same: the skill must make the next task easier. It should give people source-grounded work they can inspect, a clearer handoff, and a workflow that fits how the team already moves from intake to review to decision.
Usage is not proof
A common mistake is treating usage as the main success metric.
Usage matters, but it is not proof of business value. A team can use AI hundreds of times and still see no meaningful improvement in the work. They may be experimenting, rewriting prompts, checking answers, or using it for low-value tasks.
The better question is: did the workflow improve?
For many content-centric processes, three signals matter most: time saved, cycle time, and rework. Did the work get faster? Did the process move from start to finish more quickly? Did the team need fewer review cycles before it shipped?
Do not launch with a dashboard full of metrics. Pick the one number that would make a leader say, “Yes, this is worth scaling.”
For proposals, that might be hours saved getting to a usable first draft. For policy review, fewer missed compliance issues. For launch readiness, faster time from readiness review to launch decision.
The goal is not to prove people ran the skill. It is to prove the work got faster, cleaner, or easier to ship.
Copilot in SharePoint will bring AI into more of the places where people already work. But access is only the starting point. The real test is whether teams can turn that access into better workflows: choosing the right process, building around how the work actually happens, and proving the result was worth it.
A quick checklist
Pick the right workflow
- Start with one workflow worth improving - repeatable, content-driven, with a clear outcome.
Build it the way work actually happens
- Model the messy real workflow, not the ideal one.
- Codify judgment so the same decision comes out consistently.
- Build around the handoff and the human checkpoint - move the work forward, not just the AI task.
- Use site memory so the workflow gets smarter every run.
Make it stick
- Watch the four adoption killers: unclear value, high effort, weak trust, poor fit.
- Prove the work got better - time saved, cycle time, rework - not that people used it.
Build with us!
Bring us your real-world business problem, and we’ll help co-build the solution with Copilot in SharePoint.
If your organization is selected, Microsoft Engineering will partner 1:1 with you at no cost to design, implement, and deploy a Copilot in SharePoint solution in production. Whether you’re looking to streamline knowledge management, automate business processes, or create custom skills, we’ll help you get from concept to deployment. Nominate your scenario.
Learn more
Microsoft