---
name: systematization-content-checklists-software
description: "Turn a job your team knows into steps others can use."
category: Strategy & Measurement
stage: —
definitive_article: /9-triangles-framework-scalable-home-service-businesses/
status: complete
---

# Systematization (Content → Checklists → Software)

Turn a job your team knows into steps others can use. This guide helps you test the steps before you build tools around them. Start with one real task and the person who can show it well.

**The path:** Real work → Canonical guide → Tested checklist → Bounded software

**Start when:** A repeated task needs a reliable documented method and evidence for any automation decision.

## Inputs

- A real repeated task, current source guide if one exists and an experienced operator.
- Actual input/output examples, errors and review criteria; permission to record or inspect the work.
- The maintained task/document sources, a reviewer and an authorized scope for any later software change.

## Steps

1. Observe a real execution and capture the goal, inputs, decisions, steps, result and exceptions. Preserve actual work evidence; an imagined clean path misses the problems this process must handle.
2. Use [Document a task](https://local-service-spotlight.github.io/task-library/?task=document-a-task#task-document-a-task) to create or update its single canonical recipe. Separate a task guide from a topic hub, and connect supporting articles through the [SEO Tree, the map of related pages](https://blitzmetrics.com/seo-tree/).
3. Extract a checklist with explicit inputs, ordered actions, pass criteria and next handoff. Package it as a skill, meaning reusable task instructions, using the current [skill publishing standard](https://blitzmetrics.com/skill-publishing-standard/).
4. Test the checklist on actual authorized work with different operators. The prior local recipe calls for at least three runs including someone other than the expert; record that agreed gate and the actual distinct executions. A question can reveal missing context, an exception or an execution mistake; diagnose it before editing.
5. Compare the runs for stable mechanical steps and judgment points. Propose automation only where inputs, failure handling, access, authority and observable outputs are defined. Software use is not automatically a scheduled job.
6. Implement only the approved bounded tool or worker. Test success, missing-input and failure paths without hidden live effects, and retain the actual result. Keep a manual handoff where judgment or access remains human.
7. Compare time, rework and output quality against the baseline after use. A new script, skill or plugin is an artifact; do not call the method improved until its evidence supports that claim.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the result against its agreed requirements; see the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] One canonical recipe and usable checklist trace to real work.
- [ ] The agreed multi-operator test gate has distinct run evidence or remains unfinished.
- [ ] Any automated portion has authorized scope, failure handling and observed tests; unresolved judgment is explicit.

## Example(s)

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

A fictional team records three real invoice-check attempts in its practice setting. Two operators miss a field that the guide never named, so the guide changes. A fourth attempt has not happened. The new checklist is saved, but the team does not claim its revised process has passed or that a new script can send invoices.

## Handoff and Content Factory context

[Publish the reviewed skill and task page](https://local-service-spotlight.github.io/task-library/?task=publish-skill-and-task-page#task-publish-skill-and-task-page) handles the approved document; the implementation owner receives any separate software proposal.

This work supports the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/) across its relevant stages. It uses the actual inputs and next owner above; a strategy or measurement guide does not manufacture transcripts, clips or other unrelated stage outputs.

## Start with an agent

Give the AI worker this recipe, the real Inputs, the desired result and the actions already authorized. Ask for the saved output, source evidence, passed and failed checks, and the next owner. A skill is a set of instructions. Loading it does not prove access, install a scheduled job or complete the work. Use the [current installation guide](https://localservicespotlight.com/install/) only if reusable setup is needed; a ZIP contains instructions and is not an access grant.

Use the actual supported app and verified source access. A model name is not a promise of browser control, memory or unattended work. For recurring work, inspect the real job’s trigger, owner, timezone and observed firing; this recipe creates no schedule. Before any media playback, mute the player and set volume to zero. A silent review does not prove sound was heard.

## Record the real execution

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

Reuse the same execution ID for internal reviews, meta writing, revisions and retries. A blocked run stays open with its dependency and owner, without an invented finish time. Keep historical public examples as dated evidence; article counts alone are not verified execution frequency. Use supported findings to propose and verify a recipe improvement.


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

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

- **Phase:** —
- **Importance:** 3/5 `●●●○○` — frequency 3, revenue 3, 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/9-triangles-framework-scalable-home-service-businesses/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=systematization-content-checklists-software#task-systematization-content-checklists-software)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](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 `complete`. It is preserved, not promoted by this rewrite. That label alone does not verify document readiness, account access, an actual execution or a client outcome.

A relevant real execution, source evidence, independent reviewer and accepted handoff remain to be recorded. The fictional example teaches the method and does not fill a real-run evidence gap. The opening and full method need a named semantic reviewer; the task-specific path is source guidance, with visible desktop/mobile presentation still to check.