---
name: add-knowledge-capture-to-existing-workflows
description: Your team learns things that can save the next person time.
category: Knowledge System Maintenance
stage: —
definitive_article: /knowledge-system-maintenance
status: gap
---

# Add Knowledge Capture to existing workflows

Your team learns things that can save the next person time. This guide puts a short lesson note into the work you already do. Start with the call, report, and audit steps your team uses.

**The path:** Current work → Capture point → Checked note → Adoption review

**Start when:** A checked lesson form exists, but a call, report or audit workflow lacks a reliable capture point.

## Inputs

- Current client-call, campaign-review and audit checklists, with their owners and revisions.
- [The checked four-field note form](https://local-service-spotlight.github.io/task-library/?task=provide-knowledge-capture-note-template#task-provide-knowledge-capture-note-template) and its shared location.
- Authority for the proposed workflow changes and a reviewer for the rollout.

## Steps

1. Read each actual workflow and mark where a reusable finding appears: call wrap-up, after report analysis, and audit closeout. Do not add a capture step to a process that is outside the agreed scope.
2. At each point draft: “If this work reveals a reusable lesson, save a note within 24 hours.” Link the form there and state that the clock starts when the lesson is learned. A routine run with no new lesson need not invent one.
3. Name who writes the note and who routes it. Keep source, insight, destination and priority as the four fields; date the source and retain the actual save time in the record.
4. Prepare exact before/after checklist changes. Use [Draft a process-change proposal](https://local-service-spotlight.github.io/task-library/?task=create-sop-amendment-proposal-500-words#task-create-sop-amendment-proposal-500-words) and the existing review authority to approve and version the edits. Preserve any already working capture step.
5. After the approved rollout, inspect one real run of each workflow. Check whether a lesson arose, whether the capture step was used, and whether any resulting note reached the shared location within 24 hours.
6. Agree a 2–4 week adoption review with an owner and dates. Inspect missed captures and false alarms. Zero notes can mean no reusable finding, no work, missing access or a broken capture point; investigate before changing the method.

## Definition of done (QA checklist)

[Quality assurance (QA)](https://localservicespotlight.com/article-guidelines/) means checking the work against the agreed result.

- [ ] All three in-scope workflows have a specific capture point, linked form and owner.
- [ ] Approved source versions are saved; each trial has actual findings and timestamps, or an explicit untested state.
- [ ] Adoption review is assigned; any calendar entry is checked separately from a completed review.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

In a made-up shop, the report review finds a wrong date range. Its new closeout step yields a note with the export as source. A call produces no new lesson, so no note is invented. The audit trial has not run. Result: two capture points tried, one still untested; this is not three successful captures.

## Handoff and Content Factory context

This work supports the [Content Factory, our four stages of using real content](https://blitzmetrics.com/content-factory/): Produce → Process → Post → Promote. Use the specific inputs and next task below to place the work; a maintenance task does not manufacture transcripts, clips or other stage outputs it does not call for.

[Capture a lesson within 24 hours](https://local-service-spotlight.github.io/task-library/?task=generate-knowledge-capture-note-within-24-hours#task-generate-knowledge-capture-note-within-24-hours) receives real lessons; [The distribution owner](https://local-service-spotlight.github.io/task-library/?task=create-knowledge-capture-note-template-and-distribute#task-create-knowledge-capture-note-template-and-distribute) tracks adoption and the next review.

## Run with an agent

Give the AI worker this recipe, the real Inputs above, the intended result and the actions already authorized. Ask it to return the saved output, checks, evidence and remaining owner. Check its work against this guide; loading a skill does not prove access, installation of a job, or successful execution. Keep media muted with volume at zero if playback is needed.

For recurring work, keep the actual trigger, owner and runtime in the job record. Scheduling and observed firings are separate. Do not create a schedule merely because this guide mentions a review interval.

## Record the real execution

Open the run record when the work starts. Keep the exact starting recipe revision, one execution ID, source evidence and actual state. Write a [meta article, the record of one run](https://blitzmetrics.com/meta-article-prompt/) with decisions, results, checks, failures and next owner. Link it to this task and register it through the [Task Library](https://local-service-spotlight.github.io/task-library/) execution process. Writing is part of the work; public release follows existing authority.

Reuse the same execution ID for revisions, QA, meta writing and retries within that run. A blocked run stays open with its dependency and next owner; do not invent a finish time. Use supported findings to propose and verify a better recipe. A historical public-example count without distinct run IDs remains dated article volume, not verified execution frequency.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** —
- **Importance:** 2/5 `●●○○○` — frequency 2, revenue 1, gating 2 (supporting)
- **Suggested previous station:** —
- **Suggested next station:** —
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Save this task’s actual output, source, date and checks where the receiving owner can read them. Follow the Inputs and Handoff sections for its next step.

## Model routing (same factory, any engine)

- **This task's lane:** `any` — Any capable chat model (Claude, ChatGPT, Grok, Gemini). SOP following, drafts, checklists.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- [Maintained source guide](https://blitzmetrics.com/knowledge-system-maintenance/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=add-knowledge-capture-to-existing-workflows#task-add-knowledge-capture-to-existing-workflows)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [current article guide](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records work together](https://localservicespotlight.com/meta-articles/)

## Review and evidence still needed

The inherited contributor status is `gap`. It is preserved, not promoted by this rewrite. That label alone does not verify document readiness, a client outcome, access or an executed task.

A real execution still needs its own source, reviewer, saved result and handoff evidence. The fictional example teaches the method; a real example with relevant proof is still needed where required. The task-specific flow above is source guidance; its visible presentation and the full document need a named reviewer and desktop/mobile checks.