A financial analyst resigns after a decade. She was the person who knew why the invoice run failed on the third attempt, which report to pull when the auditor asked an unusual question, and what a cryptic batch error meant. None of it was written down, and a replacement had not been hired.
That situation is common enough to treat as a planning assumption rather than a surprise. What has changed is that a practical answer now exists.
Every organization in this position already owns the raw material. Years of closed support cases and help-desk tickets sit in a system somebody pays maintenance on. Executives generally assume AI can read them, and it can. Reading was never the constraint.
The constraint is that most of that archive is not support history. In one recent curation, roughly 1,700 support cases reduced to about 500 in scope, and from those only a few hundred carried a documented fix: a symptom, a cause and a resolution a person could follow. On the help-desk side, 600-plus closed tickets yielded 64 usable records. The remainder were access requests, provisioning, audit chores and routine administration. Real work, but not knowledge.
The discipline to discard is the difference between a knowledge base that answers questions and one that returns plausible noise. A little over 400 curated records survived, drawn from the cases, the 64 tickets and vendor articles. Each was sanitized of names, account identifiers, amounts and contact detail, then tagged so that nothing customer-specific reaches an end user.
A usable record answers a question somebody will ask again. In practice that means it carries three things, and a record missing any of them belongs in the discard pile regardless of how much work it represented at the time:
The volume that fails this test is the interesting part. Access requests, provisioning, audit chores and password resets consume most of a help desk and produce almost no reusable knowledge. Recognizing that early prevents the most common mistake, which is judging the project by how much of the archive was ingested rather than by how much was worth ingesting.
Curation involves more than selection. Each record carries a trust level that separates vendor-verified content from human-reviewed material and from content nobody has confirmed. That single field is what lets an assistant hedge honestly: answer a verified question directly and flag the rest as a pattern to confirm before acting. Uniform confidence is how these systems lose their users in week two.
The field also does regulatory work. When risk or compliance asks what the system asserts as fact and what it merely suggests, the trust level answers at the record level rather than at the system level.
Records are joined by shared identifiers, including screen codes, process codes and error codes. That is what turns two unrelated document piles into one retrievable set, so that an error and the procedure resolving it find each other.
The strongest quality control available is using the knowledge base as the working tool before anyone else sees it. For several live close cycles, the team supporting the client answered questions in Claude Cowork against the curated records rather than from memory. Every question the knowledge base could not answer became a record. Every answer that was almost right became an edit. That cycle produced most of the specific content in the finished set.
The method matters more than the tool. Running real work through the base before release converts an untested content set into one that has already answered the questions people ask, and it produces the gap list for free.
One expectation worth setting early: the model does not learn between sessions. Improvement is an operational process. Someone updates the knowledge, the rules and the assistant design on a schedule, and someone owns that schedule. A system described as getting smarter on its own is being described inaccurately.
The knowledge base was deployed inside the client’s own Microsoft tenant and reached through Microsoft Copilot licenses users already held. No new application, no new login, no data leaving the tenant. The incoming analyst asks a question in the tool she already uses and gets an answer grounded in her predecessor’s decade, with the trust level attached.
Deployment inside an existing tenant removes the two failure modes that kill internal assistants. There is no adoption curve, because there is no new application to learn, and no third-party data governance review, because the content never leaves an approved environment.
The assistant retrieves and drafts. An analyst still owns anything customer-specific and every accounting judgment. The knowledge base did not replace the analyst who left. It changed what her successor needed to know on day one.
A knowledge base without a named owner degrades within two quarters. The operating model that holds up is modest: one owner accountable for the content set, a defined intake path so that new resolutions enter the base as a matter of routine rather than goodwill, and a review cadence tied to something that already happens, usually the close calendar.
Two rules keep the content set honest over time. New records meet the same standard as the original curation, and records that repeatedly fail to answer the question they were retrieved for get rewritten or removed. Growth is not the objective. A base of 400 records that answer beats 4,000 that approximate.
The measurable return shows up in ramp time. A new hire who can retrieve a decade of resolved issues on day one reaches independent working faster than one rebuilding that knowledge from scratch, and every subsequent hire inherits the same advantage. Measure it against the organization’s own history for the role rather than an external benchmark.
Three other indicators are worth tracking from go-live, because together they show whether the base is being used and whether it deserves to be: the share of questions answered without escalation, the number of retrievals that produced no usable answer, which is the gap list, and the proportion of the content set carrying a verified trust level, which should rise over time.
Organizations have tried to solve this before. Documentation drives, shadowing programs and offboarding checklists all target the same dependency, and they share a poor record for one reason: the captured knowledge sat somewhere nobody looked. Retrieval is what changed. A curated record that surfaces inside the tool someone is already working in gets used. A binder does not.
The economics changed with it. The raw material is already paid for, sitting in a system under maintenance, and the delivery runs through licenses the organization has already bought. What is left is curation and configuration, which makes this the rare succession control that costs a defined project rather than an indefinite program.
Key person dependency has sat on risk registers for as long as there have been risk registers, routinely recorded and rarely mitigated. It has become a solvable problem, and the solution turns out to be mostly a matter of deciding what to keep.
When you choose Opportune, you gain access to seasoned professionals who not only listen to your needs, but who will work hand in hand with you to achieve established goals. With a sense of urgency and a can-do mindset, we focus on taking the steps necessary to create a higher impact and achieve maximum results for your organization.