How to Scale AI Success Across Your Organization: Sharing Departmental Knowledge and Replicating What Works

Only the results get shared, not the context

What you commonly see in internal sharing is that only the result is conveyed: that AI cut the time spent taking minutes, or that enquiry handling got faster.

Results matter, of course. But what a colleague in another department really wants to know is not the figure itself.

What they are after is concrete detail of the following sort:

• Which task AI was applied to
• What the underlying problem was
• What was fed in as input
• What sort of prompt was used
• Where the work was left to AI and where a person took over to check
• Under what conditions it might be reproduced
• And, conversely, under what conditions it fell flat

On results alone, no other department can copy the work. Only once the context, the steps and the judgement criteria are shared does case-study sharing actually mean anything.

In my experience, the more a company struggles to spread AI use, the more carefully it shares outcomes and the more weakly it shares process. The results slides are immaculate; the grubby, hands-on detail that practitioners actually want is missing.

Which input data did not work. How far the AI’s output could reasonably be trusted. How many revisions it took from the first prompt. That trial and error is exactly the knowledge worth keeping inside the organisation.

It ends as one person’s clever knack

AI use tends, at first, to begin as an individual’s own ingenuity.

• Phrasing the request this way got me a good output
• Feeding in this document first improved the accuracy
• For minutes, asking in this format makes them easy to use

Discoveries like these, made on the ground, are tremendously valuable. But left sitting in someone’s head or buried in a personal chat history, they never become an organisational asset.

When that person changes role or gets pulled onto other work, the hard-won knack stops being reused. To spread AI use across the whole company, you need to lift individual ingenuity onto a proper internal knowledge-sharing system.

The important thing here is not to disparage individual ingenuity. Quite the opposite: AI use starts with the cleverness of whoever first rolled up their sleeves. In my own work across product development and sales support, the first improvement almost always begins with one person saying they had a bit of a go at it.

The point is simply not to leave that ingenuity bottled up inside one person. What lies beyond that is what AI use looks like as an organisation.

Each department’s conditions differ, so it rarely transfers as-is

Another reason success stories are hard to spread is that working conditions differ from one department to the next.

A meeting-note summarisation prompt that worked well in sales will not necessarily suit HR’s interview records. Nor can the FAQ-organising method finance used for enquiries simply be lifted across into marketing’s content production.

In short, what matters in spreading an AI success story is not copying the same thing.

What matters is extracting the structure of the success story and getting it into a state you can redesign to fit your own department’s work.

For that, it must be organised not as a mere anecdote of triumph, but as reproducible knowledge.

I think of spreading AI use as something close to writing a recipe. Show someone a photograph of the finished dish and they still cannot make it. They need the ingredients, the quantities, the method, the heat, and the points where it tends to go wrong. An AI success story is no different.

What the trouble actually was

The first thing to set out is the problem that existed before AI came into it.

For instance, you might write:

• Taking minutes was eating up time
• The quality of enquiry responses varied from person to person
• Drafting the first version of a proposal had become one person’s job
• Turning internal training into materials was a fiddly chore

The key here is not to start your explanation from 「we used AI」. The star of an AI case is not the AI; it is the business problem.

Which task carried which inefficiency or quality variation? Pin that problem down clearly and colleagues in other departments will more readily notice that their own work suffers from something similar.

When I interview people on the ground, I never open with 「which AI did you use?」. I begin instead by asking what was a nuisance beforehand, who was struggling, and which task kept getting pushed to the bottom of the pile. The AI conversation can wait until afterwards.

Which task AI was used for

Next, make the target task clear.

Saying merely 「we used AI for enquiries」 is far too broad. More concretely, it breaks down like this:

• Classifying the content of enquiries
• Drafting reply candidates from past FAQs
• Adjusting the tone of the reply
• Deciding when to escalate to the relevant team
• Analysing monthly enquiry trends

Even within the same enquiry-handling work, there are several points where AI can be applied. Making clear which task AI was used for helps other departments map it onto their own workflow.

Said baldly, 「using AI for enquiries」 sounds like a sweeping change. In reality it breaks down into small units of work: sorting enquiries into five categories, drafting a first-pass reply from past FAQs, tidying up the wording. Getting down to that granularity is the first step towards spreading the practice.

What was fed in

The results of AI use turn heavily on the information you feed in. Use the same prompt but change the documents or background context, and the quality of the output changes with it.

So, when sharing a case, always record input information of this kind:

• Meeting notes
• Audio transcripts
• Internal manuals
• FAQs
• Past proposals
• Customer interview notes
• Training videos
• Operating rules
• Internal regulations

Whatever tool is involved, it pays to note whether the material was typed straight into an AI chat, dropped into a summarisation feature as a file, or referenced from internal knowledge or training data. That makes the work far easier to reproduce.

Where you use a tool such as Kanata, which lets you manage the prompts and reference materials you reach for repeatedly on a per-project basis, keeping your minutes template, your enquiry-reply rules, your past proposals and your internal FAQs in order saves you re-entering everything from scratch each time.

To my mind, when it comes to improving an AI’s accuracy, good input data matters every bit as much as a good prompt. However artfully you write the instruction, if the underlying information is thin, the output tends towards generalities.

Which prompt was used

For making AI use reproducible, the prompt is a vital piece of knowledge. A prompt is simply the instruction you give the AI.

That said, sharing the prompt alone is not enough. With the same prompt, if the background context, the input data and the way the output is checked are not all in place, the same result is unlikely to follow.

For that reason, do not store a prompt on its own; share it together with the following:

• The situation it was used in
• The information that was entered
• The output format expected
• The output actually obtained
• Where a person made corrections
• Phrasing to be wary of
• What to change when another department uses it

Even when saving to a prompt-management feature or a knowledge tool, do not simply park the instruction text; leave a note of which task it is for and which materials it goes with, and it will be far easier to use later.

A prompt is not merely a piece of writing. It is a compressed way of thinking about a task. That is exactly why the context of its use needs preserving too.

Which outcome measures were watched

In an AI success story, make the outcome measures as clear as you can.

Measures might include, for example:

• Time on task
• Volume processed
• Time to first reply
• Number of reworks
• Number of review rounds
• How heavy the workload felt to the person doing it
• Number of internal enquiries
• Volume of training content produced
• User-survey ratings

When you give a number, pair it with the period, the volume covered and the comparison conditions.

So rather than 「minute-taking got faster」, write: 「across the twelve sales standups from January to March 2026, the average time to produce minutes fell from 45 minutes to 15 minutes per meeting」.

Where no number is available, a qualitative change will do.

Shifts in behaviour such as 「no one needs assigning to write up the minutes after a meeting any more」, 「new joiners spend less time hunting through past cases」 or 「other departments have started asking questions at the study sessions」 are themselves meaningful results.

In the early stages of AI use I make a point of watching both quantitative measures and qualitative change, because early change tends to show up in conversation and behaviour before it shows up in the figures.

Where it went wrong

When spreading a success story, the failure information turns out to be surprisingly important.

Share only the parts that went well and another department may walk straight into the same pitfall.

Information such as the following, for instance:

• The input data was out of date, so the answers did not match reality
• The prompt was too abstract, so the output came out as generalities
• There was unease about handling confidential information, so use was kept narrow
• The AI’s output was used as-is and had to be corrected afterwards
• There was a lot of department-specific jargon, so a glossary was needed up front

These failure points do not diminish the value of AI use. If anything, they are vital knowledge for making the work reproducible.

To build genuine AI best practice, you need to keep not just the methods that worked, but the conditions under which they did not.

Case name

First, make the case name specific.

An example to avoid is 「the sales department’s AI case」. That tells you nothing about what it was used for.

Better to write something like 「using AI summarisation to pull next actions out of meeting notes」. It conveys which task it served and what it improved.

As far as possible, build the target task and the direction of the result into the name.

When naming a case I recommend a name that shows the change in the work rather than the department, because the moment a reader sees 「a sales story」 they may decide it has nothing to do with them.

Write 「extracting next actions from a record of a conversation」 rather than 「summarising meeting notes」 and people in customer success, HR and engineering can more readily map it onto their own work.

The department involved and the people involved

Next, set out the department and the people involved.

Note whose case it was, who reviewed it and which departments had a hand in it.

If, say, not only the salesperson but sales planning, a manager and the CRM administrator were involved, record that web of relationships too.

AI use may look like a solo task, but in practice it often touches several people. Naming them gives other departments a reference point when they draw up their own rollout plan.

It is especially important to be clear about the approver and the reviewer. If it is vague who checked the AI’s output, then once the practice spreads, both quality and accountability become murky.

The problem before adoption

Write up the pre-adoption problem in the language of the people on the ground as far as you can.

Not merely 「it was inefficient」, but, as a workplace grievance: 「it took two working days on average to transcribe notes into the CRM after a meeting, which held up preparation for the next proposal」.

Where you can, include something the team actually said.

Right after a meeting I remember it all, but by the next day the finer nuances have slipped away.

A line like that helps a reader in another department picture the situation.

When I build an AI case, I make a point of catching a single remark from the floor. Numbers carry conviction, but words draw the reader in. Even internal knowledge is read by human beings, and a voice from the ground gives a case some depth.

The AI features used

State which AI features were used.

You might organise it like this, for example:

Noting which features were used, and in what order, makes the work easier for other departments to put into practice.

Feed a meeting recording into AI summarisation, break the resulting summary down into department-specific actions with AI chat, then save the settled prompt to the shared library. Once a flow like that is visible, it is no longer a mere tool tour but a reproducible business process.

Input data and prompts

Record what was handed to the AI and what instructions were given.

That said, where customer information, personal data or confidential material is involved, always mask it. In business use of AI it is important to be clear about the scope of what is entered, the checking of outputs and where accountability lies. Authoritative guidance is useful here on putting the right governance and risk management in place for safe, trustworthy AI use. OECD AI Principles

For case-sharing, rather than pasting in the actual prompt verbatim, it is better to tidy it into a reusable, generic version.

You are an assistant supporting a sales manager.
Using the meeting notes below, organise the next set of actions.

# Output format
1. Meeting summary
2. The customer's problem
3. What we need to prepare before next time
4. Questions to confirm with the customer
5. A 120-character summary for the CRM

# Notes
- Do not guess at unclear information; write to be confirmed
- Keep what the customer said separate from our own interpretation

Left in this form, other departments can adapt it to fit their own work.

Where you use a tool such as Kanata that lets you store prompts in a form the team can reuse, naming them along the lines of meeting-note summary_v1 or customer standup summary_v2 makes it clear which prompt is the latest.

What changed after adoption

Set out the change after adoption in terms of both numbers and behaviour.

Numbers alone can fail to convey how things felt on the ground. Impressions alone, on the other hand, make it hard for leadership or other departments to judge the effect.

So combine the two, like this:

• How the time on task changed
• How the volume processed changed
• How rework changed
• How the team’s behaviour changed
• How the conversations among those involved changed

Rather than just minute-taking time was cut, writing that the 15 minutes after a meeting could now be spent confirming the next actions conveys what it meant for the work.

When I look at a number I always go as far as asking what it made possible. Less the ten minutes saved in itself than whether, in those ten minutes, the manager could now talk to their team, replies to customers got faster, or the time went into preparing the next proposal. Write the change through to that point and the value of the case comes across.

Points to watch on reuse

When spreading a practice, the caveats matter.

Carry a success story straight into another department and differences in the starting conditions can make it fall flat.

If you apply sales’s meeting-note summary to HR’s interview records, for instance, the differences run as follows:

• The sensitivity of the information handled
• The standing of the speaker
• The rules for retaining records
• The need for identity checks and consent
• Who is allowed to see the output

Build these caveats into the case-study format and you get not a mere copy but a safe, realistic spread of the practice.

With AI use, 「it is handy, so let us spread it」 is not enough on its own. The handier the thing, the wider the impact when it is used wrongly. Before spreading anything, I always check what might be risky about using this case in another department.

Departments it might spread to next

Finally, record the departments or tasks it might spread to next.

Sales’s meeting-note summary, say, might also apply to customer success standups, HR interview records, or engineering’s specification notes.

Noting these likely next homes helps a success story flow into the next rollout plan.

Spreading an AI case is not something to leave to chance. Simply noting 「where to try this next」 at the end of a case nudges the internal conversation towards the next action.

The presenter talks process, not just results

Ask the presenter to talk not only about results but about process.

Something like this flow, for example:

1. What the trouble was before adoption
2. What they tried first
3. What did not work
4. How they changed the prompt and the input data
5. How they settled the rule for human checking
6. Why the current way of working stuck
7. What to watch for if another department copies it

Told in this order, listeners find it easier to map onto their own work.

Especially important is what did not work. By sharing the trial and error on the way to success, another department can sidestep the same mistakes.

At first I tried pasting the AI’s output straight into the minutes. But the speaker names came out wrong a few times, so now I have the AI organise only the decisions and to-dos, and a person checks it at the end.

Talk like that is not glamorous. But it is what helps a practice spread. What people on the ground really want to know is precisely this sort of practical landing point.

Listeners ask 「how would my department use this?」

At a sharing event, the important thing is not to let people merely listen and leave.

It works well to slot in a small, department-by-department exercise after the presentation.

Prepare questions of this sort, for instance:

• Which of our tasks is similar
• Is there a situation where we could use the same prompt
• What additional internal materials would we need
• Whose sign-off would be needed if we rolled it out
• What task could we try on a small scale within a month

With these questions, case-study sharing becomes not mere information exchange but the entrance to a rollout plan.

On a project I supported, asking 「what would you try tomorrow?」 at the close of a sharing event changed how participants took notes. They stop being listeners and become the next practitioners.

Always turn the session into knowledge

Even when a good remark comes out at a study session, it means nothing if it vanishes with the moment.

Always put the content of a sharing event into a form you can revisit later.

Tidy the recording or notes from the study session with AI summarisation, for example, and store it in a format like this:

• A summary of the case presented
• Questions raised by participants
• Ideas for applying it in other departments
• Points to watch on rollout
• Actions before next time

Beyond that, save the settled prompts and case-study formats to the internal shared library or knowledge tool.

This turns the study session from a one-off event into a growing store of internal knowledge-sharing.

An internal event becomes an asset only after it is held. It becomes an asset once it is recorded, organised, searchable and reused. Whether or not you can turn this into a system makes a real difference to how well AI use beds in.

Set up a sharing channel in Slack or Teams

First, set up a channel dedicated to AI use in Slack, Teams or the like.

It is important to make the channel name easy to grasp.

Names such as the following, for instance:

• #ai-use-sharing
• #generative-ai-knowledge
• #ai-case-sharing
• #kanata-community

In this channel, it is important not to treat only flawless success stories as fair game. On the contrary, welcome small posts of this sort:

• A prompt that proved handy today
• An AI output that did not work
• Something to ask another department
• A caveat worth sharing
• A prompt registered in the shared library
• A topic you would like covered at a study session

Lowering the bar to posting helps knowledge from the ground accumulate.

Say only post flawless cases and almost everyone falls silent. Say instead that even a slightly handy way of using it is welcome, and the sharing begins. In an AI community, lowering this psychological bar matters.

Provide a posting template

To keep a community lively, a posting template helps.

Without a template, people are unsure what to write and posting tends to stall.

Provide a template like this, for instance:

[Task it was used for]
e.g. Writing up the sales standup minutes

[The trouble]
e.g. Writing up the minutes after a meeting took over 30 minutes every time

[AI feature used]
e.g. AI summarisation

[What was entered]
e.g. Meeting notes, transcript of the recording

[Prompt used]
e.g. Organise this into decisions, to-dos and open points, kept separate

[What was good]
e.g. Could put the to-do owners and deadlines into a table

[Caveats]
e.g. Some speaker names were wrong, so a person checked them

As short but structured posts like this accumulate, they become easier to search later.

I recommend deliberately keeping such a template short. Too long, and people tire before they even post. Rough is fine at first; the DX lead can tidy it into the case-study format afterwards as needed.

The administrator picks up posts and turns them into cases

The small touches posted to a community will simply drift past if left alone.

So the DX lead or a cross-functional leader picks up the posts at regular intervals.

Once a month, say, organise them like this:

• The prompts most used this month
• The posts that drew the most response
• Cases that might suit other departments
• Failure examples worth flagging
• Topics for the next study session

Through this tidying, community posts turn into proper internal knowledge.

An AI community is not merely a place for chatter. It is the entrance through which small touches of ground-level wisdom are raised into organisational AI best practice.

The important thing here is not to leave the community to its own devices. Without someone to pick up posts, someone to organise them and someone to carry them into the next study session, the channel soon falls quiet. You need not only to make the space, but to tend it.

Choosing candidate destinations

First, pick a department that looks a good fit for the success story.

The lenses for selection are these:

• Is there a similar workflow
• Is the input data in good order
• Do they feel the problem on the ground
• Is the manager cooperative
• Is the result easy to measure
• Is the information-handling risk not too high

If sales succeeded with meeting-note summaries, say, customer success is a natural next destination, since both record conversations with customers and carry them into a next action.

Rolling out to work that handles sensitive information, such as HR interviews or legal consultations, on the other hand, needs careful design.

When choosing candidates, look not only at similar work but at whether it is work you can safely try. With AI use, the risk shifts considerably with the kind of information involved.

Run a pilot

Once the destination is set, run a pilot first.

A month to three months is realistic for the period, and limit the participants at first to between a handful and a dozen or so.

In a pilot, settle the following in advance:

• The target task
• The users
• The AI features to be used
• The prompts to be used
• The information permitted as input
• Who checks the output
• The outcome measures
• The timing of the review

What matters at this stage is not to rush success.

The purpose of a pilot is not to produce a flawless result. It is to find where you need to adapt things to your own department’s conditions.

In my experience, the value of a first pilot lies not only in whether it can be used but in seeing where it gets stuck. The input data is not in order. The prompt is too long. The reviewer is busy. The output format does not match the forms on the ground. Spotting these snags is what leads to the next improvement.

Decide the outcome measures

In a rollout plan, decide the outcome measures in advance.

Without measures, you end up judging on users’ impressions alone. Impressions matter too, of course, but they are not enough as the basis for a company-wide decision.

You might set measures such as these, for instance:

• Time per item
• Monthly volume processed
• Number of corrections at manager review
• First-reply rate for enquiries
• User retention
• Number of reuse cases at study sessions
• Number of registrations to the prompt library
• Number of enquiries from other departments

Where quantifying is hard, combine in a qualitative assessment.

Reviews such as 「in which part of the work was it easy to use」, 「which outputs were unusable」 and 「where does a person need to check」, for instance.

Outcome measures are not there to back the team into a corner. They are there so you do not lose sight of the direction of improvement. With AI use, chasing the number of times it was used means nothing on its own. Unless you look at how the work changed, it will not bed in.

Update the case-study format after rollout

Fold the lessons from spreading the practice back into the original case-study format.

Suppose that rolling out sales’s case to customer success surfaced differences like these:

• Standup notes are longer than meeting notes
• You need to separate the customer’s requests from your own follow-ups
• Referencing the history of ongoing issues improves accuracy
• An output format geared to transcription into the monthly report was needed

Adding these lessons makes the case a stronger piece of knowledge.

Best practice is not finished from the outset. It is something that gets updated with every rollout.

I think AI knowledge should be treated not as a static manual but as a growing asset. Rather than fixing whatever you first wrote as the right answer, polish it each time it is used. On that footing, running internal knowledge becomes realistic.

The headline number runs on ahead of everything else

Outcome figures such as 「the work was halved」 or 「we handled more cases」 tend to draw attention internally.

But when the number runs on alone, it breeds misunderstanding on the ground.

Even if one department cut its minute-taking time, that may have been because the meeting format, the input data quality, the review setup and the prompt were all in place. Another department will not necessarily see the same result.

When sharing a number, always pair it with the period, the scope, the conditions and the assumptions. Not overselling is what makes an internal AI rollout trustworthy.

The more I am talking up the results of AI use, the more I think one should be a touch restrained. Flashy numbers grab attention, but a number with its assumptions stripped out loses the trust of the people on the ground.

The case is too abstract for the ground to use

「We improved efficiency with AI」, 「knowledge-sharing progressed」, 「we refined our prompts」.

Phrasing like this gives the ground nothing to act on.

What people on the ground want is more concrete steps:

• On which screen
• What was entered
• What output was obtained
• Who checked it
• Which task it fed into

Once it is this clear, they can finally translate it into their own work.

An abstract case may stir sympathy but rarely leads to action. If the aim is internal rollout, take it down to the level of execution steps.

Imposing the successful department’s way of working

What you want to avoid in spreading a practice is foisting the successful department’s method on others wholesale.

A method that worked in one department will not necessarily function unchanged in another.

The workflow, the information-handling rules, the relationship with customers and the outcome measures all differ from department to department.

A success story is, at most, a reference. The receiving department needs room to edit it to fit their own work.

So at a case-sharing session, rather than 「do it exactly like this」, the question that matters is 「if you translate this structure for your department, where would you need to change it?」.

I am careful even with the word 「spread」. Do not copy sideways; translate sideways. Translating to fit each department’s language, work and constraints is, in practice, indispensable.

Failing to share the assumptions around security and information handling

In AI use, the assumptions around information handling are hugely important.

Where customer information, personal data, contract information or undisclosed information is involved, you need to be clear about how far it may be entered into the AI.

When sharing a success story too, convey not just the convenience but always the points to watch on information handling.

Content such as the following, for instance:

• Customer names were masked
• Personal data was not entered
• It was handled in an internal-only environment
• A person always checked the output
• Highly confidential material was kept out of scope

The handier the case, the more readily another department may copy it carelessly. That is exactly why the caveats must be shared alongside it.

Where you use a tool such as Kanata that lets you organise members and the data used on a per-project basis, it is important to split projects according to the range of information people may see. Where sales, HR and finance handle different kinds of information, do not force them into the same place; design around who may view what.

An internal AI rollout only lasts once convenience and safety go hand in hand. Either one alone will not take root. The NIST AI Risk Management Framework likewise sets out a way of thinking about identifying the risks particular to generative AI and managing them in line with an organisation’s aims and priorities. NIST AI Risk Management Framework

The knowledge stops being updated

Build a case-study format or a prompt library and, left un-updated, it soon goes stale.

The way AI is used shifts with changes in the work, changes in internal rules and users’ growing fluency. Old prompts and old information left lingering only cause confusion.

So always assign internal knowledge an owner and an update cycle.

An arrangement like this, for instance:

• Once a month, review the prompts most used
• Once a quarter, revisit the case-study format
• Consolidate or delete knowledge that is not being used
• When the information-handling rules change, update the related cases
• Add new success stories at study sessions

Knowledge-sharing is not finished once it is made. It becomes a learning asset for the organisation by being kept up to date.

I find this close to tending a garden. Scattering seeds alone makes no good garden. Trim the grown branches, swap out the old, find the new shoots. It is because you take that trouble that knowledge stays alive.

Use AI chat to organise the case-interview questions

First, use AI chat to build the questions for interviewing people about a success story.

Before a DX lead interviews someone on the ground, for instance, they might ask the following:

You are a DX lead organising the company's AI use cases.
Draw up a set of questions for interviewing a colleague on the ground.


# Objective
To organise an AI success story into a case study other departments can reproduce


# Angles to cover
- The problem before adoption
- The target task
- The AI features used
- The input data
- The prompt
- The results
- The failure points
- Caveats for rolling out to other departments


# Output format
Produce it as an interview sheet, with questions and answer fields.

Standardising the interview questions this way reduces the variation in information from one case to the next.

I place real weight on standardising the interview sheet. When different people ask about different things, you cannot compare the cases afterwards. Building the shape of the questions up front helps the quality hold up as internal knowledge.

Use AI summarisation to turn study sessions into case studies

After a study session or sharing event, tidy its content with AI summarisation.

From the recording, the notes and the chat log, pull it together in an output format like this:

• The case shared
• The presenter’s sense of the problem
• The AI features used
• Questions from participants
• Scope for application in other departments
• Concerns about rollout
• Actions before next time

Rather than letting the session’s content simply wash past, shaping it into a case study makes it easier for those who were not there to understand later.

When using AI summarisation, rather than simply asking it to summarise, specify that it organise the content into 「case overview」, 「reproduction steps」, 「participant questions」 and 「next actions」, and it becomes far more usable as internal knowledge.

Save cases and prompts to a shared library

Save settled cases and prompts to a shared library.

When you do, give them searchable names.

Naming such as the following, for instance:

• Sales_meeting-note-summary_success_2026-05
• Finance_enquiry-first-reply_prompt_v1
• HR_training-video-summary_case-study_2026-05
• Company-wide_minutes-template_standard_v2

Putting the department, the use, the type and the date or version into the name makes them easier to find later.

When registering to the library too, noting in the description which task it is for, who checked it and the points to watch on use makes it easier to reuse.

With Kanata, you can organise prompts and training data on a per-project basis. Splitting projects by department, by task and by use makes it easier for those involved to reach the information they need. At firms already using another knowledge tool, one option is to settle a division of labour with the existing tool and organise only the prompts and reference data used for AI on the Kanata side.

When saving a prompt or a case, I tell people not to make light of how it is named. A vague name means it stops being used. Knowledge that cannot be found might as well not exist.

Use AI chat to make past cases easy to find

As cases multiply, finding them becomes the next challenge.

「I have a feeling there was a similar case before」, 「I want to see the prompt sales were using」, 「I would like to know how HR did their training-video summaries」.

In situations like these, AI chat can serve as the entrance to internal knowledge search.

If you have built up cases, prompts and session summaries in the shared library, a colleague can hunt for what they need conversationally.

They might ask, for example:

Of the AI use cases used in sales, name three that other departments could readily reuse. For each, set out the target task, the prompt used and the points to watch on rollout.

Once you can search knowledge by conversation rather than by keyword, the bar to internal knowledge-sharing drops.

Internal knowledge is not enough merely accumulated. What matters is that the person who needs it can pull it out at the moment they need it.

Turn success stories into teaching material

A case you want to spread can be turned into teaching material as well as covered at a study session.

Where there are prompts you want used company-wide, or points to watch on information handling, it is effective to keep them as a video or learning material.

Material such as the following, for instance:

• The basic steps for AI minute-taking
• How to use the meeting-note summary prompt
• The internal knowledge-registration rules
• Checkpoints for reviewing AI output
• Criteria for what must not be entered
• Department-by-department usage patterns drawn from success stories

Using a mechanism such as Kanata’s e-learning feature, where you register videos and training content and learners study as needed, lets you carry a success story beyond a single presentation and share it continually with new joiners and people who change roles.

I think it is hard to finish AI education in a single training session. People become able to use something in practice only once there is an environment where they can re-learn it when the need arises. Turning success stories into teaching material is an effective means to that end.

Decide who is responsible for registering cases

First, decide who is responsible for registering cases.

Leave it solely to people on the ground and, swamped by their day-to-day work, updates tend to stall. Leave it solely to the DX team, on the other hand, and the real ingenuity from the ground can fall out.

What I recommend is joint stewardship between the people on the ground and the DX lead.

Splitting the roles this way keeps both the feel of the ground and the reusability.

When I support a team, I too separate the parts that keep the ground’s words intact from the parts organised for easier spread. Trim the ground’s words too far and the case turns tidy but loses its force; leave it un-organised and it is hard to reuse. The balance of both matters.

Decide the criteria for publishing a case

Next, decide the criteria for which cases get shared internally.

Publish all of the trial and error company-wide and there is simply too much. Publish only flawless success stories and there is little to learn.

Possible lenses for a publishing standard include:

• Whether other departments likely face a similar problem
• Whether the steps can be explained
• Whether there are no information-handling issues
• Whether the result or the lesson is clear
• Whether the prompts and input data are reusable
• Whether the failure points can be shared too

Setting publishing criteria helps you keep the quality of the knowledge up.

Make the bar too strict, though, and no one posts. A realistic approach is to welcome anything with even a small lesson at first, with the DX lead supporting the move to a formal case.

Take stock monthly

Take stock of internal knowledge at regular intervals.

Once a month, in 30 to 60 minutes, check the following, for instance:

• Newly registered cases
• Cases viewed often
• Cases reused by other departments
• Prompts in need of updating
• Knowledge better deleted or consolidated
• Topics for the next study session

Taking stock keeps the knowledge from going stale.

It also lets you see which cases are actually being used, which makes it easier to feed into the next rollout plan.

With Kanata, since you can organise prompts and training data per project, it is easier to manage knowledge by department, by task and by use. At stocktaking, check for unused prompts, duplicated materials and stale cases, and update as needed.

I call the monthly stocktake tidying the knowledge. In a cluttered room, you cannot find what you need. Internal knowledge is no different.

Tie success stories to recognition and praise

To spread AI use, you also need a motive for the ground to want to share cases.

For the individual, sharing a case is extra effort. In a state where sharing earns no recognition, posting and registering will not last.

So touches like these are worth considering:

• Feature good cases at the monthly study session
• Praise cases that spread to other departments
• Make the number of prompt-library registrations visible
• Count it as a cross-functional contribution to improvement in appraisals
• Pick up a representative case at the board meeting

It need not be a grand award.

Simply seeing that this case was used by another department too lifts the ground’s appetite to share.

To my mind, embedding AI use means valuing not only those who used it but those who shared it. Someone who left their method in a form other departments could use contributes more to the whole organisation than someone who only made their own work more efficient.