Microsoft Copilot Implementation 2026 — Cost and Permission Design

A directive arrives from the Japanese parent company saying “we are deploying Copilot group-wide,” or you want to build the case from your Thai site upward — either way, we are being asked about Microsoft Copilot implementation far more often by Japanese-affiliated manufacturers in Thailand. The place these projects stumble, though, is not model quality. Copilot never breaks permissions; in exchange, it surfaces everything a person can technically reach in response to a single plain-language question. Years of loosely maintained sharing settings become visible on day one. This article works through how to read the cost, how to run the permission audit, which tasks are worth targeting, and the issues specific to an overseas site.

What this article covers, and what it does not

Articles about generative AI adoption tend to fall into one of two shapes: a feature tour of what the tool can do, or an abstract warning that “data leaks are frightening.” In a real implementation project, however, the effort and the money go into neither features nor fear. They go into the preparation you should finish before you buy a single licence. Skip that, and you can end up paying for the privilege of opening new holes in how information moves inside your company.

Here is the scope of this article.

If you want the wider picture first, including options other than Copilot, our enterprise generative AI comparison for 2026 sets out the axes for comparing the main tools. This article sits inside that landscape and drills into one option in depth: putting Copilot into a Microsoft 365 environment.

One note on figures. Throughout this article we clearly separate prices listed on Microsoft’s official pricing page at the time of writing from secondary sources such as press reporting. Licence pricing is an area where revisions happen, so when you build an actual quotation, always confirm the current official information and check with your Microsoft partner.

What you should settle before Microsoft Copilot implementation: what Copilot actually is

Not a “model” but a window connected to your own data

When you explain Copilot internally, there is one point worth aligning on first. Copilot is not a chatbot that answers from knowledge on the open internet. It is a window connected to the data sitting inside your own Microsoft 365 tenant.

That distinction changes the preconditions for adoption at the root. A general-purpose chatbot can be handed out without thinking about its relationship to internal data. Copilot, by contrast, composes answers by referring to your information assets: mail, Teams chats, SharePoint files, personal OneDrive areas, calendars. It follows that answer quality depends heavily on the quality and the breadth of the information each individual can access.

The critical property here is that Copilot does not break permissions. A file an employee has no rights to will not appear, no matter how they ask. This point is often used to say “and therefore it is safe.” The practical implication, however, runs the other way.

Historically, files with sloppy sharing settings caused no actual harm because nobody ever managed to find them. Typing precise keywords into the SharePoint search box and picking the right item out of a wall of results took real effort. Copilot takes a plain-language question such as “pull together the documents on this year’s executive compensation review” and searches across everything accessible, then summarises what it finds. The cost of searching drops to almost nothing, and that alone brings years of accumulated looseness to the surface at once.

Once you understand this structure, your view of where project time should go changes. Rather than spending the early weeks on prompt-writing workshops, it becomes clear that establishing who can currently access what carries higher priority.

The problem of names getting mixed up in the same meeting

The second thing that reliably happens early in the evaluation is confusion over product names. Several products carry the “Copilot” name, and they differ in audience, in cost, and in permission model. It is not unusual for people in the same meeting to be discussing different things without realising it.

Japanese head offices circulate budget approval documents — the *ringi* that travels from department to department collecting seals before spending is authorised — and when such a document simply says “Copilot implementation,” finance pictures a cost line, IT pictures permissions, and the operating departments picture task assistance. Fixing in one line, at the very start, which product is in scope changes the speed of everything that follows. Where this article says “Copilot” without qualification, it means Microsoft 365 Copilot.

What is genuinely new, and what is not

When you set expectations internally, the following breakdown helps.

Look at the last row. Copilot does not modify your permission model. It creates no new permissions and relaxes none of the existing ones. What changes is only how easily people reach information that already sits inside their permitted range. If that single point is shared internally, you avoid the mistaken narrative that “Copilot leaked something on its own.” What actually happens is that things that were already visible become noticed as visible.

Microsoft 365 Copilot cost and pricing plans in 2026

What it means that this is an add-on

The first thing to grasp when estimating cost is that Microsoft 365 Copilot is an add-on. You cannot contract for it standalone; it is added on top of an eligible base licence. For Copilot Business, aimed at small and mid-sized organisations, a base licence of Microsoft 365 Business Standard or above is required.

The implication is that depending on your current licence mix, you may face the cost of upgrading base licences on top of the add-on cost itself. If you want to give Copilot to a department running on Business Basic, that department first has to move to Standard or above. This uplift is easy to miss while you are looking only at the add-on price.

Here are the values published on Microsoft’s official pricing page.

Prices are shown in Japanese yen because that is how they appear on the pricing page used as the source here; local currency amounts will depend on the price list applicable to your contracting entity. Looking at the combined plans, you can see the gap against simply stacking a base licence and an add-on separately. Which combination works out better depends on your existing licence mix, the timing of your renewal, and seat count, so we cannot say in general terms that one is cheaper. What we can say is that listing out your current base licence breakdown — how many people on Basic, Standard and Premium respectively — puts you at the starting line for any comparison.

For large-enterprise pricing, a figure of ¥4,497 per user per month has been reported. That is not a value published on the official pricing page but a secondary source, so if you put it in an internal document, state the nature of the source and treat it as something to be confirmed in a formal quotation.

What changed during 2026

Several things moved in Copilot licensing and the areas around it during 2026. All of them affect the assumptions behind an adoption plan, so they are worth knowing. The summary below rests mainly on secondary sources, so confirm exact applicability with Microsoft or with the partner holding your agreement.

The change concerning organisations at 2,000 seats and above matters because for companies with large tenants, the assumptions behind a “roll it out to a few departments only” approach may no longer hold. Functionality that was previously usable without charge is reported to have become unavailable on seats with no add-on assigned. If you belong to a large group where the Japanese head office and overseas sites such as Thailand share a single tenant, it is worth checking whether the combined seat count crosses that threshold.

The 1 July base licence price revision, meanwhile, is a cost increase that arrives independently of any Copilot decision. If you mix it into the “here is how much Copilot will add” explanation, the internal discussion drifts toward “Copilot is expensive.” We recommend presenting the Copilot-driven increase and the unrelated increase as two separate lines.

Estimate the cost in five layers

A budget built on licence cost alone tends to come up short at a later stage. The costs that actually arise in a Copilot implementation fall into five layers.

Of these, layer 3 — the permission audit and data preparation — is the body of the project. That is the central argument of this article. Licences can be ordered and used the next day; a permission audit is an internal fact-finding exercise, and it is not work you can hand off wholesale to an outside party. The risk of skipping this layer and rolling out anyway does not show up as a cost problem. It shows up as an information governance problem.

Layer 5, operations, is the other one that gets overlooked. A Copilot licence that has been assigned to someone who does not use it keeps consuming budget indefinitely. Building in an operating rhythm — review usage each quarter and move licences from people who are not using them to people who will — keeps waste from accumulating. Deploy without deciding who owns that rhythm, and a year later nobody is looking at it.

What to measure before you budget

There are items worth confirming internally before you request a quotation, because they sharpen the estimate. Manual tallies are perfectly adequate; just get hold of the following numbers.

The second and third rows in particular govern the scale of the permission audit covered in the next section. Approach a vendor without these numbers and the quotation either stalls at “we would have to investigate first” or comes back built on assumptions that do not match reality.

The permission audit to run before implementation (oversharing remediation)

Because it does not break permissions, the looseness shows through as-is

To repeat, this section is the core of the article. Copilot does not break permissions. It will not read out information a user has no rights to. Problems nonetheless arise because in most organisations the range that is technically accessible is wider than the range that should be accessible for business purposes.

This condition is generally called oversharing. One survey has found an average of 150 to 300 overshared SharePoint sites per corporate tenant. You cannot transplant that number onto your own organisation, but it does serve as material for the argument that “we’re fine” is not a judgement to make without evidence.

Oversharing does not arise from bad intent. In most cases it is the accumulation of ordinary day-to-day operations like these.

The fourth row — labels applied only at container level — is where misunderstanding is most common. A sensitivity label applied to a container (a site or a team) is not automatically inherited by the items inside it (the individual files). The belief that “it sits in a Confidential site, so it is protected” does not hold once you rely on label-based controls. Copilot treats unlabelled items as ordinary candidates for reference. If your organisation operates labels only at site level, check this point without fail.

Picture concretely what would happen

Explaining in the abstract that “there is a data leakage risk” does not move anyone internally. Concrete examples land better. Every one of the following can happen without a single permission being broken.

None of these is Copilot breaking something. They are cases where information that was already reachable under existing permissions simply became easier to reach. That is precisely why the countermeasure is not “restrict Copilot” but “correct the sharing settings.”

The sequence: make it visible, cut exposure, apply labels, then roll out

The volume of work in a permission audit changes enormously depending on whether you keep to the right order. Get the order wrong and it never finishes. The recommended flow is as follows.

Note that in this section we call the steps of this work *phases*. The *stages* used in the roadmap later in the article are a different unit of granularity, so please do not conflate the two.

What matters practically here is that phases 2 and 3 are different in nature. Cutting exposure in phase 2 means removing content from Copilot’s reference scope, a move you can execute in a relatively short period. Labelling in phase 3 begins with building information classification rules; it is durable, structural work measured in months or years.

Where most organisations fail is in making completion of phase 3 a precondition for phase 4. Decide that nothing will be rolled out until labelling is finished, and the project effectively stops. In practice, a workable design is to start the pilot once phase 2 is complete, and run phases 3 and 4 in parallel. That design assumes, however, that phase 2 is genuinely finished. This is the one you must not skip.

Where Microsoft’s own tools fit

Management capabilities provided by Microsoft can carry part of the permission audit. Knowing what they do makes it easier to judge what to outsource.

Restricted Content Discovery becomes clear once you read it as a way to take content out of Copilot’s line of sight before you have finished correcting the sharing settings themselves. Fixing sharing settings one by one takes time. Removing a batch of suspected overshared sites from Copilot’s reference scope, by contrast, can be done in a comparatively short window. That makes it possible to carry out the substantive remediation while still rolling out safely in the meantime.

There is a caveat. A site excluded via RCD is merely invisible to Copilot; anyone with permission who navigates to it directly can still read it exactly as before. You need to understand this as a measure that buys time, not a root-cause fix. Leave sites excluded indefinitely and it eventually returns as an operational complaint: “why doesn’t this document ever come up in Copilot?”

Who actually does this work

The most realistic obstacle in a permission audit is not technical. It is ownership. The IT department cannot complete this alone.

What this table shows is a structural fact: detection can be automated, but judgement can only come from the business. When you draw up the project schedule, therefore, always budget time for business departments to make those judgements. Run it as “we handed it to IT” and a queue of pending decisions forms and the project halts.

A workable approach is to sort the detection results by volume and by risk, then work down the list with the relevant departments. Rather than trying to clear everything at once, it is also effective to prioritise only the scope belonging to the departments scheduled to receive Copilot. That is one of the reasons to start the pilot small.

Separating the work where Copilot delivers from the work where it does not

Results come where the information is already inside Microsoft 365

What Copilot can reference is, in principle, data inside the Microsoft 365 tenant. From that single fact, the set of tasks where results come easily narrows on its own.

Look down the “precondition” column and a common thread appears. As long as material sits in a local folder on somebody’s PC, or on a file server outside Microsoft 365, it is out of Copilot’s reach. A very common configuration at factories in Thailand is a Windows file server or NAS carved into departmental shared folders. In that setup, deploying Copilot does not reach the data people consult most in their daily work.

Before you estimate the benefit of adoption, therefore, you need to confirm where your working data actually lives. Hand out Copilot licences while the move to SharePoint and OneDrive is still incomplete, and the verdict comes back as “less useful than we expected” — which stops the next round of investment.

Say up front where it will not work

Setting expectations means naming the weak areas first. Roll out while leaving this vague, and disappointment on the floor turns into a blanket rejection: “generative AI is useless.”

The third row, tacit shop-floor knowledge, is where manufacturers place the highest hopes for Copilot and where those hopes most often miss. A veteran’s judgement criteria do not exist as files, so no AI, however capable, can reference them. If you want to tackle this area, the work of drawing knowledge out and giving it form has to come first — as set out in our article on supporting skill transfer with AI.

Similarly, if you want answers grounded in your own work instructions, drawings and quality records, that calls for something other than Copilot. The option in that case is building your own RAG, and the design thinking behind it is collected in implementation considerations for handling factory knowledge with RAG. The complaint that “we put in Copilot and it knows nothing about the shop floor” is entirely preventable if you explain this boundary at the outset.

How to face the claim that only one user in four saves time

On the effect of generative AI tools, there is a reported observation that only one user in four has actually reduced their working time. The number is not comfortable for anyone building an adoption case, but it is more useful to understand it structurally than to argue with it.

The plausible reasons break down as follows.

The last row is easily missed. If the time saved gets absorbed by other tasks, the individual’s experience is that “I am just as busy as before.” Unless you design your measurement before adoption, that kind of benefit never makes it into the record. What to measure and how is covered separately in our framework for measuring AI adoption results.

For wider context, PwC Japan’s Spring 2026 survey on generative AI puts the share of Japanese companies actively using or advancing it at 87%, with 4% not started or abandoned. Teikoku Databank’s March 2026 survey, on the other hand, puts the share of companies that are “using it in their work” at 34.5%. The gap between the two figures likely comes from differences in the survey population and question wording, but it does show that there is a wide gulf between “we are working on it” and “we use it in our work.” For anyone evaluating adoption, the latter number probably gives the truer feel for reality.

The same Teikoku Databank survey, broken down by company size, puts that “using it” rate at 46.5% for large enterprises, 32.4% for small and mid-sized enterprises, and 28.0% for small businesses. Separately, among companies that are using it, 86.7% reported that it is producing results in their work. In other words, among firms that have started, the proportion seeing results is high, while the gap by company size lies at the stage of whether they start at all. Note also that 46.5%, 32.4% and 28.0% are usage rates by size, not a size-by-size breakdown of who is seeing results.

In the same survey, the most frequently cited concern was the accuracy of information, at 50.4%. Section managers and team leaders were reported as the group struggling most to use these tools well. Both findings feed directly into implementation design. Answer the accuracy concern by codifying a way of working that assumes verification, and address penetration into middle management by preparing usage examples drawn from that layer’s own daily work. Generic training aimed at junior staff, reused as-is, is unlikely to land with this group. Our thinking on enablement design is collected in how to structure generative AI training for manufacturing.

A work inventory sheet

Running an inventory in this format in the target departments before adoption makes the pilot design concrete.

Ask for three to five entries in this form and you have the material to decide whether that department should receive Copilot at all. If every row in the “completes within Microsoft 365” column says no, that department should be deprioritised. Deciding not to hand out licences is a legitimate part of implementation design.

Comparing with a ChatGPT enterprise deployment, and dividing the work between them (how to choose a generative AI tool)

Think in three categories

The question “should we choose Copilot or ChatGPT?” comes up in almost every internal discussion. Yet the framing of the question itself is drifting away from reality. Forrester’s February 2026 research reports that 34% of enterprise AI deployments use multiple platforms in combination (secondary source). Rather than choosing one, dividing usage by purpose is becoming the realistic picture.

Organising the split into the following three categories makes the judgement easier.

These three are not mutually exclusive. In practice, a common combination is to place category 1 as the company-wide foundation, give category 2 to specific functions such as planning, procurement and quality assurance, and build category 3 individually against particular shop-floor problems. If you step into category 3, the centre of the design becomes how you select the target data and how you maintain accuracy — which we cover in building RAG on factory knowledge.

Points of comparison

Laid out against the criteria that matter for an adoption decision, the three options compare as follows. Note that for pricing, the Copilot figure is from the official pricing page while the ChatGPT Enterprise figure is a reported one.

The reported minimum seat count for ChatGPT Enterprise is a point that bites when you consider contracting from an overseas site on its own. If headcount at the Thai site is below 150, a standalone contract at that site may not be viable. This connects directly to the discussion of the contracting entity below.

Patterns where the selection goes wrong

Here are the judgement errors that tend to appear during a comparison exercise.

That last pattern is especially common at overseas sites. Head office selects a tool on the basis of how work is done in Japan, and the rollout proceeds without ever accounting for the fact that the local site’s primary data lives on a file server. Telling head office early that “our data is here” is what prevents wasted licence spend.

The detailed comparison axes for each option are covered in our enterprise generative AI comparison for 2026, which is worth reading alongside this article if you are still evaluating broadly, beyond Copilot.

Issues that arise when bringing Copilot into an overseas site (a Thai factory)

Where to place the contracting entity

In a Copilot deployment at a Thai site, the matter to settle before any technical question is the contracting entity. Whether the Japanese head office contracts on behalf of the group or the local entity contracts independently changes a great deal about how it is subsequently run.

Most Japanese-affiliated groups share the tenant with head office while recharging licence cost to the site. In that arrangement, the things to confirm are the recharge unit price and what happens when licences go unused. You want to avoid the situation where head office allocates a flat “20 seats for Thailand,” the cost lands on the local P&L, and the licences sit idle.

If you are the one proposing upward from the local site, present specifics — how many seats, for which departments, for what purpose — and state explicitly that the number will go up or down based on pilot results. That makes the conversation much easier to advance.

How to estimate practical quality across languages

At a Japanese-affiliated factory in Thailand, three languages run simultaneously: Japanese, English and Thai. The usual pattern is Japanese expatriates working in Japanese, the management layer working in English, and operators and staff on the floor working in Thai. What becomes a problem here is that the practical quality of generative AI is not level across languages.

This is not a defect of any particular product. It is structural, arising from differences in the volume of training data and in the accumulated stock of business documents. If you do not set expectations at deployment, a sense of unfairness develops: “useful for the Japanese staff, useless for the Thai staff.”

A realistic design is to divide purposes by language. For example, use Japanese and English actively for document drafting and summarisation, while starting Thai from the narrower position of “assistance with translation and summarisation to and from Japanese or English.” Expect complete substitution of Thai-language work from day one and the evaluation will suffer.

There is a second consideration: the language of the internal documents being referenced. Copilot composes answers by referring to documents inside the tenant. If internal documents are predominantly in Japanese, a question asked in Thai still draws on Japanese sources, so the answer passes through translation. At a multilingual site, this structure is unavoidable. In fact, using it so that Thai staff can read through Japanese material is a case where the structure works in your favour. Given how much Japanese technical documentation has historically sat unread at overseas sites, there is a real case for designing around that value deliberately.

Local shared drives are built on “everyone, for now”

This is not unique to Thailand, but at overseas sites there is a particularly pronounced tendency for shared folders and SharePoint sites to be created with access open to everyone as a matter of course.

The reasoning is understandable. In a site’s start-up phase there are few people, and there is neither the capacity nor the need for fine-grained permission design. Work moves faster when everyone can see everything. As the site grows, headcount rises, and people join and leave repeatedly, the original assumption collapses.

The last row demands particular care at a Thai site. Roll out Copilot while information about employee compensation sits in a location with weak permissions, and you can create a situation where “how much does each person earn?” is an answerable plain-language question. In employment-relations terms that is an extremely serious problem. In the pre-deployment audit, confirm the storage locations and access rights for HR and payroll information as the very first priority.

The practical difficulty of running a local permission audit is that nobody who knows the history is still with the company. The person who created a site has left, and nobody can explain why the permissions are the way they are. This happens routinely. In that case, the “can we revert this?” judgement cannot be made, and work stalls. The realistic response is to work down from the highest-risk items and restrict first, then reopen individually if the business is genuinely obstructed. Trying to reconstruct the history of every item means never finishing.

Thailand’s AI investment climate as a tailwind

When you are building the internal case for budget, knowing the state of digital and AI investment in Thailand is occasionally useful.

The Thailand Digital Outlook 2026, as reported by the Bangkok Post, puts the digital maturity of Thai firms at 2.12 out of 4, up from 1.56 the previous year and entering the “moderate” band for the first time. It has also been reported that more than 70% of Thai SMEs are implementing AI, and that Microsoft’s Global AI Diffusion Report ranks Thailand second in the world for AI adoption growth, behind South Korea (secondary source).

On the investment climate, applications to the Board of Investment (BOI) in the first half of 2026 were reported to have reached 1.47 trillion baht across 1,299 projects, up 37% year on year. Of those, 132 projects worth roughly 17.2 billion baht were reported under the “Smart and Sustainable Industry” category.

These figures are useful as counter-evidence to a head-office assumption that “the local operation is behind, so it is too early.” That said, whether the cost of software licences such as Copilot falls within the scope of BOI incentives depends on conditions including industry, the nature of the investment and the application category. Nothing in this article should be taken as establishing that your company qualifies. If you are considering it, confirm directly with the relevant authority or with the BOI.

On running AI adoption in Thailand more generally, a realistic approach to AI adoption at Thai sites covers the local constraints and how to build the team.

When head office and the local site talk past each other

Finally, a word on the most common practical difficulty in AI adoption at overseas sites. It is neither technical nor financial. It is that head office and the local site are not working from shared assumptions.

What the right-hand column has in common is returning facts from the site in the form of numbers. Rather than a subjective “this does not fit us,” present candidate headcount, data locations, language ratios and required effort. That gives head office something it can revise a plan around. Conversely, if no facts come back and a flat distribution is decided, the entire operational burden that follows lands on the local site.

Implementation steps and how to run this internally (roadmap)

The overall flow

Here is everything above, rearranged into execution order. Timescales vary enormously with the size of the organisation and the current state of its housekeeping, so treat this as a guide to sequence rather than duration.

Of these six stages, the most common failure by far is skipping stages 0 and 1 and starting at stage 2. Licences ordered today can be used tomorrow, which makes it psychologically tempting to jump ahead. But a pilot without an articulated objective cannot be evaluated, and a rollout on unremediated permissions is a breeding ground for incidents.

Stage 0: articulate the objective

“Making use of generative AI” is not an objective. What you should write down at this stage is a specific task, and the time that task currently consumes. Use the work inventory sheet shown earlier and ask each department for three to five entries.

The thing to watch here is whether the tasks that come back really do complete inside Microsoft 365. A request to “make defect analysis more efficient” cannot be served by Copilot if the defect data lives inside the manufacturing execution system. Filtering at this stage prevents disappointment later.

Stage 1: make permissions visible and cut exposure

This is the content of the earlier section. To restate the practical points, there are three.

First, do not try to organise every permission across the company before you begin. Narrowing to the scope accessible by the pilot departments and clearing that first moves you forward far more realistically.

Second, hand the judgement back to the business. Detection can be automated, but only the people using a share can decide whether it can be switched off. Build the waiting time for those decisions into the schedule.

Third, treat HR, payroll and compensation information as the top priority to check. This one area is worth confirming first regardless of where the pilot scope falls. Note that labelling, being durable structural work, does not need to be complete at this stage. Plan on the basis that it runs in parallel with the pilot.

Stage 2: pilot with twenty to fifty people

The reason twenty to fifty is a sensible pilot size is that it is large enough to yield evaluable data and small enough to pull back from if something goes wrong. At five people, chance effects dominate; at several hundred, an incident becomes unmanageable.

Choosing the participants requires design.

In practice, distributing to one or two whole departments while making sure the management layer and multilingual users are among them gives the best balance of information. Given that Teikoku Databank’s survey reports section managers and team leaders as the group struggling most, including that layer in the pilot to see the reality for yourself is worth doing.

What you collect during the pilot period is not just usage logs. Ask participants to record what they asked, whether the answer met the expectation, and if it did not, what was missing. That record becomes the enablement material for the rollout.

Stage 3: design the measurement

If you start thinking about measurement after the pilot has begun, you are already too late. Without measuring the pre-adoption state, you have nothing to compare against. That is exactly why the work inventory in stage 0 includes a “how the benefit will be measured” field.

The thinking in the last row matters for internal communication. When saved time is absorbed by other work, personnel cost does not fall. In that case, recasting the story as “how much more can the same team process?” is the more accurate framing.

Stage 4: rollout and enablement

Enablement is where the rollout stage most often hides cost. At an overseas site in particular, you need enablement material in the local language and a help channel that can answer questions in the local language. Distributing Japanese-language material and calling it done will not embed anything.

On content, usage examples tied to actual work are far more effective than instructions on which button to press. Just three concrete examples along the lines of “when you write minutes for this meeting, ask it like this” lower the barrier to getting started. The records gathered during the pilot convert directly into that teaching material.

One more thing: include working with verification built in in the enablement. Given that Teikoku Databank’s survey found accuracy of information to be the top concern at 50.4%, spelling out rules such as “never use output as-is” and “always check figures against the source document” is what sustains trust.

Stage 5: never stop reallocating

Copilot licences that are handed out and then forgotten keep consuming budget while going unused. Check usage each quarter and move licences from people who are not using them to people who will — and build that rhythm into the design from the outset.

Making that work requires the following preparation.

Announcing that this mechanism exists ahead of time reduces friction when licences are reclaimed. Once the rule “if you do not use it, it goes to someone else” is common knowledge, it also has the effect of encouraging use in the first place.

Why not to distribute company-wide all at once

When an instruction arrives from the Japanese head office to “put it in across the company,” there is value in proposing a staged approach rather than simply executing. There are three reasons.

First, licences sit idle. Give one to shop-floor staff who do not open Microsoft 365 in a normal day and you generate cost and nothing else. Produce the real number of candidate users and propose narrowing the scope.

Second, permission remediation cannot keep up. A simultaneous company-wide rollout implies that sharing settings across the whole company are already in order. Roll out without that being true and information governance problems occur widely and all at once.

Third, you cannot walk it back when something goes wrong. Staged, you can halt the next wave the moment something unexpected occurs. With a single mass distribution, there is no room for that judgement.

When you take this to head office, framing it as a proposal about sequence rather than opposition works far better. “Taking company-wide rollout as the goal, we will first run a three-month pilot with 20 to 50 people, working on permission remediation and measurement in parallel” lets head office’s intent and local operational reality coexist.

Frequently asked questions

How much does Microsoft Copilot implementation cost?

On Microsoft’s official pricing page, the Microsoft 365 Copilot Business add-on is listed at ¥3,148 per user per month (annual commitment equivalent), or ¥3,778 on monthly billing. From 1 July to 30 September 2026, a first-year-only promotional price of ¥2,698 (annual commitment equivalent) is being offered. For the combined plans, Microsoft 365 Business Standard + Copilot Business is ¥3,523 and Business Premium + Copilot Business is ¥4,797 (both annual commitment equivalent, per user per month). For large enterprises, a figure of ¥4,497 per user per month has been reported, but that is a secondary source, so confirm it in a formal quotation.

That is only the add-on licence cost, however. The real total has to be estimated across five layers: (1) add-on licences, (2) the base licence uplift (Business Standard or above is required, so Basic users need to move), (3) the permission audit and data preparation, (4) rollout and enablement, and (5) operations, meaning usage monitoring and reallocation. Of these, layer 3 demands the most effort and is the part you cannot hand off wholesale to an outside party. Build a budget on licence cost alone and you will find yourself short at a later stage.

Will deploying Copilot cause a data leak?

Copilot does not break permissions. It will not read out information a user has no rights to. So provided permissions are being maintained as intended, Copilot is not designed to create a new path to information. The starting point is understanding that existing paths become visible; the paths themselves do not multiply.

The problem is that in most organisations the range that is technically accessible is wider than the range that should be accessible for business purposes. That caused no actual harm in the past because nobody ever found their way there. Copilot takes a single plain-language question, searches across everything within permissions, and summarises. As the cost of searching drops to almost nothing, the looseness in existing sharing settings surfaces exactly as it is.

Concretely, the typical cases are folders with broken inheritance, links shared with “everyone in the organisation,” and shared sites created by people who have since left and that nobody now manages. In addition, if you apply sensitivity labels only to sites (containers), those labels are not inherited by the items inside, so the individual files remain unlabelled and stay in reference scope. Before deployment, run the audit in the sequence of visibility, cutting exposure, labelling, then rollout. In practice, that means detecting the current state with SharePoint Advanced Management permission reports and using Restricted Content Discovery to remove overshared sites from Copilot’s reference scope.

Should we choose ChatGPT or Microsoft Copilot?

We would suggest revisiting the framing of choosing one over the other. As noted in the body, research indicates that a meaningful share of companies already run multiple platforms side by side, so an either/or premise is drifting away from reality.

As a decision axis, dividing by where the information you want to work with lives, into three categories, makes it easier to organise. For work that completes inside Microsoft 365 — searching and summarising meetings, email and internal material — Copilot. For non-Microsoft data or high-freedom research and planning, ChatGPT Enterprise and similar. For answers grounded in your own work instructions, drawings and quality records, your own RAG.

Note that ChatGPT Enterprise has been reported at USD 45–75 per user per month on an annual agreement with a 150-seat minimum. That minimum seat count can be a constraint if you are considering a contract at a single overseas site. At a site with fewer employees, a standalone contract may not be viable, so check this alongside the design of the contracting entity.

Can we get the same quality in Thai or English as in Japanese?

It is safer not to assume the same level. The practical quality of generative AI differs by language, and this is not a defect of any particular product but something structural, arising from differences in training data and in the accumulated stock of business documents.

As set out in the body, we recommend a design that divides purposes by language. For Thai, rather than assigning independent substitution for a whole task from the start, entering through the narrower role of assisting with translation and organising key points is more likely to lead to real usage. Distribute while expectations are set high and local staff will rate it poorly, which makes the subsequent rollout harder.

There is a second factor: the language of the internal documents being referenced. At a site where most internal material is written in Japanese, a question asked in Thai still draws on Japanese source material, so the answer comes through translation. That can also work in your favour, though, by letting Thai staff read and interpret Japanese technical documentation that previously never reached them. Building that direction into the design, rather than only lowering expectations, is how you extract value specific to a multilingual environment.

How many people is it realistic to start with?

We would suggest twenty to fifty as a guide. At that size you can gather enough data to evaluate, and you can still pull back if something goes wrong. Around five people, individual variation dominates and evaluation becomes meaningless; start at several hundred and an unexpected situation becomes unmanageable.

Do not select recipients at random. Take one or two whole departments, and deliberately mix in the management layer and people who work in a language other than the head-office language. The finding in Teikoku Databank’s March 2026 survey that section managers and team leaders are the group struggling most gives you a practical handle when deciding who participates.

On what to collect, as noted in the body, records of actual interactions are worth more than usage logs. Building the rollout-stage teaching material from those records is the fastest route.

Will it help work on the shop floor (the production line)?

This is an area where expectations should be kept low. Actual production data inside the production management system, equipment operating data, handwritten forms, verbal exchanges on the floor — all of these sit outside the Microsoft 365 tenant or were never recorded at all. Without material to reference, no answer can be produced.

Likewise, tacit knowledge such as a veteran’s judgement criteria does not exist as a document, so no AI, however capable, can reference it. Tackling this area requires the prior step of drawing knowledge out and giving it form.

The realistic options for reaching the shop floor are not Copilot but building a RAG over your own proprietary data, or systems on the manufacturing execution and IoT side. Put the other way, Copilot suits document work in administrative, engineering and management functions. Whether you state that boundary at the kick-off briefing makes an enormous difference to how the shop floor receives the whole thing.

What changed for organisations with 2,000 or more seats?

From 15 April 2026, for organisations with 2,000 or more Microsoft 365 licence seats, Copilot features in Word, Excel, PowerPoint and OneNote are reported to have become unavailable on seats without a Copilot add-on assigned. This rests on a secondary source, so please confirm how it applies to your organisation against primary information.

The practical implication is that plans premised on partial adoption may need revisiting. Japanese-affiliated companies frequently share a tenant between head office and overseas sites, so a site that is small on its own may be part of a group total that crosses the threshold. Check early with whichever department owns the licensing agreement whether your organisation falls into this category.

Should the permission audit be finished company-wide before rollout?

Make complete company-wide remediation a precondition for rollout and the project effectively stops. In practice, a workable design is to start the pilot once visibility and cutting exposure are complete — that is, once overshared sites have been removed from Copilot’s reference scope — and to run durable work such as labelling in parallel.

Cutting exposure, however, must not be skipped. It is a move you can execute in a short period and it is the single most effective countermeasure. Also, regardless of where the pilot scope falls, the storage locations and access rights for HR, payroll and compensation information are worth confirming first. At overseas sites it is not unusual for that information to sit in shared areas.

What should we do if head office decides on a company-wide rollout?

We suggest responding with a proposal about sequence rather than with opposition. Accept company-wide rollout as the goal, and place a small pilot and permission remediation in front of it. Structured that way, you protect local operational reality without contradicting head office’s intent.

What you attach to that proposal should be facts, not opinion. The actual number of people who open Microsoft 365 on a normal day, where the primary working data lives (SharePoint, or a file server), the ratio of languages used in the work, the effort required for the permission audit — present these as numbers and head office can revise the plan. A reaction of “this does not suit us” on its own changes nothing, and the entire operational burden that follows lands locally.

After deployment, how do we judge whether it is working?

You cannot judge unless you measured the pre-adoption state. At the objective-articulation stage, list three to five target tasks, and for each, fix the current time required and how the benefit will be measured.

Things worth measuring include the time taken by a specific task, usage frequency, users’ own perception, the rework rate on output (was it usable as-is or edited), and the volume processed by the same headcount. One caution: when saved time is absorbed by other work, personnel cost in cash-flow terms does not move. Present it as a headcount-reduction story and the premise will be challenged and the case will collapse, so framing it as a change in throughput stands up better to internal scrutiny.

Note also the reported observation that only one user in four has actually reduced their working time (secondary source). Rather than reading that pessimistically, it is more useful to break it down into factors — poor fit with the work, where the data lives, not knowing how to use it, no occasion to use it — and check which of them applies to you.

Summary

The place a Microsoft Copilot implementation stumbles is not model performance. Copilot never breaks permissions, but it drives the cost of reaching anything a person can technically access down to almost nothing. Loose sharing settings caused no harm in the past because nobody found their way there, and the fact that this premise now changes is the essence of what happens at deployment.

The body of the project, therefore, is not “buying licences” but “auditing permissions.” Folders with broken inheritance, “everyone in the organisation” links, shared sites created by people who have left, labels applied only at container level — make these visible and cut the exposure before you roll out, and keep to that order. Skip the order and go company-wide and you will have paid money to make information broadly visible.

Estimate cost across five layers: (1) add-on licences, (2) the base licence uplift, (3) the permission audit and data preparation, (4) rollout and enablement, and (5) operations, meaning usage monitoring and reallocation. The add-on price on the official pricing page is ¥3,148 per user per month (annual commitment equivalent), but that is only layer 1. Layer 3 takes the most effort and is the part you cannot hand off wholesale.

Separating the work types also has to happen first. Summarising meetings, reading through long documents, searching past material, extracting tasks from minutes — work where the information already sits inside Microsoft 365 — is where it delivers. Data inside core systems, judgements based on drawings and quality records, and tacit shop-floor knowledge are out of reach. For the latter, a different mechanism such as your own RAG is required.

Design the relationship with ChatGPT and others as a division by purpose rather than an either/or. Work contained within Microsoft 365 goes to Copilot; cross-cutting and non-Microsoft assets go to ChatGPT Enterprise and similar; proprietary assets go to your own RAG. Those three categories are the decision axis, and running multiple platforms together is already unremarkable.

At overseas sites such as those in Thailand, three issues are specific to the situation: the contracting entity (head office centrally, or the local entity) and how cost is recharged; the difference in practical quality across languages and how expectations are set; and the reality of shared drives built on “everyone, for now.” The storage location of HR and payroll information in particular should be the first thing you confirm. Returning facts from the site to head office — candidate headcount, where the data lives, language ratios, required effort — rather than opinion is what prevents wasted spend and later operational burden.

For sequence, we recommend articulating the objective, making permissions visible, running a pilot with 20 to 50 people, designing the measurement, rolling out, and reallocating. The three reasons to avoid a simultaneous company-wide distribution are that licences sit idle, that permission remediation cannot keep up, and that you cannot walk it back when something goes wrong.

It does not matter whether you have just been told by head office that Copilot is going in across the group, whether you want to build the case upward from your own site, or whether nothing at all has been decided yet. If you can describe the situation in terms such as “our shared folders have been open to everyone for ten years,” “the primary data is on a file server and has not moved to SharePoint,” or “head office’s assumptions and our reality do not match,” we can work through it together — sizing the scope of the permission audit, or designing the pilot. A conversation before any decision is made is perfectly welcome, so please get in touch through our contact form.

References

• Microsoft, “Microsoft 365 Copilot pricing” (Japanese-language page)
• Microsoft Tech Community, “Mitigate oversharing to govern Microsoft 365 Copilot and agents”
• Microsoft Learn, “Get ready for Copilot with SharePoint Advanced Management”
• Microsoft, “Microsoft 365 Copilot vs ChatGPT Enterprise”
• PwC Japan Group, “Survey on the state of generative AI, Spring 2026”
• Teikoku Databank, “Corporate survey on the state of generative AI use (March 2026)”
• Bangkok Post, “AI adoption helps Thai firms become digitally mature”
• The Nation Thailand (BOI investment applications, H1 2026)