---
name: identify-thank-you-triggers
description: "Use a real good deed to plan a clear thank-you. Start when someone has helped you or your team."
category: Thank You Machine
stage: Produce
definitive_article: /thank-you-machine
status: complete
---

# Find a Real Reason to Say Thanks

People help your business in small ways each day. This guide helps you spot one good deed and say why it mattered. Start with a real event. Finish with a clear note that someone can use to record thanks.

**The path:** Real good deed → check the facts → one clear note.

**Use this when:** a real referral, useful lesson, kind act or completed piece of work gives you a specific reason to thank someone.

## Inputs

- The source of the good deed: a project note, message, call notes or your own dated recollection.
- The person’s name, their role in this event and the intended private or public use.
- The existing gratitude log, if there is one; no account access is needed merely to write the note.

## First-run prompt

> Use this source to find one specific reason for thanks. Name what the person did and why it helped. Check for a duplicate. Save a short recording note and flag facts or sharing rights we still need.

## Steps

1. Read the actual source. Write the event date and one sentence about what happened; distinguish an observed deed from a guess about someone’s motive.
2. Confirm the right person and spelling. If two people share the name, use the known project or profile to resolve identity rather than choosing the first search result.
3. State what they did, the practical effect and your genuine reason for thanks. Keep numbers and claims within the source; an introduction is not a sale unless that sale is proven.
4. Check the log for the same person, deed and date. Reuse an existing record when this is the same event; a new deed can deserve new thanks.
5. Choose the audience. Keep personal matters and private client details out of a public script. Note whether the event can be shared and whether the person wants to be named; a private thank-you can be the right outcome.
6. Write three short talking points: their name, the specific deed and why it mattered. Remove any pitch, request for a favor or implied endorsement of your business.
7. Save the source reference and talking points with a next owner. If a key fact is missing, mark exactly which fact needs checking and prepare the rest.

## Definition of done (QA checklist)

- [ ] One real, sourced deed is named without added results.
- [ ] Identity and duplicate check are recorded.
- [ ] Private details and intended sharing scope are clear.
- [ ] The note contains a specific reason for thanks and no request for a return favor.
- [ ] The next owner can find the source and the recording note.

## Example(s)

**Fictional teaching example — no client result or completed run.** A project note says Jordan covered the front desk for ten minutes while the owner helped a customer. The note thanks Jordan for that time. It does not claim that Jordan brought in new sales.

## Handoff and Content Factory context

Pass the checked note to [Record a One-Minute Thank-You Video](https://local-service-spotlight.github.io/task-library/?task=record-one-minute-thank-you-video#task-record-one-minute-thank-you-video). If the note should stay private, keep that scope with the handoff.

This fits the [Content Factory](https://blitzmetrics.com/content-factory/): Produce a true story, Process it into useful files, Post only in the agreed places, and Promote a suitable post when its test has a budget. Each stage passes its checked files and next owner forward.

## When this runs

Run after a specific good deed or during an already agreed review of recent work. A recurring review is optional and needs an actual configured schedule.

## First-run setup and continuity

Use the files and accounts this task actually needs. A skill is a written recipe; the [AI worker](https://blitzmetrics.com/build-agents/) needs suitable tools and access to follow it. This file does not install an app, connect an account or start a timer. Follow the [setup guide](https://localservicespotlight.com/install/) for the chosen app. Carry out work already covered by the user's instructions; ask only for an exact missing item or a new action outside that scope.

Save the source, current state, checked result and next owner in the project files. Check that record before retrying or handing work to another person. Configure a repeat only when requested, with its time zone, actual runtime and first successful firing. An app or model name does not prove persistence, memory or a schedule.

Keep every agent media check muted with volume zero before playback. If that cannot be verified, use captions, metadata or still frames and record the limit. Do not play sound through the user's speakers without their current request.

## Write up the real run

For each real attempt, [write the meta article](https://blitzmetrics.com/meta-article-prompt/): its task and source revision, starting point, work done, evidence, measured result, gaps and next handoff. Save one execution ID across retries and edits. Partial, blocked and failed work also gets a record. A saved draft satisfies writing while any public release is pending. Writing does not grant publication authority.

A teaching example is not a real execution. Do not count it, a repeated check or a revision as another run. The [recipe and meta-article guide](https://localservicespotlight.com/meta-articles/) explains the link between reusable instructions and actual work.


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

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

- **Phase:** Produce
- **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:** Raw files in Content Library `01-Raw/` plus a tracker row (question, date, speaker). Next skill never needs the chat — it needs the files.

## 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

- Exact task: [Find a Real Reason to Say Thanks](https://local-service-spotlight.github.io/task-library/?task=identify-thank-you-triggers#task-identify-thank-you-triggers)
- [One-minute video guide](https://blitzmetrics.com/one-minute-video-guide/) — how to record one clear point.
- [Content Factory](https://blitzmetrics.com/content-factory/) — how the source becomes checked posts.
- [Dollar-a-Day guide](https://blitzmetrics.com/dollar-a-day/) — the paid test method; current platform controls still need checking.

## Review and evidence still needed

The original contributor state is preserved. Instruction review, article certification, account access and completed work are separate states.

- Source mapping needs repair: on September 6, 2026, the recorded /thank-you-machine/ hub redirected to /face-socks/, a gift-ordering guide. That live gift recipe does not certify this video workflow. Keep the task ID and contributor state; use the relevant video and process guides below until the owner resolves the canonical video hub.
- Add a dated, real execution record with the actual checked output. The example below does not fill that gap.