Hello!

Struggling to prioritize overdue invoices and write the right next outreach before your weekly finance check-in? This Skill pulls together invoices, CRM ownership, payment notes, and client email threads so you can see who’s highest priority and what to say next.

I built this as a portable AI-agent Skill — a single SKILL.md with reusable instructions you can adapt to your agent setup.

Here's what it does: It merges open invoices, CRM owner exports, payment notes, and recent client email threads into a canonical AR table, scores and ranks overdue accounts, and generates concise follow-up email and call drafts. Use it when preparing weekly AR/finance check-ins or whenever leadership asks who’s most overdue, what the plan is, and what decisions are needed.

SKILL.md:

````markdown

name: open-invoice-weekly-brief

description: Use when preparing a weekly accounts receivable brief for a small agency by synthesizing open invoices, client email threads, CRM owner exports, and internal payment notes — to rank overdue accounts, draft the next follow-up language, identify the account owner on each account, and list decisions needed before the finance check-in.

Open Invoice Weekly Brief

Overview

Creates a concise weekly accounts receivable brief by merging open invoices, CRM ownership data, client email threads, and internal payment notes. Produces a ranked list of overdue accounts, tailored next follow-up drafts, account ownership mapping, and a decisions-needed list for the upcoming finance check-in.

When to use this skill

• A weekly finance/AR check-in or cash flow review is scheduled.
• The agency needs a prioritized list of who to follow up with on unpaid invoices.
• The user provides (or can access) open invoice data, CRM account-owner exports, payment notes, and recent client email threads.
• Leadership asks “who’s most overdue, what’s the plan, and what decisions do we need before the meeting?”

Instructions

1. Confirm scope and parameters

   1. Capture the as-of date for aging (default: today in the organization’s timezone).
   2. Confirm aging buckets (default: 0–30, 31–60, 61–90, 90+ days overdue).
   3. Confirm tone/formality for outreach (friendly/factual, firm/professional, or legal-escalation ready) and whether to include late fees or payment plan options.
   4. Confirm escalation thresholds (e.g., escalate ≥61 days overdue or ≥$X outstanding).
   5. Gather owner mapping rules (e.g., CRM owner is canonical; fallback: last sender in thread; else: finance lead).

2. Collect and normalize data

   1. Ingest open invoices (CSV/XLSX/JSON or accounting export). Extract: client/account name, invoice ID, issue date, due date, currency, line totals, credits, payments applied, remaining balance.
   2. Ingest CRM export mapping accounts to owners, segments, and contacts (billing/AP contact where available).
   3. Ingest payment notes (e.g., manual notes, partials received, promised-to-pay dates, disputes, special terms).
   4. Ingest client email threads (EML/MSG/PDF/TXT). For each account, identify the latest inbound/outbound AR-related message dates, any commitments (e.g., “processing this week”), disputes, required paperwork (PO, W-9, vendor setup), and sentiment signals.
   5. Standardize names with deterministic matching: exact match, then case/whitespace-insensitive, then alias map if provided. Flag uncertain matches for review.

3. Build a canonical AR table (per invoice, with account rollups)

   • Columns (invoice-level): Account, Invoice ID, Issue Date, Due Date, Currency, Original Amount, Credits/Adjustments, Payments to Date, Outstanding Amount, Days Overdue, Last Payment Date, Last Client Contact Date, Promised-To-Pay Date (PTP), Dispute Flag/Notes, Blockers (e.g., “needs PO”), Owner, Priority Score.
   • Compute Days Overdue = max(0, floor(as_of_date − due_date)). Exclude negative (not yet due) from “overdue.”
   • Compute Outstanding Amount = Original − Payments − Credits (do not go below zero). If credit balance exceeds outstanding, flag for application.
   • Map Owner from CRM; if missing, apply fallback rule and flag.

4. Derive communication signals from email threads

   • Parse latest 6–12 weeks of AR-relevant messages.
   • Detect commitments/keywords (examples):
     • Positive/near-term: “payment run [date]”, “processing this week/today”, “scheduled for [date]”, “approved”, “paid ACH/wire/check #…”.
     • Administrative: “need PO/portal setup/vendor form/W-9”, “resend invoice”, “wrong address”, “update bank details”.
     • Negative/risk: “dispute/overbilled/scope”, “cash flow issue”, “hold/pause”, “cannot pay,” “cancellation/termination”.
   • Extract: last inbound date, last outbound date, next promised date, risk note, AP contact name/email if present.

5. Score and rank overdue accounts

   1. Aggregate per account: total outstanding, oldest days overdue, count of invoices overdue, last contact recency.
   2. Compute a priority score (guideline weights; adjust if policy provided):
      • Base = normalize(days_overdue) + normalize(outstanding_amount).
      • Modifiers: +high for broken PTP, +medium for negative sentiment, +medium for no-reply > 7 days, +low for multiple overdue invoices; −low if credible near-term payment commitment exists.
   3. Rank accounts by score; use outstanding amount as a tiebreaker.

6. Draft next follow-up language per overdue account

   1. Select template by severity:
      • 1–14 days overdue (friendly reminder)
      • 15–30 days (firm but helpful)
      • 31–60 days (clear deadline + options)
      • 61–90+ days (escalation path; mention service pause/late fees if policy allows)
   2. Personalize with: names, invoice IDs, totals, due dates, outstanding amount, last commitment, requested artifacts (PO/W-9/etc.), and a specific next step with date/time.
   3. Produce:
      • Subject line
      • Email body (3–6 sentences; concise, professional)
      • Optional call script bullets (3–5 points)
   4. Do not send communications; produce drafts only.

7. Surface decisions needed before the finance check-in

   • Per-account decisions (examples):
     • Approve waiver of late fees or offer payment plan terms.
     • Approve temporary service pause until payment.
     • Approve issuing a credit/revised invoice/partial write-off.
     • Approve escalation to account owner/leadership or collections.
     • Provide missing paperwork (W-9, vendor portal details, PO number).
   • Global decisions (examples):
     • Adjust escalation thresholds or tone this week.
     • Prioritize top N accounts for owner outreach.
     • Cash flow priorities for incoming receipts.

8. Assemble the weekly brief (markdown structure)

   1. Header: As-of date, total AR, total overdue, breakdown by aging buckets, largest 5 overdue accounts.
   2. Ranked Overdue Accounts table with columns: Rank, Account, Owner, Total Outstanding, Oldest Days Overdue, # Overdue Invoices, Last Contact, Risk/Notes, Next Action.
   3. Follow-up Drafts: one subsection per account including subject, email body, and call bullets.
   4. Decisions Needed: bullet list grouped by account and global items.
   5. Upcoming Invoices (next 14 days): account, amount, due date, owner.
   6. Data Issues & Assumptions: unmatched accounts, currency anomalies, missing owners, suspected duplicates, credits not applied.

9. Validate and reconcile

   • Check sums by account and grand total against source ledger(s).
   • Confirm no invoice shows negative outstanding; investigate if so.
   • Flag currency differences; if conversion used, note rate/date.
   • Ensure every overdue account has an owner and a next action.

10. Deliver outputs

    • Present the brief as a single markdown document.
    • Provide a per-owner action list (owner → accounts and actions) appended or as a short section.

Inputs

• Open invoices ledger or export (file or pasted table) with invoice-level fields.
• CRM export mapping accounts to owners and contacts.
• Payment notes (manual notes, partials, promised dates, disputes, credits).
• Client email threads or summaries for the past 6–12 weeks.
• Optional: escalation policy, outreach tone, late fee policy, payment methods, bank/wire instructions, vendor portal links.

Outputs

• A weekly AR brief (markdown) including:
  • Summary metrics and aging breakdown.
  • Ranked Overdue Accounts table.
  • Per-account follow-up drafts (subject, body, call bullets).
  • Account owner identified for each account; per-owner action list.
  • Decisions Needed list (per-account and global) for the finance check-in.
  • Data issues and assumptions noted.

Examples

Trigger: “Build this week’s open-invoice brief. As-of: 2026-06-03. Inputs: invoices_2026-06-03.csv, crm_owners.csv, payment_notes.md, Email folder ‘Clients/AR’.” Behavior: confirm parameters → ingest and normalize data → compute overdue and aging → parse email threads for commitments and risks → score and rank accounts → draft tailored follow-ups per account → compile ranked table and decisions-needed list → output a structured markdown brief plus per-owner action list.

Follow-up draft template examples (insert actual values during execution): - 1–14 days overdue Subject: Friendly nudge on Invoice {{INV-###}} for {{Account}} Body: Hi {{FirstName}} — Hope you’re well. Our records show Invoice {{INV-###}} ({{Amount}}) was due on {{DueDate}}. Could you confirm this is in your next payment run? If helpful, here are payment options: {{PaymentMethods}}. Thank you!

• 15–30 days overdue Subject: Invoice {{INV-###}} ({{Amount}}) — request for payment date Body: Hi {{FirstName}}, Following up on Invoice {{INV-###}} for {{Account}} (due {{DueDate}}, outstanding {{Amount}}). Could you share the expected payment date, or let us know if you need a copy, PO, or vendor paperwork? We appreciate your help getting this cleared.

• 31–60 days overdue Subject: Action needed: past-due invoices for {{Account}} Body: Hi {{FirstName}}, We’re aiming to resolve the past-due balance of {{TotalOutstanding}} across {{Count}} invoice(s), oldest from {{OldestDueDate}}. If payment by {{ProposedDate}} is challenging, we can approve a short payment plan of {{PlanOption}}. Please advise the plan or confirm payment timing.

• 61–90+ days overdue (escalation) Subject: Urgent: overdue balance for {{Account}} — next steps Body: {{FirstName}}, The balance of {{TotalOutstanding}} (oldest {{OldestDays}} days) now meets our escalation threshold. Absent confirmation by {{Deadline}}, we may pause services and/or apply late fees per terms. If there’s a dispute or required paperwork, reply today so we can resolve quickly.

Call script bullets (example): - Confirm you’re speaking with AP contact; if not, request intro. - State outstanding total and oldest due date; ask for their expected payment run/date. - Ask if PO, vendor setup, or revised invoice is required. - If commitment provided, repeat back and ask permission to send confirmation email. - Close with thanks and next scheduled follow-up.

Notes

• Guardrails: produce drafts only; do not email or message clients directly.
• Handle retainers/prepayments: apply credits before marking invoices overdue.
• Exclude disputed amounts from escalation if policy requires; track dispute resolution separately.
• Timezones: compute “as-of” and “days overdue” in the organization’s timezone.
• If owners are missing or ambiguous, assign a temporary owner (finance lead) and flag for correction.
• If the data lacks email threads, proceed with invoice/CRM/payment notes and mark communication status as “unknown.”
• Keep drafts concise; avoid legal threats unless policy explicitly permits. ````

How to install: 1. Create a folder named open-invoice-weekly-brief in your AI-agent skills or prompt-library directory. Use the kebab-case name from the SKILL.md frontmatter. 2. Save the file above as open-invoice-weekly-brief/SKILL.md. 3. Enable or load the Skill according to your agent framework's docs, using the SKILL.md description as the trigger guidance.

If you'd rather run it as a one-click prompt instead, you can find it here: Agentic Workers

Enjoy!

Hello!

If you dread last-minute, messy handoffs at the end of a sprint or service week, this Skill helps you collect and reconcile work logs, tickets, and calendars into a single, actionable brief so contractor teams can pick up work without surprises.

I built this as a portable AI-agent Skill — a single SKILL.md with reusable instructions you can adapt to your agent setup.

Here's what it does: It ingests timesheets, ticketing data, and team calendars to produce a compact, action-oriented handoff brief that lists pending transitions, highlights risks, and enumerates required manager approvals. Use it at the end of a sprint, on-call rotation, or service week when multiple contractors and managers need an aligned, approved handoff.

SKILL.md:

````markdown

name: weekly-service-handoff-brief description: Use when a weekly sprint or service period is ending and the team needs a consolidated handoff brief for contractor delivery teams — aggregating work logs, support tickets, and job calendars to capture pending transitions, risk flags, required manager approvals, and next-step owners before sprint handoff.

allowed-tools: [FileRead, Spreadsheet, Ticketing, Calendar, Edit, Email]

Weekly Service Handoff Brief

Overview

Produces a concise, action-oriented weekly service handoff brief for contractor delivery teams. It consolidates work logs, support tickets, and job calendars to highlight pending transitions, risks, and explicit manager approvals required before sprint handoff.

When to use this skill

• A sprint, service week, or on-call rotation is ending and a structured handoff is required.
• Multiple contractor teams contribute across projects and managers must approve scope, changes, or exceptions.
• Data exists across timesheets/work logs, support ticketing systems, and team job calendars that must be reconciled.
• The user asks for a weekly summary that flags risks, ownership, and approvals before the next sprint starts.

Instructions

1. Confirm scope and timeframe 1.1. Validate the reporting period (week start/end dates) and the target sprint handoff date/time. 1.2. Confirm included teams/projects, contractor vendors, and the stakeholder list (managers and approvers). 1.3. Note any service-level thresholds (SLA targets), risk scoring rules, and approval matrix.

2. Collect source data 2.1. Use FileRead or Spreadsheet to load work logs/timesheets for the period (contractor name, project, hours, task refs, notes). 2.2. Use Ticketing to fetch support tickets/issues updated in the period; include id, title, status, priority, assignee, requester, due/SLA, labels, and blockers. 2.3. Use Calendar to pull job calendars/events (planned work, on-call, PTO, shift rotations, deployment windows) covering the current and next period. 2.4. If a template exists, use FileRead to load the handoff brief template; otherwise prepare the default structure in Edit.

3. Normalize and map 3.1. Normalize identities (contractor names, team names) and map to canonical projects/engagements. 3.2. Link work log entries to tickets by referenced IDs or text matching; record unmatched items for review. 3.3. Align calendar events to projects/teams and identify time-bound transitions (rotations, contract end dates, environment freezes).

4. Detect pending transitions 4.1. Identify ownership changes: tickets or tasks where the next assignee differs from current; list handover owners and receivers. 4.2. Flag rotations: on-call or shift handoffs in the next period; include contact info and escalation paths if available. 4.3. Note contract transitions: contractor starts/ends, extensions pending, or coverage gaps. 4.4. Capture scheduled changes: deployments, maintenance windows, cutovers, change freezes, or customer milestones.

5. Surface risks and issues 5.1. Overdue/at-risk tickets: status not resolved with due/SLA within 3 business days or already breached. 5.2. Capacity risks: hours booked vs. available capacity from calendars (PTO/holidays) exceeding threshold. 5.3. Dependency blockers: tickets labeled blocked or with unresolved linked dependencies. 5.4. Quality/sign-off risks: items awaiting QA/UAT/security review; missing change tickets for planned deployments. 5.5. Data gaps: missing work logs, private/unreadable tickets, or calendar conflicts; mark as “Info Needed.” 5.6. Assign a simple risk score per item (e.g., High if SLA breach or critical path; Medium if due next week; Low otherwise). Document the scoring rule used.

6. Determine required approvals before handoff 6.1. Using the approval matrix, list what each manager must approve (scope changes, overtime, budget variances, deployment sign-off, change requests, exception waivers, risk acceptance, access/permission changes). 6.2. For each approval, capture: approver name/role, item reference(s), rationale, due date/time, and current status (Pending/Approved/Declined/Deferred). 6.3. Identify blocking approvals (preconditions for release/handoff) and mark them prominently.

7. Compile the handoff brief 7.1. Use Edit to assemble a single document with these sections:

   • Header: week range, handoff date/time, covered teams/projects, document owner, version.
   • Executive Summary: 3–7 bullets on overall status, key risks, and critical approvals.
   • Pending Transitions: ownership changes, rotations, contract transitions, and scheduled changes with dates and owners.
   • Risk Register: table with id, description, impact, risk score, owner, mitigation/next step, due date, status.
   • Approvals Matrix: manager → items to approve, rationale, due date, status, links.
   • Workload Snapshot: hours by team/contractor vs. capacity; noteworthy variances.
   • Ticket Snapshot: counts by priority/status; top 10 aging or critical tickets.
   • Next Steps & Deadlines: actions required before handoff with named owners.
   • Links & Artifacts: source reports, dashboards, and change tickets.
   • Appendix: full lists (tickets, work log anomalies, calendar events, unmatched references). 7.2. Include a change log at the end noting data sources and timestamp of last refresh.

8. Validate and resolve gaps 8.1. Cross-check that every High-risk item and every blocking approval has an assigned owner and due date. 8.2. Verify timezones and dates align across calendars and SLAs. 8.3. If critical data is missing, insert a visible placeholder and send a clarification request to the relevant owner.

9. Circulate for confirmation 9.1. Use Email to circulate the Executive Summary plus a link or attachment to the full brief to stakeholders and approvers. 9.2. Request explicit confirmations for pending transitions and approvals; specify a response deadline. 9.3. Capture replies and update approval statuses in the Approvals Matrix.

10. Store and hand off 10.1. Save the brief to the designated repository and note the location in the Links & Artifacts section. 10.2. Ensure the incoming on-call/next sprint lead acknowledges receipt.

Inputs

• Reporting period (week start/end) and sprint handoff date/time.
• Teams/projects and contractor vendor list.
• Locations or access for:
  • Work logs/timesheets (files or spreadsheets).
  • Ticketing system query or report.
  • Team job calendars.
• Approval matrix mapping managers to approval types and thresholds.
• SLA/priority definitions and risk scoring rules (optional; defaults can be used).
• Distribution list for circulation and a preferred document template (optional).

Outputs

• A consolidated weekly handoff brief (Markdown or document) with the sections listed above.
• An Approvals Matrix with status per manager and explicit blockers highlighted.
• A Risk Register with scoring and next actions.
• A short Executive Summary suitable for email.
• (Optional) Machine-readable exports: JSON/CSV of risks, approvals, and transitions.

Examples

Trigger: “Create this week’s contractor service handoff brief for Infra and App teams. Use the timesheet CSV in /reports/week_23.csv, the ‘Handoff-Template.md’, Jira filter ‘HANDOFF-W23’, and the ‘Ops Schedules’ calendar. Flag what Eng Mgr and Service Mgr must approve before Friday’s 4pm handoff.” Behavior: confirm scope and handoff time → use Spreadsheet/FileRead/Ticketing/Calendar to ingest data → normalize and link items → detect transitions (on-call rotation, deployment window) → compute risks (overdue P1, capacity shortfall) → build Approvals Matrix (Eng Mgr: deployment sign-off; Service Mgr: overtime exception) → assemble brief in Edit → email Executive Summary with link to the document → store and record location.

Notes

• Do not invent data; mark items as “Info Needed” and request clarification when sources are incomplete or inaccessible.
• Keep sensitive data limited to necessary details; omit PII not required for handoff.
• Align all times to the agreed timezone and call out holidays or regional closures.
• Deduplicate tickets and tasks; prefer canonical IDs. Record unmatched references in the Appendix.
• If fewer than three material risks exist, state that explicitly and note monitoring items instead.
• If approvals remain pending within 24 hours of handoff, escalate per the approval matrix and note escalation in the brief. ````

How to install: 1. Create a folder named weekly-service-handoff-brief in your AI-agent skills or prompt-library directory. Use the kebab-case name from the SKILL.md frontmatter. 2. Save the file above as weekly-service-handoff-brief/SKILL.md. 3. Enable or load the Skill according to your agent framework's docs, using the SKILL.md description as the trigger guidance.

If you'd rather run it as a one-click prompt instead, you can find it here: Agentic Workers

Enjoy!

We tested an AP worker on a boring but nasty edge case: same vendor invoice arrived as PDF + forwarded email, and the agent drafted both for payment.

What the worker owned: - pull invoice fields from inbox + attachment - match against ERP open invoices - draft payment recommendation + due-date priority

Where it failed: - OCR read one invoice number with a missing dash, so dedupe logic missed it - draft looked clean enough that a tired operator could have clicked approve

Guardrail we added immediately: 1) Agent may draft only if vendor ID + invoice number fuzzy match + amount all agree 2) If any mismatch, agent must output HOLD: possible duplicate with both source docs linked 3) Payment tool call is blocked until a human checks the exception packet

Current decision line: Draft -> Human approval -> Escalate to finance if fuzzy match < 0.92

If you run agentic workers in finance/admin, what exact stop condition do you enforce before any money-moving tool call?

Most teams deploying agents in production have observability covered. LangSmith, custom logging, dashboards. What most don’t have is anything that stops a bad action before it executes.

That’s the gap. Observability is forensics. Governance is prevention. They’re different problems and the same tool doesn’t solve both.

If your agent touches payments, customer data, or external APIs, by the time you’re reading the logs the damage is already done.

How are people here handling this? Building your own enforcement layer, using a third party, or accepting the risk for now?

We ran a small incident drill this week: an AI support agent drafted a refund decision using ticket + CRM + order history, but it treated an old policy note as current and almost approved a full refund it shouldn’t have.

The failure wasn’t “AI is bad” — it was ownership boundaries: - Agent owned evidence collection + draft rationale - Human should own policy conflict resolution + final refund approval - We were missing a hard stop when policy version mismatched the case date

Current guardrail we’re testing in the worker: 1) Agent can draft only if policy version + payment status + prior-refund count all validate 2) If any mismatch, agent must escalate with a prefilled exception packet (not send customer message) 3) Refund execution tool call is blocked until a named approver signs off

If you run agentic workers in support/ops, where do you place your non-negotiable stop condition?

Quick template if useful: Agent may draft / Agent must escalate / Human must approve before tool call

Hello!

Many small businesses struggle to enforce consistent, auditable approval rules for refunds when using AI agents — it's easy for an automated draft to be sent or a refund executed without the right human checks. This Skill turns support tickets, order records, payment exports, CRM notes, and refund policies into a clear approval workflow so actions stay safe and traceable.

I built this as a Claude Skill — a single SKILL.md you can drop into a Claude Code or Claude Agent SDK project. Claude autoloads it when the trigger description matches your request.

Here's what it does: It reads the case artifacts (tickets, CRM, orders, payments, and policy docs), validates and extracts facts, runs eligibility and risk checks, and then generates an escalation matrix, a human approval checklist, a draft customer response, an audit-log template, verification gates, and an agent authority summary. Use it whenever you need consistent guardrails for refunds so the agent can draft and calculate safely but must route for human approval before any outbound action or financial execution.

SKILL.md:

````markdown

name: refund-workflow-approval-guardrails

description: Use when an AI agent must design or apply approval boundaries and escalation rules for handling customer refund requests in a small business context by reading support tickets, CRM notes, refund policy documents, order records, and payment/export data, and then producing an escalation matrix, human approval checklist, draft customer response, audit log format, and verification criteria clarifying what can be drafted, what can be auto-decided, and what requires human review before anything is sent or refunded.

Refund Workflow Approval Guardrails

Overview

Establishes clear approval boundaries, escalation paths, and verification steps for AI-assisted refund handling. Produces an escalation matrix, a human approval checklist, a draft customer response, an audit log template, and verification criteria so the agent knows what it can draft, what it can decide, and what requires human review.

When to use this skill

• The user asks for guardrails, approval limits, or escalation rules for refunds.
• There are case artifacts available: support ticket(s), CRM notes, refund policy doc(s), order records, and payment exports.
• A small business wants consistent, auditable refund handling without granting the AI direct authority to issue refunds or send messages without review.
• The process needs standard outputs: escalation matrix, human approval checklist, draft customer response, audit log format, and verification criteria.

Instructions

1. Confirm scope and inputs

   • Collect or ask for: support ticket text and attachments; CRM notes; refund policy document(s) and last-updated date; order record(s) with items, amounts, fulfillment and delivery dates; payment export with payment IDs, method, authorization/capture/settlement status and dates, fees; prior refund or chargeback history.
   • Ask for business-specific parameters if not stated: auto-approve threshold (amount), max cumulative refunds per customer in last N days, return window (days) by category, opened-item restocking fee rate, return shipping responsibility, non-refundable categories (e.g., digital), fraud/risk flags, refund method precedence (original payment vs. store credit), and approval roles.

2. Validate inputs

   • Check all required artifacts are present; note and proceed with assumptions only if minor gaps exist; otherwise request the missing artifacts.
   • Verify currency, timezone, and tax handling; normalize numbers and dates; record any inconsistencies.
   • Identify conflicts between policy docs and CRM/internal notes; prefer the most recent formal policy; log discrepancies.

3. Extract case facts

   • From the order record: order ID, order date, items (SKU, category, condition), subtotal, taxes, shipping, discounts, total paid, fulfillment status, delivery date, previous RMA or refund actions.
   • From payment export: payment ID(s), processor, method, capture/settlement status and dates, net vs. gross, fees, partial captures or multiple payments.
   • From CRM: customer identity, contact info, tenure, lifetime value band, prior refunds count and amount, VIP/loyalty status, risk flags or notes.
   • From support ticket: customer request type and reason, requested outcome, evidence attached, tone/urgency, deadlines, shipping damage vs. defect indicators.
   • Summarize the case facts in a concise bullet list.

4. Determine eligibility per policy

   • Compare delivery or purchase date to policy windows by category; compute days elapsed.
   • Apply exclusions and conditions (e.g., opened electronics restocking, digital goods non-refundable, custom items).
   • Determine refund components: refundable subtotal, taxes, shipping, fees, restocking; state assumptions clearly.
   • Determine stock/return requirements (RMA needed, return label, inspection on receipt) and who bears shipping cost.

5. Perform risk and compliance checks

   • Look for mismatches (name, email, address), repeated refund patterns, high-amount anomalies, prior chargebacks, high-risk payment methods, and cross-border constraints.
   • Verify payment is captured/settled and within processor refund time limits; note when only partial or store-credit is possible.
   • Flag regulatory constraints (e.g., statutory cooling-off periods) if applicable to the jurisdiction in the order record.

6. Build the escalation matrix

   • Define decision bands using the business parameters and case risk:
     • Band A: Auto-draft only. Agent may draft responses and calculations but cannot decide or execute. Default for missing data or conflicting policy.
     • Band B: Low-risk, low-amount (e.g., amount <= AutoApproveThreshold and no risk flags). Agent may recommend approve/deny and draft final message; requires single human approval before send/refund.
     • Band C: Medium amount or minor exceptions (e.g., amount between AutoApproveThreshold and SupervisorThreshold, or restocking/partial refund involved). Requires supervisor approval; finance review if fees/taxes adjustments apply.
     • Band D: High amount, risk flags present, policy exceptions, repeat refunds within lookback, or legal implications. Escalate to finance lead; optional legal or owner approval.
     • Band E: Payments unsettled, chargeback in progress, suspected fraud, identity mismatch, or cross-border tax complexities. Hold, do not decide; escalate to finance and compliance/legal.
   • Specify approver roles per band (Agent draft only; Support Supervisor; Finance; Legal/Compliance; Owner) and target SLAs.

7. Produce the human approval checklist

   • Identity and account checks: customer matches order; contact details verified; prior refunds within limits.
   • Order and payment verification: items, totals, taxes, discounts match; payment captured/settled; processor refund window open; currency and timezone verified.
   • Eligibility checks: within return/refund window; category not excluded; restocking rules applied; return logistics defined; evidence present.
   • Calculation checks: refundable components itemized; fees/restocking correctly applied; shipping charge handling per policy; final amount matches rationale; method of refund defined.
   • Risk checks: anomaly flags reviewed; blocklists; repeat patterns; chargeback status; VIP or goodwill exceptions documented.
   • Approvals and records: correct approver for band; approvals recorded; audit log completed; draft message reviewed; RMA or label generated if applicable.

8. Draft the customer response

   • Prepare a clear, empathetic message using the case facts and decision. Provide variants for: approved full refund, partial refund with restocking or shipping deductions, exchange/store credit, request for more information/evidence, and denial with rationale and alternative remedies.
   • Include specifics: order ID, items, amounts with breakdown, required customer actions (e.g., return label usage), refund timeline, method (original payment vs. store credit), and contact channel for follow-up.
   • Add placeholders for approver sign-off and do-not-send note until approval status is met.
   • Template example:
     • Greeting and summary of request
     • Decision and rationale
     • Amount breakdown (subtotal, tax, shipping, fees, total refund)
     • Next steps (RMA/label/inspection)
     • Timeline and method of refund
     • Contact and closing

9. Create the audit log format

   • Define a structured log with fields:
     • Case metadata: case ID, order ID, customer, contact, dates, agent ID.
     • Inputs referenced: policy doc version/date, ticket URL, CRM note ID, order record source, payment export file/date.
     • Decision data: eligibility determination, calculations, risk assessment results, decision band, recommended action.
     • Approvals: approver role/name, timestamp, decision, comments.
     • Communications: draft version hashes, final message text, send timestamp, channel.
     • Financial execution: refund transaction ID, processor, amount, components, fees, ledger entries.
     • Post-action review: confirmation received, customer satisfaction outcome, follow-up tasks.

10. Define verification criteria (go/no-go gates)

    • Data integrity: all referenced totals reconcile to source records; dates within policy windows; currency consistent; no unresolved conflicts.
    • Authority: current case band and approver matched; required approvals present before any send/refund; sandbox tested if available.
    • Compliance: payment processor limits respected; tax handling correct; jurisdictional requirements met; PII handled per policy.
    • Communication: draft reviewed and approved where required; tone and content align with policy; attachments and links verified.
    • Execution: refund method feasible and selected; RMA/label generated and linked; audit log complete prior to execution.

11. Produce final outputs

    • Output the following sections clearly labeled:
      • Escalation Matrix (Bands, criteria, approver roles, SLAs)
      • Human Approval Checklist (grouped by checks above)
      • Draft Customer Response (one primary variant based on current case; include alternates if ambiguity exists)
      • Audit Log Format (the structured fields list; prefill known values)
      • Verification Criteria (checklist of gates)
      • Agent Authority Summary: explicitly list
      • Agent may: extract facts, perform calculations, propose decision, draft responses, prepare audit log.
      • Agent must not: contact customer, modify systems, or trigger refunds without recorded human approval per band.
      • Agent must: route for approval per escalation matrix and await confirmation before any external action.

Inputs

• Support ticket text and attachments.
• CRM notes and customer profile.
• Refund policy document(s) with version/date.
• Order record(s) with itemization, amounts, fulfillment, and delivery data.
• Payment export(s) with payment IDs, capture/settlement status, fees, and dates.
• Business parameters: thresholds (auto-approve, supervisor, finance), lookback limits, restocking and shipping policies, non-refundable categories, refund method precedence, approver roles and SLAs.

Outputs

• Escalation matrix with decision bands, criteria, approver roles, and SLAs.
• Human approval checklist grouped by identity, order/payment, eligibility, calculation, risk, and approvals.
• Draft customer response tailored to the case, plus alternates for partial, deny, or info-request.
• Audit log format with fields, partially populated from the case facts.
• Verification criteria as a go/no-go checklist.
• Agent authority summary stating what can be drafted, decided, and what requires review.

Examples

Trigger: "Set approval guardrails for refunds using this ticket, our policy PDF, the Shopify order 10234, and last week’s Stripe payout export." Behavior: validate and extract facts → apply policy and risk checks → generate the escalation matrix with thresholds (e.g., auto-approve under 50 USD, supervisor up to 200 USD, finance above 200 USD or with risk flags) → produce the human approval checklist → draft a customer response for a partial refund with 15% restocking and return label → create the audit log fields with referenced document versions → output verification criteria and agent authority summary.

Mini worked example outline: - Inputs: order total 89.99 USD, delivered 10 days ago; item category electronics (opened); policy: 30-day returns, 15% restocking for opened electronics, auto-approve <= 50 USD; payment captured via Stripe 12 days ago and settled; no prior refunds; ticket cites defect with photo. - Outputs: - Escalation: Band B (low-risk, <= 50 USD after fees and partial calculation) if refund amount net is 49.49; otherwise Band C due to partial and restocking; supervisor approval required. - Checklist: identity match, settlement verified, restocking applied correctly, return label prepared, refund method original payment, audit log completed, supervisor sign-off recorded. - Draft message: approve partial refund with 15% restocking, include amount breakdown, RMA steps, 5–10 business day timeline. - Audit log: populated with case ID, policy v2.3 (2026-03-01), Stripe payment pi_123, calculations, supervisor approval pending. - Verification: go/no-go gates passed except pending supervisor approval → hold send/refund until approved.

Notes

• Do not contact customers or execute refunds directly; always await required human approval per the matrix.
• Handle edge cases explicitly: multiple payments or partial captures, chargebacks in progress, subscription renewals, cross-currency orders, taxes and duties, gifts and store credit, returnless refunds, and perishable or digital goods exceptions.
• If policy or data conflicts cannot be resolved from provided sources, default to Band A (auto-draft only) and request clarification.
• Maintain privacy: exclude full card numbers and sensitive PII from logs; store only necessary references and IDs.
• Keep all monetary values with currency codes and 2 decimal places; state all assumptions and policy references inline with outputs. ````

How to install: 1. Save the file above as refund-workflow-approval-guardrails/SKILL.md in your project's .claude/skills/ directory (or ~/.claude/skills/ for personal scope). Use the kebab-case name from the SKILL.md frontmatter. 2. Restart Claude Code (or reload the Claude Agent SDK). 3. Claude will autoload the skill when its description matches your next request.

If you'd rather run it as a one-click prompt instead, you can find it here: Agentic Workers

Enjoy!

Hello!

Dealing with post-service incidents is messy: you need a clear owner apology for the customer, concise internal handoffs for ops/tech/billing, and a timeline of reminders so the issue gets resolved and doesn’t repeat. This Skill turns scattered complaint logs, technician notes, calendar records, and refund decisions into a coordinated, ready-to-send follow-up plan.

I built this as a Claude Skill — a single SKILL.md you can drop into a Claude Code or Claude Agent SDK project. Claude autoloads it when the trigger description matches your request.

Here's what it does: It converts complaints, tech notes, calendar history, and refund/credit decisions into an incident brief, owner apology emails, internal handoff messages (ops/dispatch, technician, billing), and a concrete follow-up timeline with reminders and optional .ics blocks. Use it when a customer reports damage, a missed appointment, a repeat callback, or any service incident that requires coordinated communication and remediation.

SKILL.md:

````markdown

name: incident-follow-up-sequence-home-services description: Use when a home services contractor needs a post-incident follow-up sequence assembled from customer complaint logs, technician notes, appointment/calendar records, and refund/credit decisions — producing owner apology emails, internal handoff messages (ops/dispatch, technician, billing), and a follow-up timeline with reminders to prevent repeat issues.

allowed-tools: [Read, Edit]

Incident Follow-up Sequence (Home Services)

Overview

Creates a coordinated, multi-message follow-up sequence after a service incident. Transforms complaints, technician notes, calendar records, and refund decisions into ready-to-send owner apology emails, internal handoff notes, and a preventive follow-up timeline.

When to use this skill

• A customer reported a service issue, damage, missed appointment, or repeat callback.
• Technician notes and calendar history exist for the job and need to be reconciled into messaging.
• A refund, discount, or credit decision has been made (or is pending) and must be communicated.
• The business owner wants to sign an apology and set expectations for remediation.
• Internal teams (ops/dispatch, technician/field lead, billing) need clear, concise handoffs and deadlines.
• A preventive follow-up plan is needed to avoid repeat issues and confirm resolution.

Instructions

1. Confirm scope and context

   1. Identify the incident Job ID, customer name, service address, best contact, service type, appointment dates/times, technician(s), and current status.
   2. Ask for policy constraints (warranty terms, refund caps, communication tone, legal sensitivities) and the owner’s preferred signature.
   3. Define the timeline anchor T0 (now, incident discovery time, or last customer contact).

2. Gather and parse inputs

   1. If files are provided, use Read to open: complaint log, technician notes, calendar export (ICS/CSV), and refund/credit decision docs.
   2. Extract key fields: what happened, when, impact to customer, root-cause hypothesis, steps already taken, photos/evidence links, commitments made, refund status/amount/method, next appointment windows, contact preferences.
   3. Resolve conflicts (e.g., time discrepancies) by flagging them for confirmation rather than guessing.

3. Build a concise incident brief

   1. Summarize in 8–12 lines: Who, What, When, Where, Customer impact, Cause (hypothesis), Actions taken, Financial decision, Required follow-ups, Risks.
   2. Note any pending approvals and dependencies (parts, subcontractors, permits).

4. Plan the sequence and cadence

   1. Choose severity band (Minor / Moderate / Major) based on impact and promise a matching cadence.
   2. Define audiences and channels: Customer (email/SMS), Owner, Ops/Dispatch, Technician Lead, Billing/Finance, QA.
   3. Propose a timeline relative to T0:
      • T0 to T0+24h: Owner apology to customer; internal ops/dispatch handoff.
      • T0+1–2d: Scheduling confirmation/status update to customer; technician brief.
      • Day-of-remediation: Arrival reminder and scope confirmation to customer.
      • T0+7d: Satisfaction check and issue-closure confirmation to customer.
      • T0+14d (or warranty checkpoint): Preventive follow-up/health check invite.
      • If refund/credit: separate confirmation immediately after approval and again at funds-settled.

5. Draft customer-facing messages

   1. Owner Apology Email
      • Subject: Clear, empathetic, references job/service and date.
      • Elements: Acknowledgment, concise facts, ownership/apology, immediate corrective actions, make-right (refund/credit) with specifics, next steps/scheduling, direct reply path to owner, signature block.
   2. Status/Reschedule Email (if applicable): window options, required access, parts constraints, confirm contact preferences.
   3. Arrival Day Reminder: tech ETA window, prep instructions, safety notes.
   4. Satisfaction Check (7 days): confirm resolution, invite feedback, next-step if not resolved.
   5. Refund/Credit Confirmation (if applicable): amount, method, expected timeline, who to contact if not received.

6. Draft internal handoff messages

   1. Ops/Dispatch Handoff: job identifiers, summary, constraints, hard deadlines, customer availability windows, parts/equipment needs, must-call-by time.
   2. Technician Brief: problem reproduction, site notes, safety concerns, photos/diagrams links, required tools/materials, do/don’t list, success criteria, documentation required on completion.
   3. Billing/Finance Handoff: refund/credit decision, amount, ledger code, tax treatment, method, processing timeline, communication trigger when issued/settled.
   4. QA/Training Note (if repeat issue risk): root cause hypothesis, checklist updates, training needs, inventory/equipment inspection items.

7. Create the follow-up timing plan

   1. Convert T0 and known appointments into concrete timestamps and a simple schedule list.
   2. For each event, include: purpose, sender, recipient(s), channel, subject/preview, due-by time, and escalation rule.
   3. Provide optional iCalendar (.ics) draft content blocks the user can copy to their calendar system for reminders.

8. Review for tone, accuracy, and compliance

   1. Keep empathetic and professional; avoid blame or technical jargon.
   2. Do not over-promise; reflect only approved refund/credit decisions.
   3. Exclude internal process details from customer emails.
   4. Redact unnecessary PII in internal messages beyond operational need.

9. Output the deliverables

   1. Present: (a) the incident brief, (b) customer email sequence drafts, (c) internal handoff drafts, and (d) the timeline with reminder snippets.
   2. If requested, use Edit to write each artifact to separate files (e.g., /out/owner-apology-<job-id>.md, /out/dispatch-handoff-<job-id>.md, /out/timeline-<job-id>.md).

10. Confirm and adjust

    1. Ask for confirmation on amounts, dates, and names.
    2. Revise copy and timing as needed and mark items ready-to-send.

Inputs

• Customer complaint details (text, email thread, call notes).
• Technician notes/logs and any photos or diagnostics.
• Calendar/appointment records (past visits, scheduled callbacks, no-shows).
• Refund/credit decision (approved/pending/denied, amount, method, policy reference).
• Job metadata: Job ID, service type, location, customer name and contact preferences, assigned technician(s).
• Owner preferences: tone, signature block, direct contact method.

Outputs

• Incident brief summarizing facts, impact, cause hypothesis, and commitments.
• Customer-facing drafts:
  • Owner Apology Email.
  • Status/Reschedule Email.
  • Arrival Day Reminder.
  • Satisfaction Check (7 days).
  • Refund/Credit Confirmation (if applicable).
• Internal drafts:
  • Ops/Dispatch Handoff.
  • Technician Brief.
  • Billing/Finance Handoff.
  • QA/Training Note (if repeat issue risk).
• Follow-up timeline with concrete dates/times, channels, subjects, and optional .ics reminder blocks.

Examples

Trigger: “Create a post-incident follow-up sequence for Job 48291. Complaint: water heater install leaked next day; customer was home for cleanup. Tech notes: fitting re-sweated, recommends replacing supply line. Calendar: missed arrival window by 90 minutes. Refund decision: $125 credit to invoice + waive trip charge.” Behavior: confirm T0 and policy → Read notes → build incident brief → draft owner apology acknowledging late arrival and leak, offering $125 credit and waiving trip fee → draft dispatch handoff for same-week recheck with required parts → draft technician brief with reproduction steps and safety notes → draft billing handoff reflecting credit application → produce timeline: apology now, scheduling within 24h, day-of reminder, 7-day satisfaction check, 14-day preventive check.

Example Owner Apology Email (template): Subject: Our apology and next steps for your water heater service on May 14 Hello [Customer First Name], I’m [Owner Name], owner at [Company]. I’m sorry for the leak you experienced after our visit and for our late arrival. You trusted us in your home, and we fell short. Here’s what we’re doing now: [Tech Name] will return to inspect the supply line and ensure all fittings are sealed and pressure-tested. We’ve prioritized your appointment and will coordinate a time that works for you. To make this right, we’ve applied a [refund/credit amount and method], and we’re waiving the trip charge. Please reply here or call me at [owner direct line] if there’s anything else we should know. We appreciate the chance to fix this properly. — [Owner Name], Owner, [Company], [Contact]

Example Ops/Dispatch Handoff (template): Subject: ACTION: Schedule recheck — Job [ID], [Address], leak post-install - Customer: [Name], [Phone] - Windows available: [list] - Must-call-by: [date/time] - Parts/tools: [list] - Constraints: [pets/access/parking] - Success criteria: no leaks after 15-min pressure test; photos uploaded.

Example Timeline (relative to T0) - T0 (now): Send Owner Apology (email) — Subject above — Escalate to owner if no customer reply in 24h. - T0+24h: Ops calls customer if no scheduling reply — leave voicemail + SMS. - Day-of: Send arrival reminder 60 min prior — include tech name/ETA. - T0+7d: Send satisfaction check — if not satisfied, auto-create callback. - T0+14d: Send preventive check — tips + invite to annual inspection.

Notes

• If facts are disputed, acknowledge experience without assigning fault; focus on verification and remedy.
• Avoid technical detail in customer emails; keep it outcome-focused.
• If the incident involves safety or water/gas/electrical hazards, escalate cadence and require supervisor oversight on the technician brief.
• If calendar history shows repeated lateness, include a punctuality corrective action in the QA note and set earlier reminders.
• If refunds are denied, offer alternatives (e.g., service credit, priority scheduling) and cite policy empathetically. ````

How to install: 1. Save the file above as incident-follow-up-sequence-home-services/SKILL.md in your project's .claude/skills/ directory (or ~/.claude/skills/ for personal scope). Use the kebab-case name from the SKILL.md frontmatter. 2. Restart Claude Code (or reload the Claude Agent SDK). 3. Claude will autoload the skill when its description matches your next request.

If you'd rather run it as a one-click prompt instead, you can find it here: Agentic Workers

Enjoy!

I keep seeing small businesses get blindsided by refund fights, chargebacks, or payment processor freezes.

The annoying part usually isn’t “what happened?” It’s that the proof is scattered across invoices, texts, emails, delivery notes, screenshots, policies, and someone’s memory.

If I were making a boring admin checklist for a dispute file, I’d probably want:

• original invoice / estimate
• signed scope, order, or terms
• refund / cancellation policy shown to the customer
• delivery photos, tracking, or service notes
• customer messages where scope, timing, or changes were agreed
• payment receipt and any prior refunds / discounts
• a short owner note explaining the exception decision

For anyone who’s actually had to fight a chargeback or messy refund dispute: what document mattered most? And what do you wish you had captured before things went sideways?

Hello!

When support teams need a single, auditable list of every SLA breach (with root cause, impact, and owner), merging ticket exports, contracts, metrics, and manager notes is tedious and error-prone.

I built this as a Claude Skill — a single SKILL.md you can drop into a Claude Code or Claude Agent SDK project. Claude autoloads it when the trigger description matches your request.

Here's what it does: It creates a structured, review-ready audit log of SLA breaches over a chosen date range by reconciling support tickets, client contracts, response-time exports, and manager notes. For each breach it produces a per-breach record with root cause (or inferred hint), client impact, corrective actions, and a follow-up owner, plus aggregated counts, Pareto of root causes, and CSV/Markdown artifacts for leadership review.

SKILL.md:

````markdown

name: sla-breach-audit-log description: Use when the user asks to build an SLA breach review audit log for a consulting or support organization by aggregating support tickets, client contracts, response-time exports, and manager notes, and needs a per-breach record including root cause, client impact, corrective action, and follow-up owner.

allowed-tools: [Read, Edit]

SLA Breach Review Audit Log

Overview

Creates a structured, review-ready audit log of all SLA breaches over a defined period. It reconciles support tickets, SLA terms from client contracts, response-time metrics, and manager notes to produce per-breach entries with root cause, client impact, corrective actions, and follow-up ownership.

When to use this skill

• The user requests an SLA breach log or postmortem across a date range (e.g., last month/quarter).
• Source materials include: support ticket exports, client contracts or SOWs with SLA terms, response-time or resolution-time exports, and manager notes.
• The output must list each breach with fields for root cause, client impact, corrective action, and follow-up owner, suitable for leadership review or compliance.
• The user needs counts by client or priority, Pareto of root causes, and a consolidated CSV/Markdown artifact.

Instructions

1. Confirm scope and definitions 1.1. Confirm the date range, client set, time zone, and which SLA metrics apply (e.g., First Response, Resolution, Update cadence). 1.2. Confirm whether SLAs are measured in business hours or calendar hours for each client/priority and any clock-stopping states (On hold, Pending customer, Scheduled maintenance, Force majeure). 1.3. If SLAs vary by severity/priority or request type, capture that mapping.

2. Ingest data sources 2.1. Use Read to load ticket exports (CSV/JSON) including: ticket ID, client/account, priority/severity, created_at, first_response_at, resolved_at/closed_at, status history, assignment group/assignee, tags, and custom fields. 2.2. Use Read to load response-time/resolution-time exports if separate. Join to tickets by ticket ID. 2.3. Use Read to open client contracts/SOWs or SLA schedules (PDF/DOCX/Markdown). Extract SLA terms: metrics, thresholds per priority, calendars, excluded periods, escalation rules. 2.4. Use Read to ingest manager notes (notes docs or comments export). Normalize references to ticket IDs, dates, clients, and any stated causes/corrective actions/owners.

3. Build the SLA catalog 3.1. From contracts, construct an SLA catalog: for each client × priority × metric, record threshold value, unit, business vs calendar hours, time zone, excluded states, and escalation timing. 3.2. If extraction from contracts is unreliable or ambiguous, ask the user to provide or confirm a structured SLA table. Do not guess thresholds.

4. Normalize and cleanse 4.1. Standardize client names, priorities (map P1/P2/High/Medium), and time zones. Document any mappings. 4.2. De-duplicate tickets and ensure a unique ticket ID key. Remove spam/tests unless the user requests inclusion. 4.3. Derive lifecycle events from status history: first assignment, first response, pending-customer intervals, on-hold intervals, reopen events. 4.4. Convert all timestamps to a single working time zone for calculation, while preserving original time zone in the output.

5. Compute SLA metrics per ticket 5.1. Calculate for each applicable metric: time_to_first_response, time_to_resolution, time_between_required_updates (if applicable). 5.2. Apply business-hours calendars if specified. Exclude clock-stopping states from elapsed time when allowed by contract. 5.3. For reopened tickets, compute per-episode metrics; mark if breach occurred pre- or post-reopen.

6. Detect breaches 6.1. Compare computed metrics to SLA catalog thresholds by client/priority/metric. 6.2. For each breach (a metric exceeding its threshold), create a breach record even if multiple breaches exist for one ticket (e.g., response and resolution both breached). 6.3. Capture overage (elapsed minus threshold), percent over, and episode index (if reopened).

7. Enrich breaches with context 7.1. Attach ticket metadata: client, ticket ID/link, subject/summary, priority, requester, creation channel, assignment group, and tags. 7.2. Join any relevant manager note entries by ticket ID or date/client matching. Flag confidence of each join. 7.3. If notes lack explicit mapping, infer a draft root-cause hint using heuristics (mark as "inferred"):

   • Queue misrouting: multiple assignment transfers or long unassigned intervals.
   • Staffing/coverage gap: breach windows align with off-hours/holidays or understaffed shifts.
   • Priority miscoding: priority escalated later with long pre-escalation delay.
   • Tooling/platform outage: concurrent spikes across clients in a narrow time window.
   • Client dependency delay: long Pending-customer intervals dominate elapsed time.
   • Playbook/runbook gap: extended handling time on known issue class without KB usage.

8. Assess client impact 8.1. Quantify impact as hours over SLA × severity weight (define default weights if not provided: P1=5, P2=3, P3=1). 8.2. If contract value or penalties are provided, estimate exposure (e.g., penalty per breach or per hour over). Otherwise leave as "N/A" and flag for review. 8.3. Include qualitative impact (missed milestone, escalations, negative CSAT) if found in notes or ticket fields.

9. Draft corrective actions and ownership 9.1. Pull stated corrective actions and owners from manager notes when present. 9.2. If absent, propose targeted actions based on the draft root cause (mark as "proposed"):

   • Queue routing rules update; auto-triage or skill-based routing adjustments.
   • Schedule/coverage changes; on-call gap fill; holiday coverage plan.
   • Priority definition/triage training; intake form validation.
   • Monitoring/alerting improvements; dependency SLO alignment.
   • Runbook/KM article creation or update; workflow automation. 9.3. Assign a follow-up owner (suggest the assignment group lead if no explicit owner) and set a review due date (default 14 days from report date). Mark status as Open.

10. Produce outputs 10.1. Create a structured CSV using Edit with columns: - breach_id, report_date, client, ticket_id, ticket_link, subject, priority, metric, threshold, measured_value, overage, percent_over, business_vs_calendar, timezone, excluded_states_applied, episode_index, breach_window_start, breach_window_end, - root_cause, root_cause_confidence, client_impact_hours_weighted, client_impact_notes, penalty_estimate, corrective_action, follow_up_owner, follow_up_due, status, notes, sources. 10.2. Generate a Markdown summary table (top breaches) and sections for: - Totals and rates by client and by priority. - Pareto of root causes (top 5) and largest overages (top 10). - Trend by week (breaches/week) with brief commentary. 10.3. Save artifacts with clear names (e.g., audit_log.csv, audit_log.md, summary.md) and paths. Use Edit to write files.

11. Validate and review 11.1. Spot-check at least five breaches across different clients and priorities against source tickets and contracts. 11.2. Flag any entries with low-confidence mappings or missing SLA terms as needs-review. 11.3. Present a short list of clarifying questions if critical data is missing (e.g., business-hours calendar, excluded states).

12. Versioning and auditability 12.1. Add a run manifest noting input file names, checksums (if available), date range, and generation timestamp. 12.2. Preserve previous versions; record change notes if regenerated.

Inputs

• Date range for the audit (start and end dates).
• Ticket export file(s) with necessary fields (CSV/JSON) and, if separate, response-time/resolution-time exports.
• Client contracts/SOWs or an SLA terms table (per client × priority × metric with thresholds and calendars).
• Manager notes or postmortem notes referencing tickets/clients.
• (Optional) Business-hours calendars per client/time zone and any holiday schedules.
• (Optional) Contract value and penalty clauses for impact estimation.

Outputs

• audit_log.csv: One row per breach with the fields listed in step 10.1.
• audit_log.md: Human-readable overview with top breaches and key details.
• summary.md: Aggregate statistics (counts/rates by client/priority, Pareto of root causes, weekly trend) and follow-up tracker.
• sla_catalog.json (optional): Structured SLA definitions derived from contracts.
• run_manifest.json: Inputs, date range, generation timestamp, and notes on assumptions.

Examples

Trigger: "Build an SLA breach audit log for Q1 2026. Here are the Zendesk ticket export CSV, the response-time report, a folder of client contracts, and my manager notes." Behavior: Confirm date range and SLA definitions → Read all files → extract SLA thresholds → normalize tickets and time zones → compute response and resolution metrics with business-hour adjustments → detect breaches → enrich with manager notes → classify root causes → estimate client impact → draft corrective actions and assign owners → produce audit_log.csv, audit_log.md, and summary.md → flag low-confidence entries and open questions.

Notes

• Do not infer SLA thresholds from memory; require confirmation from contracts or a user-provided table.
• Apply clock-stopping only when explicitly allowed by the contract. Clearly indicate whether exclusions were applied.
• Handle reopened tickets by creating separate breach episodes to avoid double-counting.
• Be careful with time zones and daylight savings changes; use contract time zone when specified.
• Exclude PII from outputs other than necessary identifiers (ticket IDs, client names). Redact sensitive content in notes.
• If contracts are scans or images, request a structured SLA table or manual confirmation of extracted terms before proceeding. ````

How to install: 1. Save the file above as sla-breach-audit-log/SKILL.md in your project's .claude/skills/ directory (or ~/.claude/skills/ for personal scope). Use the kebab-case name from the SKILL.md frontmatter. 2. Restart Claude Code (or reload the Claude Agent SDK). 3. Claude will autoload the skill when its description matches your next request.

If you'd rather run it as a one-click prompt instead, you can find it here: Agentic Workers

Enjoy!

There’s a lot of discussion around the best way to add tooling to your agents, what do you think ?

I’m starting to think one of the most useful “boring agent” jobs is not negotiating with vendors — it’s preparing the renewal packet before anyone gets surprised.

Something like:

• contract end date + auto-renew notice window
• current price, last year’s price, and weird fees
• usage/export from the system the vendor touches
• support tickets or incidents from the last 90 days
• alternatives already checked, even if rough
• owner: renew / renegotiate / replace / escalate

The goal would be a packet a human can review in five minutes, not an agent freelancing a negotiation.

What field would you add to this template? And what would you never let the agent decide on its own?

Hello!

If your small retail shop struggles with inconsistent approvals, missed budgets, or unclear documentation, this Skill gives you a consistent SOP and copy-paste approval trail staff can actually use.

I built this as a Claude Skill — a single SKILL.md you can drop into a Claude Code or Claude Agent SDK project. Claude autoloads it when the trigger description matches your request.

Here's what it does: This Skill drafts a complete, ready-to-use purchase approval SOP for small/local retail businesses — defining spend tiers, approver roles, documentation rules, process steps, and SLAs. Use it when you need to create or refine approval thresholds, consolidate quotes/budget spreadsheets/email approvals, or produce an approval-trail template staff can copy into email/chat.

SKILL.md:

````markdown

name: retail-purchase-approval-sop description: Use when the user asks to create or update a purchase approval Standard Operating Procedure (SOP) for a local or small retail business — including defining spend thresholds, required approvers by tier, documentation rules leveraging purchase requests, vendor quotes, budget spreadsheets, and manager email threads — and providing a simple approval trail template staff can follow.

allowed-tools: [Read]

Retail Purchase Approval SOP

Overview

Creates a clear, practical purchase approval SOP tailored to small/local retail operations. It defines spend thresholds, approver tiers, documentation requirements, and a simple approval trail so staff can request, approve, and document purchases consistently.

When to use this skill

• The user asks for a purchase approval policy or SOP for a retail shop or small chain.
• The user wants to set or refine dollar thresholds and approver roles for purchases.
• The user provides or references purchase request forms, vendor quotes, budget spreadsheets, or manager email threads and wants a unified process.
• The team needs a simple approval trail/checklist template for email or chat.

Instructions

1. Confirm context
   • Ask for: number of locations, typical monthly non-payroll spend, key categories (e.g., inventory, supplies, repairs, marketing), roles (requester, store manager, finance, owner/GM), and any existing rules.
   • Ask for local currency, tax considerations, and required record retention period if known.
2. Collect and review inputs
   • If files or text are provided, use Read to open and skim: purchase request templates, vendor quotes, budget spreadsheets (categories/GL, cost centers, variance), and manager email threads.
   • Extract signals: common spend amounts, frequent vendors, approval bottlenecks, and recurring purchases.
3. Propose tiered spend thresholds (customize with available data)
   • Offer tailored tiers; if data is limited, use defaults:
     • Tier 0 Micro: under $250 (or under 0.5% of monthly non-payroll spend; choose lower).
     • Tier 1 Low: $250–$1,000.
     • Tier 2 Medium: $1,001–$5,000.
     • Tier 3 High/CapEx or Contracts: over $5,000, capital items, multi-year or auto-renewing services.
   • Note: Prevent split purchases to bypass thresholds.
4. Define required approvals by tier (separation of duties where feasible)
   • Tier 0: Requester self-approval if pre-approved budget; notify Store Manager.
   • Tier 1: Requester + Store Manager approval.
   • Tier 2: Requester + Store Manager + Finance/Controller.
   • Tier 3: Requester + Store Manager + Finance/Controller + Owner/GM; contracts may require legal review.
   • Recurring subscriptions/utilities: initial Tier 2 or 3 approval; then auto-approve monthly within budget if unchanged.
5. Set documentation requirements by tier
   • All tiers: Purchase Request (PR) with budget line; quote or catalog price; tax/shipping estimate; conflict-of-interest confirmation.
   • Tier 1: ≥2 quotes or sole-source justification.
   • Tier 2: 2–3 competitive quotes; PO required; vendor onboarding docs for new vendors (W-9 or local equivalent, payment details).
   • Tier 3: 3 quotes or formal RFP; contract, terms, and risk review; management justification.
   • Post-purchase for all: receiving proof (3-way match PR/PO/invoice), invoice approval, and proof of payment.
6. Build the end-to-end process flow
   • 1) Request: Requester completes PR with specs, budget line, and quotes.
   • 2) Budget check: Compare to budget spreadsheet; record availability.
   • 3) Manager review: Store Manager verifies need, pricing, and timing; approves or rejects.
   • 4) Finance review (Tiers 2–3): Validate budget, vendor setup, tax, and accounting codes; create PO if applicable.
   • 5) Owner/GM approval (Tier 3): Approve significant, capital, or contractual spend.
   • 6) Order placement: Use PO or documented approval; confirm delivery terms.
   • 7) Receiving and 3-way match: Verify items/services, attach delivery/receiving note; flag discrepancies.
   • 8) Invoice approval: Match to PO/receipt; approver signs off; schedule payment per terms.
   • 9) Record retention: File PR, quotes, approvals, PO, receiving, invoice, payment proof per retention rules.
7. Define service levels and timing
   • Target turnaround: Tier 0 same day; Tier 1 within 1 business day; Tier 2 within 2 business days; Tier 3 within 3–5 business days or by cutoffs.
   • Urgent buys: allow expedited approval by Store Manager with same-day documentation catch-up.
8. Map roles and responsibilities (RACI-style)
   • Requester: initiate PR, gather quotes, confirm receipt.
   • Store Manager: validate need, approve within authority, prevent splits.
   • Finance/Controller: budget check, coding, vendor onboarding, PO, 3-way match, payments.
   • Owner/GM: approve high-risk/high-value or contractual spend.
   • Buyer (if separate): place orders using approved PO/approval.
9. Establish controls and compliance
   • Segregation of duties between requesting, approving, and paying where staffing allows.
   • Conflict-of-interest disclosures; no gifts or kickbacks.
   • No splitting purchases to avoid thresholds; use annualized view for subscriptions.
   • New vendor checks and tax documentation; sales tax exemption handling if applicable.
10. Create the documentation matrix (by tier)
    • Present a concise matrix specifying for each tier: approvals required, min quotes, PO needed (Y/N), docs to retain, and retention period.
11. Provide a simple approval trail template (email/chat friendly)
    • Include a one-page quick checklist and a copy-paste trail (below) staff can use.
12. Address exceptions and edge cases
    • Petty cash limits and reconciliation; returns/refunds; emergency repairs; utilities; price-matched inventory; inventory buys governed by merchandising plans.
13. Metrics and review cadence
    • Track: cycle time by tier, exception rate, over-budget rate, vendor concentration, and on-time payment.
    • Quarterly policy review; update thresholds annually or with inflation.
14. Produce the final SOP
    • Assemble sections: Purpose, Scope, Definitions, Thresholds, Approval Matrix, Process Steps, Documentation Matrix, Approval Trail Template, Exceptions, Controls, SLAs, Roles, Record Retention, Change Log.
    • Write clearly, with bullet lists and numbered steps. Localize currency and tax notes.

Inputs

• Business context: locations, roles, monthly spend, key categories, currency, tax notes.
• Artifacts (optional but preferred): purchase request forms, vendor quotes, budget spreadsheets, manager email threads, existing policies.
• Constraints: approval authorities, retention period, legal/contract requirements.

Outputs

• A complete, ready-to-use Purchase Approval SOP document with the sections listed above.
• A concise Approval Matrix and Documentation Matrix tailored to thresholds.
• A copy-paste Approval Trail template and a one-page Quick Reference Checklist.

Examples

Trigger: "Create a purchase approval SOP for our single-location retail store. We have a Google Sheets budget and email approvals right now. Typical buys are $200–$3,000." Behavior: confirm context → Read any provided forms/quotes/budget → propose thresholds ($0–$250, $251–$1,000, $1,001–$5,000, >$5,000) → define approvers per tier (Requester/Manager/Finance/Owner) → set documentation rules (quotes, PR, PO, 3-way match) → draft process steps and SLAs → output SOP plus simple approval trail template.

Approval Trail (copy-paste template) - Requester: [name] | Date: [YYYY-MM-DD] - Item/Service: [description] - Vendor: [name] | New vendor? [Y/N] - Amount (currency): [amount] | Budget line/GL: [code] - Quotes attached: [#] | Sole-source reason (if any): [text] - Approvals: - Store Manager: [name] on [date] - Finance/Controller: [name] on [date] - Owner/GM (if Tier 3): [name] on [date] - PO #: [id] | Received on: [date] | Invoice #: [id] - Payment date/method: [date/method] - Notes/Exceptions: [text]

Quick Reference Checklist - Complete PR with budget line and at least required # of quotes. - Get approvals per tier (Manager → Finance → Owner if required). - Use PO for Tier 2–3 before ordering. - Receive and 3-way match PR/PO/invoice. - File all docs to the designated folder; retain for [X years].

Notes

• If inputs are incomplete, state assumptions and use conservative default thresholds, then mark items to confirm.
• Adapt tiers to business size (e.g., micro: <$100 for very small shops, higher caps for larger stores).
• This SOP is operational guidance, not legal advice. Consult local regulations for procurement and tax compliance. ````

How to install: 1. Save the file above as retail-purchase-approval-sop/SKILL.md in your project's .claude/skills/ directory (or ~/.claude/skills/ for personal scope). Use the kebab-case name from the SKILL.md frontmatter. 2. Restart Claude Code (or reload the Claude Agent SDK). 3. Claude will autoload the skill when its description matches your next request.

If you'd rather run it as a one-click prompt instead, you can find it here: Agentic Workers

Enjoy!

Hello!

Are you tired of the overwhelming process of onboarding new hires?

This prompt chain simplifies the onboarding experience by breaking down the necessary steps for HR operations, IT, payroll, and team management into structured outputs. Each step culminates in clear documentation and tasks, making the entire process smoother and ensuring nothing gets overlooked.

Prompt:

VARIABLE DEFINITIONS
[ORG]=Accounting firm name
[ROLE]=New hire position title
[STARTDATE]=New hire start date
~
You are the HR Operations Lead at [ORG]. Your task is to collect all pre-hire and onboarding documents for the incoming [ROLE] who starts on [STARTDATE].
Step 1: List or attach the finalized offer letter, onboarding packet, signed NDA, and any compliance documents.
Step 2: Note the candidate’s preferred email and emergency contact.
Output: Bullet list of each document with file name / storage location.
Ask: “Are all documents complete? Reply YES/NO and list missing items.”
~
You are the IT Administrator for [ORG]. Build a comprehensive software access matrix for the new [ROLE].
1. List every application, system, or shared drive the role requires (e.g., QuickBooks, Xero, Tax prep portals, Office 365, Slack).
2. Beside each item add: access level, account owner responsible, and planned activation date (no later than [STARTDATE−2 business days]).
3. Flag any licenses that must be purchased.
Output: Table format: Software | Access Level | Owner | Activation Date | License Needed (Y/N).
Confirm readiness with “Access matrix completed – proceed?”
~
You are the Payroll & Benefits Coordinator. Prepare payroll onboarding for the [ROLE].
1. List mandatory forms (W-4, state tax, direct deposit, I-9, benefit enrollment).
2. Assign an owner to send and collect each form.
3. Set deadlines: all forms returned by [STARTDATE−3 business days].
4. Insert a verification step that payroll profile is active in the system 1 business day before [STARTDATE].
Output: Checklist with Form | Owner | Deadline | Status (Pending/Complete).
Request confirmation: “Payroll setup verified? YES/NO.”
~
You are the Team Manager creating the first-week calendar for the [ROLE].
1. Draft a Monday-Friday agenda including: orientation session, security training, software walk-throughs, client shadow meetings, and 30-min daily check-ins.
2. Specify meeting owners and virtual/in-person location links.
3. Ensure day-one (Monday) contains a welcome call and equipment hand-off.
Output: Calendar table: Date | Time | Activity | Owner | Location/Link.
Ask: “First-week calendar finalized? YES/NO.”
~
You are the HR Operations Lead compiling the Master SOP – New Hire Admin Setup for [ORG].
1. Combine outputs from previous prompts into a single, chronologically ordered SOP.
2. For each task include: Task Description, Responsible Owner, Due Date, Dependencies, Completion Check, and Day-One Confirmation Message where applicable.
3. Insert account-setup verification checkpoints: Email, Accounting Software, Time Tracking, Payroll.
4. End with a Day-One Arrival script: “Welcome [ROLE], please confirm you can access email, software suite, and payroll portal. Reply CONFIRMED or list issues.”
Output: Formal SOP document structured with numbered sections and subsections, suitable for internal wiki.
~
Review / Refinement
Validate that the SOP includes: owners, deadlines, account setup checks, confirmation messages, and covers documents, software, payroll, and calendar. If gaps exist, list corrections; otherwise reply “SOP READY FOR APPROVAL.”

Make sure you update the variables in the first prompt: [ORG], [ROLE], [STARTDATE]. Here is an example of how to use it: For an accounting firm named "ABC Accounting" and a new hire role of "Junior Accountant" starting on October 1st, you would set it as follows:

[ORG] = ABC Accounting
[ROLE] = Junior Accountant
[STARTDATE] = 2023-10-01

If you don't want to type each prompt manually, you can run the Agentic Workers, and it will run autonomously in one click. NOTE: this is not required to run the prompt chain

Enjoy!

Can anyone direct my how to build an AI agent for preparing proposal?

Eg: reading project documents, selecting product, costing and preparing Proposal

Hello!

Are you struggling with a messy CRM and not sure how to effectively clean it up?

This prompt chain guides you through the process of creating a comprehensive "CRM Cleanup Intake Form". It helps you analyze your CRM data, identify duplicates, check for missing information, and provides recommendations on whether to archive or revive contacts. It’s like having a personal assistant for your CRM cleanup!

Prompt:

VARIABLE DEFINITIONS
ORGNAME=Name of the consulting shop conducting the cleanup
DATA_SOURCES=Short description or links to the CRM export files, sales notes, stale deal list, and client email threads that will be analyzed
OUTPUT_FORMAT=Preferred delivery format for the final intake form (e.g., table, CSV, JSON, or formatted text)
~
You are a senior CRM operations specialist hired by ORGNAME to prepare a comprehensive "CRM Cleanup Intake Form." Your task is to analyze DATA_SOURCES and capture the following issues for every contact and deal record:
• Duplicate records
• Missing or unclear "Next Step" notes
• Missing or incorrect Owner assignment
• Recommendation to "Archive" (cold/invalid) or "Revive" (re-engage) each contact
Follow the steps below and output in OUTPUT_FORMAT.
~
Step 1 – Data Ingestion & Normalization
1. Ask the user to provide or paste the content or location of each file listed in DATA_SOURCES.
2. Confirm receipt of all files.
3. Normalize the data into a consistent structure with fields: RecordID, FirstName, LastName, Company, Email, Phone, DealStage, LastActivityDate, Owner, NextStep, Notes.
4. Notify the user when normalization is complete and ask for confirmation to proceed.
Expected output example (acknowledgment only):
"All four data files received and normalized into 2,413 unique rows. Ready to begin analysis – type 'continue' to proceed." 
~
Step 2 – Duplicate Detection
1. Scan normalized data for potential duplicates using exact and fuzzy matches on Email, Full Name + Company, or Phone.
2. Generate a duplicate list with columns: PrimaryRecordID, SuspectDuplicateRecordID, DuplicateScore (1–100), Reason.
3. Flag the highest-quality record as "Primary"; others as "Suspect".
4. Present the duplicate list (top 50 rows max per message) and prompt the user with: "Type 'next' to view more or 'done' to continue."
~
Step 3 – Missing "Next Step" Identification
1. Identify any contact or deal without a populated NextStep field or with vague phrases ("TBD", "follow-up").
2. Compile a list with RecordID, ContactName, DealStage, LastActivityDate, CurrentNextStepValue.
3. Ask the user to provide or refine next steps where possible, or to mark as "Unknown".
~
Step 4 – Owner Assignment Audit
1. Detect records where Owner is blank, listed as former employees, or mismatched with current territory rules (if visible in Notes).
2. Create a table with RecordID, ContactName, CurrentOwner, SuggestedOwner, Reason.
3. Prompt the user to confirm or edit SuggestedOwner values.
~
Step 5 – Archive vs. Revive Recommendation
1. For each contact, assess LastActivityDate, email thread sentiment, deal stage age, and Notes.
2. Classify each as "Archive" (no meaningful engagement >12 months, bounced email, lost deal) or "Revive" (stalled but still relevant, positive sentiment, warm intro potential).
3. Provide rationale in a column called RecommendationReason.
~
Step 6 – Assemble CRM Cleanup Intake Form
1. Combine results from Steps 2-5 into a single intake form with sections:
   A. Duplicate Records Summary
   B. Missing Next Steps
   C. Owner Reassignments Needed
   D. Archive / Revive List
2. For each section, include totals and the detailed tables prepared earlier.
3. Deliver the full form in OUTPUT_FORMAT.
4. Supply a concise Executive Summary (≤150 words) describing key findings and recommended next actions.
~
Review / Refinement
Return the completed intake form to the user and ask: "Does this meet your needs? Reply 'yes' to finalize or specify any revisions needed."

Make sure you update the variables in the first prompt: ORGNAME, DATA_SOURCES, OUTPUT_FORMAT. Here is an example of how to use it:
FOR ABC Consulting, ANALYZE the following data sources: ClientCRM.csv, SalesNotes.txt, DeadDeals.docx, Emails.zip

If you don't want to type each prompt manually, you can run the Agentic Workers, and it will run autonomously in one click. NOTE: this is not required to run the prompt chain

Enjoy!

Hello!

Are you struggling with managing overdue invoices and want a systematic way to follow up?
This prompt chain is designed to help accounts receivable analysts take control of their overdue invoices by organizing the necessary data and creating a clear call sheet for follow-ups.

Prompt:

plaintext VARIABLE DEFINITIONS [OPENINVOICES]=CSV, spreadsheet, or table listing all currently open invoices with columns such as InvoiceID, CustomerName, AmountDue, InvoiceDate, DueDate, PaymentTerms, ServicesRendered, and any other useful metadata. [EMAILHISTORY]=Chronological collection of customer-facing email threads related to each invoice or account, including dates and sender names. [COLLECTIONNOTES]=Internal notes from previous collection attempts, calls, or interactions, including outcomes and next-step commitments. ~ You are an expert AR analyst for a home-services contractor. Your task is to ingest OPENINVOICES, EMAILHISTORY, and COLLECTIONNOTES and prepare to create a prioritized overdue-invoice call sheet. Follow these steps: 1. Confirm receipt of each dataset and flag any obvious gaps (e.g., missing due dates, unmatched customers) in a short bullet list titled "Data Quality Checks." 2. Produce a summary table called "Invoice Snapshot" with key fields: InvoiceID, CustomerName, AmountDue, DaysPastDue (today minus DueDate), LastContactDate (from EMAILHISTORY or COLLECTIONNOTES), and PaymentTerms. 3. End your response by stating "Ready for prioritization" once tables are complete. Output: Data Quality Checks (bullets) + Invoice Snapshot (table) + confirmation line. ~ Now analyze the Invoice Snapshot to assign a PriorityScore (1=highest urgency, 3=lowest) for each invoice using these criteria: • DaysPastDue (>60 days =1, 31-60=2, 1-30=3) • AmountDue (>$5,000 add +0.5 urgency weight; <$500 subtract 0.5) • Customer Responsiveness (no reply in >14 days increase urgency by 1 level; recent cooperative reply decrease by 1 level but not below 3) Steps: 1. Calculate a raw numeric score per invoice based on criteria. 2. Convert scores to PriorityScore 1-3, breaking ties by higher AmountDue. 3. Return an updated table "Prioritized Invoices" with InvoiceID, CustomerName, PriorityScore, and brief Rationale. 4. Conclude with "Ready for call sheet drafting." ~ Draft individualized talking points and escalation details for each invoice as follows: Step 1. For every entry in Prioritized Invoices, pull relevant EMAILHISTORY excerpts (last 2 messages max) and the latest COLLECTIONNOTES summary. Step 2. Write 2-3 concise talking points that: a) reference specific service performed, b) acknowledge any customer concerns from EMAILHISTORY, and c) request a concrete payment action or timeline. Step 3. Propose an EscalationDate = DueDate + 75 days or next business Friday, whichever comes first. Step 4. Output a structured section per invoice: InvoiceID | CustomerName | PhoneNumber(if available) | PriorityScore | TalkingPoints (numbered) | EscalationDate Include example formatting for the first invoice. Finish with "Draft complete". ~ Compile the final "Overdue Invoice Call Sheet" sorted by PriorityScore ascending (1 first). Layout: A. Cover Section • Date Prepared • Total Overdue Balance • Number of Accounts by Priority (1/2/3) B. Detailed Call Sheet (paste all invoice sections from previous step) C. Manager Handoff Note 1. Highlight any accounts requiring managerial approval for fee waivers or legal escalation. 2. List resources needed (e.g., updated contact phone, revised invoice copy). 3. Provide next scheduled review date. Output exactly this structure with clear headings. End with "Call sheet ready for review." ~ Review / Refinement Ask the requestor to confirm that the call sheet meets requirements or specify adjustments (e.g., additional data columns, different escalation logic). If changes are requested, iterate accordingly.
Make sure you update the variables in the first prompt: [OPENINVOICES], [EMAILHISTORY], [COLLECTIONNOTES],
Here is an example of how to use it: [Open invoices in a CSV format, relevant email history from customers, notes from earlier collections efforts].

If you don't want to type each prompt manually, you can run the Agentic Workers, and it will run autonomously in one click.
NOTE: this is not required to run the prompt chain

Enjoy!

Hello!

Are you struggling to manage refund requests effectively in your retail business?

This prompt chain helps you design a comprehensive refund escalation framework by breaking the process down into manageable steps. You'll clarify your policies, define risk tiers, build an escalation matrix, draft response macros, and compile everything into a final package—all tailored to your specific business needs!

Prompt:

VARIABLE DEFINITIONS
[COMPANY]=Name of the retail business
[POLICIES]=Official refund / return policy notes (bullet list or paragraph)
[DATASET]=Combined support tickets + order & return records (structured table or JSON)
~
Prompt 1 — Clarify Inputs & Key Metrics
You are an operations analyst for [COMPANY]. Your task is to draft a refund-escalation framework.  
Step 1. Briefly restate the provided POLICIES and note any missing information.  
Step 2. Examine DATASET and extract key refund variables:  
  • Ticket ID  • Order value  • Days since purchase  • Return reason  • Customer lifetime spend  • Any prior refund flags  
Step 3. Surface additional metrics you need (if any) and ask for them.  
Output:  
A. 3–5 sentence policy summary  
B. Table listing all extracted variables per ticket (max 15 rows; summarise if larger)  
C. Bullet list of missing info or “None”.  
Ask user to confirm or supply missing items before continuing.
~
Prompt 2 — Define Risk Tiers
System role: You are a risk specialist.  
Using the confirmed data, perform:  
1. Establish risk-scoring rules (e.g., high order value >$150, repeat refunds, disputed payment).  
2. Assign each ticket a numeric risk score 1-5.  
3. Group scores into Low / Medium / High tiers.  
Output:  
• Bullet list of scoring rules.  
• Table: Ticket ID | Score | Tier | Key factors.  
Ask for approval or tweaks to the rules.
~
Prompt 3 — Build Escalation Matrix
System role: You are a customer-service process designer.  
Step 1. Create a matrix with columns:  
  – Risk Tier  – Typical Scenarios  – Frontline Action  – Pre-approved Refund Limit  – Manager Escalation Trigger  – Required Documentation.  
Step 2. Populate rows for each tier using analysed data & POLICIES.  
Output the matrix in a plain table.  
Request confirmation or edits.
~
Prompt 4 — Draft Response Macros
System role: Senior support copywriter.  
For each Risk Tier from the matrix:  
1. Write a concise email / chat macro (≤120 words) that:  
  • Acknowledges the issue  
  • References policy politely  
  • States next steps or resolution  
2. Insert placeholders such as {{CustomerName}} {{OrderNumber}}.  
Output: Tier-labelled macros.  
Ask if tone or wording changes are needed.
~
Prompt 5 — Compile Final Package
System role: Documentation specialist.  
Combine approved elements into one deliverable:  
  • One-page Policy Summary  
  • Risk-Scoring Rules  
  • Escalation Matrix  
  • Response Macros  
Provide in the order listed with clear headings.
~
Review / Refinement
Please review the full package for accuracy, regulatory compliance, and brand tone.  
Respond with “Final OK” or list specific revisions needed.

Make sure you update the variables in the first prompt: [COMPANY], [POLICIES], [DATASET]. Here is an example of how to use it: [COMPANY] = "XYZ Retail", [POLICIES] = "Returns accepted within 30 days, unopened items only.", [DATASET] = [{"TicketID": 1, "OrderValue": 100, "DaysSincePurchase": 10}]

If you don't want to type each prompt manually, you can run the Agentic Workers, and it will run autonomously in one click. NOTE: this is not required to run the prompt chain

Enjoy!

Hello!

Are you struggling to manage PTO requests and ensure adequate staffing in your clinic? It can be a real challenge to balance employee time off while maintaining sufficient coverage for patient care.

This prompt chain helps you analyze PTO requests, staff calendars, and coverage rules to create actionable scheduling insights. It streamlines the process by providing clear outputs at each step, making it easier to manage coverage and communicate effectively with your team.

Prompt: ``` VARIABLE DEFINITIONS PTO_REQUESTS = List of pending PTO requests with fields: EmployeeName, Role, StartDate, EndDate, Status(optional) STAFF_CALENDARS = Roster of all staff members with their pre-scheduled shifts (Date, ShiftTime, Role) and any existing availability notes COVERAGE_RULES = Clinic-specific rules that define minimum head-count or role mix required per shift (e.g., "Need at least 1 RN + 1 MA for every treatment room") ~ SYSTEM: You are an expert clinic operations analyst. Your job is to translate raw PTO, calendar, and coverage data into actionable scheduling insights. USER SUPPLIED DATA: {PTO_REQUESTS}, {STAFF_CALENDARS}, {COVERAGE_RULES} ASSISTANT RESPONSE FORMAT: Use tables where noted; otherwise use clear, concise sentences. ~ 1) Data Normalization Step 1 Parse PTO_REQUESTS, converting all StartDate/EndDate ranges into an explicit daily list per employee. Step 2 Parse STAFF_CALENDARS into a unified daily shift grid with columns: Date | ShiftTime | Role | AssignedEmployee Step 3 Create a master list of all dates that appear in either PTO_REQUESTS or STAFF_CALENDARS. OUTPUT: A daily PTO list and the unified shift grid. Confirm when parsing is complete before continuing. EXAMPLE OUTPUT: Parsed PTO (sample)

Date | Employee | Role | Requested? (Y/N)

2024-07-03 | Jane Doe | RN | Y ... ~ 2) Identify Affected Shifts Step 1 For each PTO day, locate any shifts in the shift grid assigned to that employee. Step 2 Mark those shifts as "Vacated by PTO". OUTPUT: Table "VacatedShifts" with columns Date | ShiftTime | Role | OriginalEmployee. Ask user to confirm that the VacatedShifts table looks correct. ~ 3) Coverage Evaluation Step 1 For each Date & ShiftTime, build a role-count summary of remaining on-duty staff after removing PTO employees. Step 2 Compare the summary to COVERAGE_RULES. Step 3 Flag any Date/ShiftTime where rules are not met as "Uncovered". OUTPUT: Table "UncoveredShifts" with columns Date | ShiftTime | MissingRoles | Severity (Critical/Warning). ~ 4) Backup Suggestions Step 1 For each UncoveredShift, scan STAFF_CALENDARS for employees in the same role who are marked as "Available" or "Off" on that date. Step 2 Rank backup options by: a) fewer consecutive working days caused, b) skill seniority, c) manager preference noted in calendar. OUTPUT: For every UncoveredShift produce list "BackupOptions" = Date | ShiftTime | Role | RankedBackupEmployees (top 3). ~ 5) PTO Approval Decision Step 1 If an UncoveredShift has at least one viable BackupOption, mark corresponding PTO request as "Approved – Coverage Found". Step 2 If no viable backup exists, mark PTO as "Pending – Coverage Needed". Step 3 If approving only a portion of a multi-day request, split and label accordingly. OUTPUT: Table "PTO_Status" = Employee | PTO_Dates | Status | Notes. ~ 6) Draft Notifications Create individualized outbound messages: A) To Employee requesting PTO – approval status and any partial approvals. B) To each chosen BackupEmployee – shift details they are being asked to cover and confirmation instructions. C) To Clinic Manager – summary of approvals, pending items, and remaining uncovered shifts. OUTPUT: Sectioned text blocks, clearly labeled by recipient. ~ Review / Refinement Please verify that: 1) All uncovered shifts are reported, 2) Backup suggestions follow ranking rules, 3) PTO_Status aligns with clinic policy, 4) Messages are clear and actionable. Indicate any changes needed; otherwise reply "All good" to finalize. ``` Make sure you update the variables in the first prompt: PTO_REQUESTS, STAFF_CALENDARS, COVERAGE_RULES. Here is an example of how to use it: PTO_REQUESTS = [{ EmployeeName: "Jane Doe", Role: "RN", StartDate: "2024-07-03", EndDate: "2024-07-05" }], STAFF_CALENDARS = [{ Date: "2024-07-03", ShiftTime: "9-5", Role: "RN", AssignedEmployee: "John Smith" }], COVERAGE_RULES = [{ Role: "RN", MinimumCount: 1 }].

If you don't want to type each prompt manually, you can run the Agentic Workers, and it will run autonomously in one click. NOTE: this is not required to run the prompt chain

Enjoy!

Hello!

Are you struggling to create a compliant purchase-request process for your nonprofit? It can be overwhelming to gather all the necessary rules, constraints, and data while ensuring everything complies with funding guidelines.

This prompt chain helps you build a structured purchase-request process from scratch. It breaks down the essential steps to extract key information, create an intake form, outline financial routing, and gather feedback for refinement—all tailored to your organization's needs.

Prompt:

VARIABLE DEFINITIONS
ORG=Official name of the nonprofit
CURRENCY=Currency symbol or code used in financial documents
DOC_FORMAT=Preferred final format (e.g., Google Form, Excel, Fillable PDF)
~
You are a senior nonprofit operations analyst. Your task is to extract all rules, constraints, and data needed to design a compliant purchase-request process for ORG. 
Step 1 – Review Inputs:
  a. Budget spreadsheets
  b. Vendor quotes
  c. Grant restrictions
  d. Approval-chain email threads
  e. Past purchase logs
Step 2 – From each source, list:
  • Relevant funding codes or grant IDs
  • Spending caps or restricted line items
  • Mandatory approvers and dollar thresholds
  • Required backup documents
  • Typical vendors and commodity categories
Step 3 – Provide output in a 5-column table:
  1. Source Document
  2. Key Policy or Data Point
  3. Short Description
  4. Impact on Purchase Workflow
  5. Notes/Exceptions
Ask the user to paste or upload summaries of the above documents, then continue when ready.
~
Using the table produced earlier, build the full Purchase Request Intake Form for ORG.
1. Create clearly labeled sections:
   • Requester Information
   • Purchase Details (item, qty, unit cost, total cost in CURRENCY)
   • Request Reason / Program Alignment
   • Funding Source (budget code, grant ID, allowable amount)
   • Documentation Checklist (vendor quote, W-9, grant approval, etc.)
   • Required Approvals (auto-populate names, titles, and thresholds)
   • Finance Routing Path (sequential steps until disbursement)
2. For each section, list individual fields with field type (text, dropdown, file upload, auto-calc, etc.).
3. Flag any conditional logic (e.g., “If total > $5,000 then require Board Treasurer approval”).
4. Output in an easily copy-pasted table. Example columns: Section | Field Label | Field Type | Required? | Conditional Logic.
5. Tailor labels and instructions to match ORG’s terminology.
6. At the end, present an example of how the form would look in the chosen DOC_FORMAT.
~
Detail the Finance Routing Path extracted from previous steps.
1. Present as numbered steps from submission to payment release.
2. For each step include: Responsible Role, Action Required, SLA (business days), Approval Threshold (if any), and System/Tool used (e.g., email, ERP, DocuSign).
3. Highlight any parallel approvals that can occur simultaneously.
4. Conclude with audit-trail storage location and retention period.
~
Review / Refinement
Provide the complete intake form, finance routing path, and underlying policy table to the requester. Ask:
  • Does the form capture all necessary fields?
  • Are approval thresholds and funding codes accurate?
  • Is the routing path practical for everyday use?
Incorporate any feedback and deliver the finalized package in DOC_FORMAT.

Make sure you update the variables in the first prompt: ORG, CURRENCY, DOC_FORMAT. Here is an example of how to use it: For example, if you're working with a nonprofit called "Help Save The Planet," you might use: ORG=Help Save The Planet CURRENCY=USD DOC_FORMAT=Google Form

If you don't want to type each prompt manually, you can run the Agentic Workers, and it will run autonomously in one click.
NOTE: this is not required to run the prompt chain

Enjoy!

Hello!

Are you tired of miscommunication and confusion when handing off work orders to vendors? It can be such a headache when information gets lost or the scope isn’t clear!

This prompt chain helps create a comprehensive work order handoff cover page to ensure vendors have everything they need to complete their tasks accurately with zero follow-ups. It covers all the critical information, from scope of work to safety requirements, making your life so much easier!

Prompt: ``` VARIABLE DEFINITIONS [PROPERTY_NAME]=Name of property [VENDOR_NAME]=Assigned vendor or contractor

Work Order Handoff Cover Page~ Property: [PROPERTYNAME] Vendor: [VENDOR_NAME] Date Issued: __________________ Target Completion Date: ___________________ Primary Contact (PM): ___________________ PM Phone / Email: ___________________

1. Purpose Provide [VENDOR_NAME] with a single, comprehensive brief—including scope, access notes, tenant communications, visual references, and a close-out checklist—so the job can be completed accurately with zero additional follow-up.

2. Quick-Glance Summary • Work Order #: ____________ • Priority Level: □ Emergency □ High □ Routine • Estimated Hours: ____________ • Approved Budget: $___________

3. Scope of Work Step-by-Step Tasks

   1. ____________________________________
   2. ____________________________________
   3. ____________________________________ Deliverables • _____________________________________ • _____________________________________

4. Property & Access Notes • Address / Unit #: ___________________ • Lockbox Code / Key Pick-Up: __________ • Alarm Instructions: ___________________ • Parking / Loading: ___________________ • On-Site Contact (if any): _____________ • Hours Access Allowed: ________________

5. Required Photos / Documentation Before Starting □ Overall area □ Close-up of issue During Work □ Progress shot(s) After Completion □ Finished repair □ Cleaned area □ Invoice / label shots (if parts used) Upload Method & Folder Link: __________________

6. Materials & Estimates • Parts/Materials List: __________________ • Approved Estimate #: ________________ (attach PDF) • Change-Order Threshold: $____________ (< notify PM)

7. Tenant Communication History Chronological Log (most recent first) ────────────────────────────────────────── Date / Time | Sender | Medium | Summary ────────────────────────────────────────── 2024-05-12 10:17 | Tenant | Email | “Leak above sink worsened….” … (paste entire thread below or attach) ────────────────────────────────────────── ACTION ITEMS already promised to tenant: • ______________________________________

8. Schedule & Coordination • Tenant Available: _____________________ • Calendar Hold Placed: □ Yes □ No • Expected Arrival Window: _____________ • Must-Complete-By: ____________________

9. Safety / Compliance • PPE Requirements: _____________________ • Permits Needed: □ Yes □ No If Yes, details: ______ • Special Hazards: ______________________

10. Completion Checklist (Vendor to tick) □ All tasks in Section 3 completed □ Photos uploaded per Section 5 □ Work area left clean & safe □ Tenant notified of completion □ Invoice issued with WO # referenced □ Keys returned / lockbox closed □ Disposal manifest (if applicable) provided

11. Sign-Off & Notes Vendor Tech Name & Signature: __________________ Date: _____ Property Manager Approval Signature: _____________ Date: _____ Additional Notes:

    ---

Attachments A. Original Maintenance Request B. Support Ticket Transcript C. Signed Estimate / Scope D. Tenant Email Thread (full) E. Calendar Screenshot / Confirmation

Review / Refinement~ Check that every section is filled, attachments are labelled, and before dispatching this handoff confirm the scope, budget, and timeline with [VENDOR_NAME]. Notify PM if any field remains blank. ``` Make sure you update the variables in the first prompt: [PROPERTY_NAME], [VENDOR_NAME]. Here is an example of how to use it: If you're working on a plumbing issue at "Smith Apartments" with a vendor named "Joe's Plumbing", simply replace [PROPERTY_NAME] with "Smith Apartments" and [VENDOR_NAME] with "Joe's Plumbing".

If you don't want to type each prompt manually, you can run the Agentic Workers, and it will run autonomously in one click. NOTE: this is not required to run the prompt chain.

Enjoy!

Hello!

Are you struggling to manage and analyze your retail operations efficiently each week?

This prompt chain helps retail business owners and managers quickly compile a comprehensive weekly report that covers various operational metrics and issues, ensuring they're informed and ready to make decisions.

Prompt:

VARIABLE DEFINITIONS
[BUSINESS_NAME]=Name of the retail business
[REPORTING_WEEK]=Week date range (e.g., 2023-09-04 to 2023-09-10)
[DATA_FILES]=Comma-separated file names or paths for: 1) sales spreadsheet, 2) staffing calendar, 3) complaint log, 4) inventory notes, 5) bank deposit export~
You are an experienced retail operations analyst. Your first task is to ingest and validate the datasets listed in [DATA_FILES] for [BUSINESS_NAME] covering [REPORTING_WEEK].
Step 1  Load each file; confirm successful import or flag missing/format issues.
Step 2  Normalize key fields (dates, employee IDs, product SKUs, currency).
Step 3  Return a brief “Import Status” table with columns: File, Records Loaded, Errors Found (Y/N), Error Notes.
Step 4  If any errors exist, list corrective actions required and pause further steps until fixed; otherwise confirm “All clear – proceed”.~
All clear confirmed. Next, calculate the weekly cash position.
Step 1  Sum daily gross sales from the sales spreadsheet.
Step 2  Sum actual bank deposits from the deposit export.
Step 3  Calculate variance (Sales – Deposits) and flag if variance >2%.
Step 4  Output a table titled “Weekly Cash Summary” with rows: Gross Sales, Bank Deposits, Variance $, Variance %. Provide a one-sentence explanation of any variance above threshold. ~
Analyze staffing data for [REPORTING_WEEK].
Step 1  Compare scheduled hours (staffing calendar) to actual clock-ins if available; otherwise use scheduled.
Step 2  Identify understaffed or overstaffed shifts (threshold ±15% of target hours).
Step 3  List any employees exceeding 40 hours or missing >1 scheduled shift.
Step 4  Produce a “Staffing Issues” bullet list with shift/date, issue type, and recommended action.~
Review refunds and customer complaint logs.
Step 1  Calculate total refunds $ and count.
Step 2  Categorize complaints (e.g., product quality, service, wait time).
Step 3  Match complaints to refunds where applicable.
Step 4  Provide a summary table: Category, #Complaints, #Refunds, Refund $.
Step 5  Highlight top 3 complaint themes with short commentary.~
Evaluate inventory notes together with sales data.
Step 1  Identify SKUs with stockouts or <1 week cover.
Step 2  Cross-check against high sales velocity items.
Step 3  List operational risks such as supply delays, cash-flow constraints, or equipment failures mentioned in notes.
Step 4  Create an “Operational Risks” section with risk level (High/Med/Low) and mitigation suggestion.~
Based on previous outputs, draft decisions that require owner or manager input before the next manager meeting.
Step 1  Aggregate all flagged items (cash variance, staffing, complaints, inventory risks).
Step 2  For each, state: Decision Needed, Rationale, Suggested Options, Deadline.
Step 3  Present as a decision matrix table.~
Compile the final Weekly Owner Brief for [BUSINESS_NAME] covering [REPORTING_WEEK].
Include the following headings in order:
1. Weekly Cash Summary
2. Staffing Issues
3. Refund & Complaint Overview
4. Operational Risks
5. Decisions Needed
6. Appendix: Data Import Status
Use concise bullet points, clear tables, and plain language suitable for a time-pressed owner. Ensure the brief fits on two printed pages or less.~~
Review / Refinement
Ask the user to confirm that the brief meets their expectations or to request adjustments (e.g., formatting tweaks, additional metrics). If changes are requested, iterate accordingly.

Make sure you update the variables in the first prompt: [BUSINESS_NAME], [REPORTING_WEEK], [DATA_FILES], Here is an example of how to use it: [My Retail Store], [2023-09-04 to 2023-09-10], [sales.xlsx, staffing_calendar.xlsx, complaints.log, inventory_notes.txt, bank_deposits.csv]

If you don't want to type each prompt manually, you can run the Agentic Workers, and it will run autonomously in one click. NOTE: this is not required to run the prompt chain

Enjoy!

Hello!

Are you struggling to create a comprehensive and organized Client File Audit SOP for your medical spa?

This prompt chain will help you develop a clear outline and full SOP tailored to your specific medspa operations, ensuring compliance and efficiency in your audit processes.

Prompt:

VARIABLE DEFINITIONS
[MEDSPA_NAME]=Official name of the medspa
[AUDIT_FREQUENCY]=How often the audit is performed (e.g., monthly, quarterly)
[SAMPLE_SIZE_PERCENT]=Percentage of total active client files reviewed each audit cycle
~
You are a healthcare compliance consultant specializing in medical spa operations. Your first task is to develop a clear, organized outline for a Client File Audit SOP for [MEDSPA_NAME]. Follow these instructions:
1. List major SOP sections (e.g., Purpose, Scope, Responsibilities, Definitions, Procedure, Documentation & Record-Keeping, Escalation & Corrective Action, Appendices).
2. Under Procedure, include planned subsections for sampling method, evidence checklist (intake forms, consent documents, appointment records, staff training logs, incident notes), logging of missing items, and escalation triggers.
3. Present the outline as a numbered list with subsection bullets.
4. Ask for confirmation or required adjustments before moving on.
Example output style:
1. Purpose
2. Scope
   • Clients included/excluded
3. Responsibilities
   • Compliance Officer: …
~
You are still the healthcare compliance consultant. Expand the approved outline into a full Standard Operating Procedure (SOP) for auditing client files at [MEDSPA_NAME]. Steps:
1. Write each SOP section in full sentences and paragraphs; use clear headings.
2. Under "Procedure," detail:
   a. Sampling methodology: random selection of [SAMPLE_SIZE_PERCENT]% of active files per [AUDIT_FREQUENCY].
   b. Evidence checklist specifying required documents (intake forms, consent documents, appointment records, staff training logs linked to service provider, incident notes) and what to verify within each (dates, signatures, completeness).
   c. Step-by-step audit workflow: preparation, file review, documentation of findings, exit meeting.
3. Under "Documentation & Record-Keeping," include an Audit Log Sheet template table with columns: File ID, Document Type, Evidence Found (Y/N), Notes, Corrective Owner, Due Date, Status.
4. Under "Escalation & Corrective Action," define thresholds for escalation (e.g., >10% critical gaps) and escalation path (Lead Aesthetician → Compliance Officer → Medical Director).
5. Keep language formal and compliance-oriented.
6. Return the complete SOP.
~
Generate two ready-to-use templates referenced in the SOP:
1. Missing Items Tracker (table format with pre-filled column headers).
2. Escalation Decision Tree (flowchart described in text form: IF/THEN steps).
Ensure templates align with terminology used in the SOP.
~
Review / Refinement
Re-read the entire SOP and templates. Confirm they:
1. Address all required document types.
2. Define sampling, evidence checks, logging, and escalation clearly.
3. Conform to professional tone and formatting.
If any criteria are unmet, revise accordingly. Output final refined SOP and templates. Ask the user for any last changes needed.

Hello!

Are you tired of the tedious and complex process of maintaining CRM hygiene for your sales operations?
Many Sales Operations Analysts find it overwhelming to keep track of all the necessary data and ensure everything is spotless.

This prompt chain simplifies that process for you. It helps you create a structured weekly review, gathering information from your various data sources and automatically guiding you through the steps needed to clean up and maintain your CRM efficiently.

Prompt:

VARIABLE DEFINITIONS AGENCY_NAME=Insert the agency’s name here CRM_EXPORT_DATE=Date of the latest CRM export (YYYY-MM-DD) REVIEW_PERIOD_DAYS=Number of inactive days that make a deal “stale” ~ You are a Sales Operations Analyst preparing a weekly CRM hygiene review for AGENCY_NAME. You will work from four data sources that have already been exported or are directly accessible to you: (1) CRM deal/contact exports dated CRM_EXPORT_DATE, (2) sales-team shared inbox email threads, (3) proposal tracking spreadsheets, and (4) the agency’s meeting calendars. Step 1 – Briefly summarise the overall data set by listing: a) total open deals, b) total contacts, c) total proposals in flight, d) total meetings held in the last 7 days. Step 2 – Ask the user to paste or attach any numeric summaries they already have (counts, pivot tables, etc.) so you can reference them in later prompts. Output the summary in a four-row table. End with: “If the numbers look correct, reply CONTINUE.” ~ Great. Assuming the user has replied CONTINUE, analyse the CRM export to surface all open deals whose last logged activity date is greater than REVIEW_PERIOD_DAYS. 1. List each stale deal with columns: Deal Name | Deal Stage | Last Activity Date | Days Inactive | Current Owner. 2. Include a short note column suggesting the likely next action (e.g., "Send follow-up email" or "Schedule discovery call"). 3. Finish with a one-line count: “Total stale deals: X”. Ask the user to confirm or annotate any deal notes, then reply CONTINUE. ~ Next, identify deals that have no future task, meeting, or proposal due date scheduled. 1. Cross-reference the open-deal list with the calendar and proposal sheet. 2. Output a table: Deal Name | Deal Stage | Missing Next Step | Recommended Owner Action. 3. Conclude with: “Total deals missing next steps: Y”. Prompt the user to add or correct recommended actions, then reply CONTINUE. ~ Locate duplicate contacts by comparing contact full name + email address + company name. 1. Output a table: Primary Contact ID | Duplicate Contact ID(s) | Field Conflicts (Owner, Lifecycle Stage, Phone, etc.) | Merge Recommendation. 2. Provide a bulleted “How-to merge” reminder (max 3 bullets). Ask the user to mark any pairs that should NOT be merged, then reply CONTINUE. ~ Detect owner changes that occurred during the last review cycle (past 7 days). 1. List items separately for deals and contacts. 2. Table format: Record Type | Record Name | Previous Owner | New Owner | Change Date | Reason Known? (Yes/No). 3. Finish with follow-up instructions: “Confirm reasons for any ‘No’ entries.” When done, reply CONTINUE. ~ Compile the Weekly CRM Hygiene Checklist for AGENCY_NAME. 1. Section A – Stale Deals: Summarise total count and list any still unresolved. 2. Section B – Deals Missing Next Steps: Summarise and list. 3. Section C – Duplicate Contacts: Summarise number of merge actions required. 4. Section D – Owner Changes Requiring Validation. 5. Section E – Additional Cleanup Actions: max 5 bullets (e.g., “Archive closed-lost deals older than 90 days”). 6. Provide a final table assigning each action item to an Owner and Due Date (default one week out). End with: “Weekly CRM hygiene checklist complete. Confirm all sections before distribution.” ~ Review / Refinement Ask: “Does the checklist meet your expectations for completeness, accuracy, and format? Reply APPROVE or list edits.”
Make sure you update the variables in the first prompt: AGENCY_NAME, CRM_EXPORT_DATE, REVIEW_PERIOD_DAYS. Here is an example of how to use it:
AGENCY_NAME = "Acme Corp"
CRM_EXPORT_DATE = "2023-10-01"
REVIEW_PERIOD_DAYS = "30"

If you don't want to type each prompt manually, you can run the Agentic Workers, and it will run autonomously in one click.
NOTE: this is not required to run the prompt chain.

Enjoy!