Best PromptsSupport Macro Library
Turn your most common tickets into a reusable macro library with tone rules, escalation triggers, and honest wording for the bad news.
Ticket data: """ [PASTE 20-100 REAL TICKETS OR THEIR SUBJECTS AND FIRST MESSAGES. RAW IS BEST.] """ Build a support macro library from the tickets above. Product: [WHAT IT DOES] Our voice: [e.g. "warm and plain-spoken, never corporate" / "precise and technical, our users are engineers"] Policies I can state: [REFUNDS, SLAS, DATA HANDLING, WHAT WE WILL AND WILL NOT DO] Known issues we get contacted about: [LIST] Where we escalate and to whom: [PATHS] Produce: 1. **Ticket clusters** ranked by volume, each with the count, the underlying question in one line, and whether the real fix is a macro, a documentation change, or a product change. Label them, because writing a macro for a problem that should be fixed in the product just makes the problem cheaper to tolerate. 2. **Macros** for the top [15-25] clusters. Each with: - A short internal name and the trigger for using it - The reply, in our voice, personalizable in one or two spots marked clearly - The first sentence answering the question or naming the next step, with no preamble - The specific next step for the customer, and what we will do and by when - A note on when NOT to use this macro 3. **Hard-news macros.** The replies for "no, we will not refund that", "that feature does not exist and is not planned", "this was your mistake, not ours", and "we had an outage that cost you". Write these plainly and without hedging. A clear no is easier to accept than a warm maybe, and the hedged version generates a second ticket. 4. **Escalation triggers.** The exact conditions where a macro must not be used and a human takes over: legal threats, security reports, accessibility complaints, distressed customers, anything touching money above [THRESHOLD]. 5. **Tone rules** for the library: three things always to do and three phrases never to use, each with the reason. 6. **Documentation and product gaps** the ticket data reveals, ranked by the volume they would remove. Rules: state only my real policies. Never promise a timeline, refund, or feature I did not authorize. Where a macro would need a policy we do not have, flag it as [POLICY NEEDED] instead of inventing one.
How to use
Section 1 lifts this above a template exercise: a macro is the correct answer for a recurring question and the wrong answer for a recurring defect, and the volume ranking tells you which you have. Spend your editing time on the hard-news macros. They get written once under calm conditions and used repeatedly under pressure, which is the reverse of how they usually get produced.
More business prompts
Build me a monthly budget and a debt payoff plan from these numbers. Take-home income per month: [AMOUNT, and note if it varies] Fixed costs: [RENT/MORTGAGE, UTILITIES, INSURANCE, SUBSCRIPTIONS, TRANSPORT, CHILDCARE, with amounts] Variable spending, last 3 months if known: [GROCERIES, DINING, SHOPPING, ETC.] Debts: [FOR EACH: name, balan
Budget and Debt Payoff Plan
Turn your real income, bills, and debts into a monthly budget and a payoff schedule with the math shown and the tradeoffs named.
Build a 13-week cash flow forecast. Cash on hand today: [AMOUNT, and which accounts] Any restricted or committed cash: [AMOUNT AND WHAT IT IS FOR] Expected inflows: - Receivables outstanding: [CUSTOMER, AMOUNT, INVOICE DATE, TERMS, and how reliably each pays] - Recurring revenue: [AMOUNT, BILLING DATE, CHURN ASSUMPTION] - New sales expe
13-Week Cash Flow Forecast
Build the rolling weekly cash forecast operators actually run on: opening balance, timed inflows and outflows, and the week you run short.
Help me set pricing for [PRODUCT/SERVICE]. What it does and who buys it: [PRODUCT + BUYER] The alternative if they do not buy: [COMPETITOR, IN-HOUSE, SPREADSHEET, DOING NOTHING] What that alternative costs them: [MONEY, TIME, RISK. Estimate if needed and say so.] Value we create, quantified if possible: [TIME SAVED, REVENUE GAINED, COST
Pricing Strategy
Work out what to charge and how to package it: value basis, tier structure, the metric you meter on, and how to test before committing.