---
name: personal-efficiency-do-delegate-delete
description: "Clear the next step for work that lands in your inbox."
category: Strategy & Measurement
stage: —
definitive_article: /9-triangles-framework-scalable-home-service-businesses/
status: complete
---

# Personal Efficiency (Do, Delegate, Delete)

Clear the next step for work that lands in your inbox. This guide helps you do it, hand it to the right person or set it aside with a clear reason. Start with one inbox and your current goals.

**The path:** Incoming item → Do / Delegate / Delete → Evidence → Follow-up

**Start when:** An agreed inbox or task list needs triage into clear owned actions.

## Inputs

- The exact inbox or task list in scope, with the operator’s current priorities and authority.
- Existing assignments, threads, deadlines and follow-up records.
- A suitable receiving owner where delegation is possible; relevant task guides.

## Steps

1. Define the source’s three choices. Do means own the action; Delegate means give a bounded task to a capable owner; Delete means decline, archive or remove only as appropriate and authorized. It does not require irreversible deletion.
2. Read each exact item and its history before acting. Check whether it already has an owner, sent reply or working follow-up so triage does not duplicate a live task.
3. Do a short in-scope action when the inputs and authority are present. For a longer action, record its next step, owner and due date in the existing task system. A calendar-bound task can be owned without being done now.
4. Delegate with the goal, sources, expected output, deadline and relevant guide. Preserve the originating thread and confirm the receiving owner’s acceptance where required. Do not send messages or grant access without the current authority.
5. Archive or decline irrelevant items under the source’s retention and communication rules. Keep records that support an active matter; do not unsubscribe, delete or refuse a commitment merely to reach zero.
6. Reconcile every in-scope item to a real disposition. Waiting on someone remains waiting with a next check; unread or inaccessible items remain unresolved. Inbox zero is a useful working view, not a reason to conceal open work.
7. Save the triage result and verified actions. Use any existing follow-up cadence; create a new schedule only when separately authorized. Compare useful completed outcomes and rework, not just the fraction delegated.

## 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/).

- [ ] Every reviewed item has a supported disposition and an exact next action if open.
- [ ] No duplicate handoff, unsupported send, irreversible removal or lost active evidence occurred.
- [ ] Waiting and blocked work remain tracked; completion reflects actual action.

## Example(s)

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

A fictional owner has a simple file request, a tax document and a repair quote awaiting a vendor. The allowed file reply is sent and checked. The tax document is routed to its existing owner, and the quote stays waiting with its next check. Archiving the inbox view does not mark the quote delivered.

## Handoff and Content Factory context

[Manage the accepted handoffs](https://local-service-spotlight.github.io/task-library/?task=management-communicate-iterate-delegate#task-management-communicate-iterate-delegate) receives delegated work and unresolved dependencies.

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=personal-efficiency-do-delegate-delete#task-personal-efficiency-do-delegate-delete)
- [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.