How a Governed Microsoft 365 Copilot Adoption Cut Document Prep Time by 71% for a City Government Organization

This case study explains how Code Creators guided Copilot adoption for a mid-sized city government organization, expanding Microsoft 365 Copilot from senior leadership to departments across the organization through government document automation, Copilot data governance, and structured Copilot end user training, cutting document preparation time by 71% and reaching 68% active adoption within six weeks of go-live. 

Executive Summary 

A mid-sized city government organization with 850 employees reduced document preparation time by 71% and reached 68% active Copilot adoption within six weeks of a phased Microsoft 365 Copilot rollout led by Code Creators, a Microsoft Solutions Partner. The organization had already provisioned Copilot licenses for senior leadership but needed a structured way to extend adoption across departments without compromising Copilot data governance or public-sector security standards. 

Code Creators delivered a three-part engagement built around government document automation: a Copilot Assessment covering licensing, access, and data governance; Copilot Configuration across Teams, Outlook, and SharePoint; and hands-on Copilot end user training for both staff and administrators, including train-the-trainer sessions to support ongoing internal adoption. 

Key Results 

1. 71% reduction in time spent preparing internal reports and correspondence, from an average of 7 hours per staff member each week down to about 2 hours per staff member each week 
2. 68% active Copilot adoption across pilot departments within 6 weeks, 82 of 120 licensed pilot users using Copilot on a weekly basis 
3. 100% of the 18 in-scope SharePoint sites brought into alignment with least-privilege access before Copilot activation 
4. 8 hours of structured training delivered, backed by a User Manual, Admin Manual, and Copilot Support Guide

About the Client

The client is a mid-sized city government organization with approximately 850 employees, responsible for delivering public services across multiple departments, including administration, public works, finance, and community services. Like many public-sector organizations, it operates in an environment where data handling and access control carry both compliance and public-trust implications. Resident records, internal correspondence, and departmental documentation all require careful governance. 

The organization had already taken an early step into AI adoption, provisioning Microsoft 365 Copilot licenses  for senior leadership. But scaling that access to department staff, and using it for government document automation such as reports, memos, and correspondence, raised a harder question: how do you extend a powerful AI assistant across a Microsoft 365 environment that has grown organically over years, without knowing exactly what content it might surface or to whom? 

This mattered because local government environments often carry accumulated complexity, legacy SharePoint sites, inconsistent permission structures, and departments operating with different levels of data hygiene. Before Copilot could be handed to more staff, the organization needed confidence that access boundaries would hold and that IT could demonstrate governance if ever asked to. 

The Problem 

The Issue 

Departments across the organization were spending significant time each week manually drafting reports, internal memos, and correspondence. Based on a two-week time-tracking sample the organization ran across Finance, Administration, and two other departments ahead of the engagement, staff were spending an average of 7 hours per person each week on this manual drafting work. Microsoft 365 Copilot licenses had already been provisioned, but only senior leadership had access; front-line and department staff, who were doing the bulk of this manual drafting work, had no path to the tool yet. Meanwhile, the underlying Microsoft 365 environment itself hadn’t been validated for a broader rollout. Permissions, sharing links, and data classification had accumulated organically across departments over several years without a full review. 

The Impact 

The immediate operational cost was time: staff across Finance, Administration, and other departments were absorbing roughly 7 hours of manual document preparation each week, per the pre-engagement time-tracking sample, that a properly governed Copilot deployment could have offset. That cost compounded because the organization was already paying for Copilot licensing without realizing productivity value from most of the seats: capability sitting unused while the manual workload continued. It also created an internal credibility gap: staff were aware leadership had access to a tool they didn’t, without a clear timeline for when or how that would change, which made it harder to build momentum for AI adoption more broadly. 

The Risk 

The larger risk sat behind the productivity gap. Microsoft 365 Copilot draws on whatever content a user’s existing permissions allow it to see, and in an environment where sharing links, guest access, and departmental folder structures had accumulated over time without a full audit, expanding Copilot access broadly without first validating that structure risked surfacing content to the wrong audience. For a public-sector organization, that’s not just an IT risk; it’s a public accountability risk, since any data exposure involving resident records or internal correspondence carries reputational and compliance consequences beyond a typical private-sector incident. 

Left unresolved, the organization faced a choice: keep Copilot access limited to leadership and forgo the productivity gains staff could realize, or expand access quickly without validating the underlying permission structure and accept the exposure risk that came with it. Neither option was acceptable on its own, which is what made a structured, assessment-first approach necessary rather than optional. 

What We Discovered 

Code Creators began with a Copilot Assessment covering the organization’s Microsoft 365 environment, reviewing existing Microsoft 365 E3/E5 and Copilot add-on licensing, user provisioning, and departmental requirements to understand who actually needed access and what the rollout boundary should be. 

The assessment focused specifically on three areas that would determine whether a broader rollout could be done safely: 

1. User permissions across SharePoint, Teams, and Outlook, analyzed to confirm Copilot would only ever surface content each user was already authorized to see. 
2. Microsoft Purview configuration, including sensitivity labels, information protection settings, data classification rules, and access auditing, reviewed to understand what governance tooling was already in place versus what needed to be configured. 
3. Data storage and usage patterns, reviewed to identify gaps or risks, including several SharePoint sites with broader sharing settings than intended, a common byproduct of departments managing their own folder structures over time without central oversight. 

How was the permission review carried out? 

Code Creators exported a full sharing and membership inventory across the organization’s 47 SharePoint sites, covering active sharing links, guest account access, and Teams membership, and cross-referenced each site against the department that owned it. This inventory was the input for deciding which sites were ready for Copilot and which needed remediation first. 

How was the Purview review carried out? 

Separately, Code Creators reviewed the organization’s existing Microsoft Purview configuration: which sensitivity label taxonomy was defined, where those labels were actually applied versus just available, whether DLP policies covered Finance and HR content specifically, and whether audit logging was enabled and retained at the site level rather than only tenant-wide. 

What the reviews found? 

The two reviews surfaced three specific gaps. First, 23 of the 47 SharePoint sites had at least one guest account with no recorded activity in over a year, mostly tied to former contractors and vendors. Second, a four-tier sensitivity label taxonomy existed in Purview but had been manually applied to only about 31% of eligible document libraries, meaning most content was technically unlabeled even though the framework to label it was in place. Third, tenant-wide audit logging was active, but per-site alerting for unusual access patterns wasn’t configured for any of the sites reviewed. 

How in-scope sites were selected? 

Rather than waiting to resolve all 47 sites, Code Creators and the organization selected 18 SharePoint sites tied to the four pilot departments, Finance, Administration, and two additional departments, as the Phase 1 boundary. Selection criteria were document-drafting volume (how much of each department’s manual reporting workload Copilot could realistically offset), and permission readiness (how close each site already was to a clean, least-privilege state). Those 18 sites became the “in-scope” set referenced throughout this case study; the remaining 29 sites were documented for a later governance phase rather than blocking the initial rollout. 

This discovery phase confirmed that the organization’s Copilot data governance gap wasn’t a lack of tooling, Microsoft Purview was already available, but a lack of applied configuration. Closing that gap on the in-scope sites first was the precondition for a responsible rollout, not an optional add-on to it.

The Solution

Code Creators recommended a sequenced approach, assessment, then configuration, then training, rather than enabling Copilot for all departments at once. The reasoning was straightforward for a public-sector client: governance has to be demonstrably in place before broader access is granted, not verified after the fact.

Copilot Assessment

Copilot Assessment established the Copilot data governance baseline: license and access review, a Microsoft Purview security and compliance review covering sensitivity labels, DLP policies, and access auditing, and a defined rollout scope and target department list based on the findings.

Copilot Configuration

Copilot Configuration translated those findings into baseline compliance and security settings, configuring data access policies and content boundaries, setting up minimal viable compliance controls in Purview, and tightening SharePoint, Teams, and Outlook permissions to limit unnecessary data access. Copilot licenses were then assigned to the defined user groups; because Copilot respects each user’s existing permissions rather than requiring separate activation per application, that licensing step is what extended consistent, governed access across Word, Excel, Outlook, Teams, and SharePoint to support government document automation across reports, memos, and correspondence.

Copilot End User Training 

The training closed the loop with 8 hours of structured sessions for both end users and administrators, including train-the-trainer components so the organization’s own staff could support ongoing adoption without depending indefinitely on outside consultants. Sessions were backed by three supporting documents built specifically for the organization’s configured environment: a User Manual, an Admin Manual, and a Copilot Support Guide. 

The engagement used entirely out-of-the-box Microsoft 365 Copilot capabilities across Teams, Outlook, and SharePoint, no custom development was needed to hit the Phase 1 goals, keeping the rollout fast while more advanced automation was intentionally scoped for a later phase. 

Challenges Overcome 

Legacy SharePoint permissions were broader than anyone realized

Several departmental SharePoint sites had accumulated sharing links and guest access grants that were broader than staff realized, some dating back years to external contractors whose engagements had ended without access ever being revoked. Rather than pausing the entire rollout for an organization-wide audit, Code Creators scoped a targeted review focused on the 18 in-scope sites, closing the most significant gaps first. 

Departments had inconsistent folder and naming conventions

Because departments had organized SharePoint content independently for years, document structures varied widely, some used clear, dated folder hierarchies, while others relied on flat folders with inconsistent file naming. This directly affected the quality of Copilot’s contextual responses, since the tool relies partly on structure and metadata to locate and summarize relevant content. Code Creators addressed this with lightweight, department-specific guidance on folder and naming conventions during Configuration, rather than mandating a full reorganization that would have delayed the rollout. 

Balancing speed with public-sector risk tolerance

IT leadership was understandably cautious about moving quickly on anything touching data access. Every configuration decision was tied directly back to assessment findings, giving IT a clear, defensible rationale for each access boundary. 

Lessons Learned 

Governance readiness is a prerequisite, not a parallel track

The clearest lesson from this engagement was that attempting to configure Copilot access at the same time as reviewing permissions would have been far riskier than sequencing the two. Completing the assessment first, and treating its findings as a gate before configuration began, meant every access decision was made with full visibility into the environment’s actual state, not assumptions about it. 

Content structure quietly determines AI output quality

Departments with cleaner, more consistent SharePoint structures saw noticeably better Copilot responses from day one, while departments with flatter, less organized content needed more coaching to get comparable value. This reinforced that AI readiness isn’t just a licensing and permissions question, document hygiene has a direct, measurable effect on how useful the tool feels to end users. 

Internal champions accelerate adoption more than volume of training does

The train-the-trainer component of Copilot end user training proved to be a disproportionately high-value investment. Departments with an engaged internal champion reached higher weekly usage rates faster than departments relying solely on the initial training sessions, suggesting that ongoing peer support matters more for sustained adoption than the number of formal training hours delivered upfront. 

Documenting deferred work builds trust

 Rather than presenting the rollout as fully “done,” explicitly documenting the SharePoint sites and departments still pending a full permissions cleanup gave IT leadership a transparent, prioritized roadmap, and made it easier to secure support for a follow-on governance phase rather than treating it as unfinished business. 

Results & Business Impact 

Within six weeks of go-live, the rollout produced measurable results across productivity, adoption, and governance:

Results Snapshot

1. 71% reduction in time spent preparing internal reports and correspondence: from an average of 7 hours per staff member each week (pre-engagement baseline) down to about 2 hours per staff member each week 
2. 68% active Copilot adoption across pilot departments: 82 of 120 licensed pilot users using Copilot on a weekly basis by week 6 
3. 100% of the 18 in-scope SharePoint sites brought into least-privilege alignment before activation 
4. 8 hours of structured training delivered across user and admin tracks 
5. 5 hours/week saved per staff member on average (7 hours before, 2 hours after), the direct driver of the 71% reduction above 
6. 3 supporting reference documents (User Manual, Admin Manual, Copilot Support Guide) adopted as standing internal resources 

• Productivity gains by function. Staff in Finance and Administration used Copilot within Outlook and Word to draft correspondence, budget summaries, and internal reports significantly faster, contributing to the drop from an average of 7 hours to about 2 hours per staff member each week on manual document prep. Teams-based meeting summarization cut a typical 45-minute follow-up write-up down to about 15 minutes, and several departments used Copilot in SharePoint to locate and summarize policy documents and past correspondence that previously required manual searching.
• Adoption trends. Weekly active usage climbed steadily over the six-week window, from 31 of 120 licensed pilot users active in week 1 to 82 of 120 by week 6, rather than spiking and tapering off.
  
  
• Governance outcomes. The access-alignment work completed during Configuration meant Copilot’s rollout didn’t introduce any new data exposure across the 18 in-scope sites, a result IT leadership could point to directly when reporting on the initiative to city administration.
  
  
• Longer-term positioning. Beyond the immediate productivity numbers, the engagement left the organization with reusable assets, the User Manual, Admin Manual, and Copilot Support Guide, that reduce dependency on outside consultants as adoption extends to additional departments, and establish the governance foundation the organization would need before considering Microsoft 365 Copilot agents for multi-step workflow automation in a future phase.
  

Client Testimonial 

“We had Copilot licenses sitting with leadership for months because we weren’t confident about what it would be able to see once we opened it up further. Code Creators didn’t just turn it on; they showed us exactly where our permissions needed cleanup first. That’s what let us move forward with confidence.” 

IT Director 

Considering Copilot Adoption for Your Organization? 

If your organization is weighing how to safely expand Microsoft 365 Copilot access without compromising data governance, a phased, assessment-first approach can get you there without unnecessary risk. Schedule a Copilot readiness consultation to talk through your environment.