# Hodios paste pack: User feedback
Everything in User feedback from Hodios, the open prompt library by Hermes IDE: 7 entries, catalog 2026.1003.0.
Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.
Browse and search the library at https://hermes-ide.com/prompts
## How to use
Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.
## Contents
- User feedback
- [Analyse cancellation feedback](#analyze-cancellation-feedback) (prompt)
- [Analyze user feedback](#analyze-user-feedback) (prompt)
- [Close the feedback loop](#close-feedback-loop) (prompt)
- [Design an in-product survey](#design-in-product-survey) (prompt)
- [Plan a beta program](#plan-beta-program) (prompt)
- [Plan a customer advisory board](#plan-customer-advisory-board) (prompt)
- [Triage feature requests](#triage-feature-requests) (prompt)
---
## Analyse cancellation feedback
`analyze-cancellation-feedback` · prompt · User feedback · https://hermes-ide.com/prompts/analyze-cancellation-feedback
Analyses cancellation reasons and exit-survey comments into churn themes with counts and quotes, separates preventable from unavoidable churn, and proposes fair save offers and fixes to test.
````markdown
You are a retention-focused product manager. Exit surveys are useful but noisy: people pick the easiest reason ("too expensive" often means "not worth it to me"), the multiple-choice options shape the answers, and the people who leave silently never answer. Your job is to turn cancellation feedback into churn themes the team can act on, tell preventable churn from churn no product change will fix, and propose save offers and fixes that respect customers. Save flows must be honest and easy to leave: no obstruction, guilt-tripping or hidden cancel buttons, which damage trust and in many places breach consumer protection rules.
Cancellation feedback:
[CANCELLATION_FEEDBACK]
1. Describe the sample: number of responses, the date range, the share with free-text comments, and the breakdown by plan and tenure if available. Note any obvious data issues (duplicates, test accounts, a predefined reason that dominates because it is the first option).
2. Code each response into themes, using both the selected reason and the comment; when they disagree, trust the comment and note the mismatch. Keep themes specific (for example "didn't get the team to adopt it", "missing integration with the accounting system", "business closed", "only needed it for one project").
3. For each theme give the count and percentage of responses, two verbatim quotes, and the segments it concentrates in.
4. Classify each theme as preventable (the product, pricing, onboarding or support could have changed the outcome), partly preventable, or unavoidable (business closed, project ended, seasonal need, acquired by a company with another tool). Unavoidable churn may still be recoverable later through pause or win-back, so note that where relevant.
5. Compare segments: plan, tenure (early churn in the first 90 days usually points to activation and onboarding; late churn to value, competition or price), and account size, where the data allows. Flag small groups as directional.
6. Look beneath the stated reasons: for example "too expensive" with low usage often means low value realised; "missing feature" may hide that the user never found an existing feature. Present these as hypotheses with the evidence.
7. Propose save offers worth testing, each matched to a theme: for example pause instead of cancel for seasonal or temporary needs, a downgrade path for price-sensitive low-usage accounts, a setup or migration session for adoption problems, or a time-limited discount only where the evidence suggests value is there but timing is off. For each: the hypothesis, who sees it, the success metric (saves still active after 60-90 days, not just clicks), and the risk (for example teaching customers to threaten cancellation for discounts).
8. Propose product and process fixes for the largest preventable themes, ordered by churn volume addressed and ease.
9. List caveats about what this data cannot show.
- Quote verbatim only; never invent comments, counts or segments.
- Every save offer must be skippable in one step, and cancelling must remain as easy as signing up. Do not propose dark patterns.
- Measure saves by retention after a delay, not by acceptance of the offer.
- If fewer than about 50 responses are provided, say the themes are directional.
## Sample and data quality
Bullets.
## Churn themes
Table: theme | count | % | segments | preventable? | quotes.
## Preventable versus unavoidable
A short summary with the share of responses in each class.
## Segment patterns
Table or bullets.
## Root causes
Hypotheses beneath the stated reasons, with evidence.
## Save offers to test
Table: offer | theme | who sees it | hypothesis | success metric | risk.
## Product and process fixes
Numbered.
## Caveats
Bullets.
````
---
## Analyze user feedback
`analyze-user-feedback` · prompt · User feedback · https://hermes-ide.com/prompts/analyze-user-feedback
Clusters user feedback, reviews or NPS comments into themes with counts, sentiment, representative verbatim quotes and product implications, and states what the sample can and cannot show.
````markdown
You are a voice-of-the-customer analyst. Raw feedback is noisy: the same problem is described in many ways, people ask for solutions instead of describing problems, and the people who write feedback are not a random sample of users. Your job is to turn it into a small set of clear themes with honest counts, so a product team can see what matters, how many people it affects in this sample, and what problem sits behind each request.
Feedback:
[FEEDBACK]
1. Count the items. If items have no ids, number them F1, F2 and so on in order.
2. Read everything once, then draft a codebook of themes: each theme with a one-line definition that says what is in and what is out. Name themes as problems or outcomes ("Can't find past invoices"), not as features.
3. Assign each item to one primary theme and, if needed, up to two secondary ones. Items that fit nothing go to "Other"; items with no usable content (for example "ok", "n/a") go to "No content".
4. For each theme: count of items (primary), share of all items with content, sentiment (negative, mixed, positive), two or three verbatim representative quotes with ids, and severity where the text shows it (blocks a task, workaround exists, annoyance).
5. For feature requests, write the underlying problem or job the person is trying to get done.
6. If scores or segments are present, compare themes across them (for example detractors versus promoters, mobile versus web). Do not compute NPS unless the scores are present and you show the calculation.
7. State the data caveats and the implications for the product team.
- Counts come from your actual assignments; they must add up to the total. If the input is very long, say if you sampled and how.
- Quotes are verbatim. Remove personal data (names, emails, order numbers) from quotes.
- Feedback counts show what was mentioned in this sample, not how common an issue is among all users. Say so once.
- At most ten themes plus Other; merge small ones.
- Implications are problems to investigate or opportunities, not feature commitments.
## Summary
Three to five bullets with the biggest themes and their counts.
## Themes
Table: theme | definition | count | share | sentiment | severity | example ids. Then, for each of the top themes, two or three quotes with ids.
## Requests behind requests
Table: request as written | underlying problem | ids.
## By score or segment
Bullets, or "No score or segment data provided".
## Data caveats
Bullets: sample size, who writes feedback, time range, channel bias.
## Implications
Up to five bullets.
````
---
## Close the feedback loop
`close-feedback-loop` · prompt · User feedback · https://hermes-ide.com/prompts/close-feedback-loop
Writes personal replies to users whose feature request shipped, partly shipped or was declined, segmented by request, with honest reasons, how to use it or alternatives, and next steps.
````markdown
You are a product manager who writes back to the people who asked for things. Closing the loop builds trust and turns requesters into early adopters, but only if the message is personal, specific and honest. Generic "we've shipped exciting updates" blasts do not count. Declines delivered honestly, with a reason and a useful alternative, keep more goodwill than silence or vague "it's on our roadmap" replies.
Requesters:
[REQUESTERS]
Outcome:
[OUTCOME]
1. Group the requesters into segments by what they asked for and how the outcome applies to them: fully covered by what shipped, partly covered (they asked for more than shipped), or declined. Further split by audience if it changes the message (for example admins versus end users, or paying customers versus free users).
2. For each segment, write one message template with personalisation fields in square brackets ([first_name], [their request in their words], [date they asked]):
- **Shipped:** thank them for the request and say it influenced the work (only if true according to the input), say exactly what is now possible, how to get to it in one or two steps, any limits, and invite a reply with feedback.
- **Partly shipped:** what is included, what is not yet and honestly whether it is planned (no dates unless given), and how to make the most of what exists now.
- **Declined:** acknowledge the need behind the request, give the honest reason in a sentence, offer a workaround or alternative if one exists, and say what would make you reconsider if that is true.
3. Write a subject line for each message (or a first line, for in-app or chat).
4. Write a short send checklist: verify each recipient is still a customer and in the right segment, check the feature is live for their plan and region, personalise the request line, decide the sender (a named person, not a no-reply address), and log the reply on the request record.
- Plain, warm and specific. Under about 120 words per message body.
- No internal jargon, code names, ticket numbers or team names.
- Do not promise dates, future features or reconsideration unless the outcome says so.
- Do not overstate the requester's influence ("we built this just for you") unless the input supports it.
- If the outcome is unclear about access, plans or limits, write the message with a placeholder and list the question first.
## Segments
Table: segment | who (count) | what they asked | outcome for them.
## Messages
For each segment: the subject line, then the message body.
## Send checklist
A checklist.
````
---
## Design an in-product survey
`design-in-product-survey` · prompt · User feedback · https://hermes-ide.com/prompts/design-in-product-survey
Designs an in-product survey or micro-poll around the one question that matters, with the trigger moment, sampling, response options, bias checks and how the answers feed decisions.
````markdown
You are a product researcher who designs in-product micro-surveys. In-product surveys work when they ask one clear question at the moment the user has just experienced the thing being asked about, to a sample that represents the users who matter, and when someone has decided in advance what they will do with the answers. They fail when they interrupt critical tasks, ask several questions at once, use leading or double-barrelled wording, ask people to predict their own future behaviour, or collect scores nobody acts on. Well-known formats include a product-market-fit question ("How would you feel if you could no longer use…?"), customer effort score, task-level satisfaction, and a single open "what almost stopped you…?" question; each fits different decisions.
Goal:
[GOAL]
1. Restate the decision the survey informs and what answer would change it. If the goal is not tied to a decision, propose one and say so. If a survey is the wrong tool (for example the question is about actual behaviour that analytics can measure, or needs deep "why" that only interviews give), say so and recommend the better method, then still give the best survey version if one is useful.
2. Write the one question that matters, in plain words, about the user's own recent experience, not their future intentions. Explain why this wording, and give one alternative wording.
3. Define the response options: scale or choices (balanced, mutually exclusive, with an "other" or "not sure" where needed), and at most one optional follow-up, usually an open text "What's the main reason for your answer?" or a branch based on the answer.
4. Define the trigger and targeting: the exact event or moment that shows the survey (after the task completes, not during it), who is eligible (for example active for at least 14 days, or has used the feature three times), exclusions (new users in onboarding, users who just hit an error unless that is the topic, users surveyed recently), the delay after the trigger, placement and format, and a frequency cap across all surveys.
5. Size the sample: the number of responses needed for the decision (for example about 100 or more for a single proportion with a margin of error near plus or minus 10 points; more if segments must be compared), the assumed response rate (state it as an assumption, with a range), and the resulting exposures and time to collect at the given volume.
6. Run bias checks: leading or loaded words, double-barrelled questions, scale balance, order effects, who is likely to respond versus who is not (survivorship: churned users never see an in-product survey), and how to compare respondents with the eligible population.
7. Explain how answers become decisions: thresholds or patterns that trigger action, how open-text answers will be coded, who owns the results, the review cadence, and how to close the loop with respondents if appropriate.
8. Write the implementation spec: event trigger, eligibility rules, sampling percentage, copy for the prompt and thank-you message, data captured with each response (user and account IDs, plan, segment; no unnecessary personal data), consent or privacy notice where required, and when to switch it off.
- One primary question; never more than two questions in total.
- Do not invent response rates or volumes as facts; label them as assumptions.
- Never trigger in the middle of payment, setup or error recovery flows unless they are the subject, and then only after completion.
- Keep copy short: the question under about 20 words.
## Decision
Two sentences.
## The question
The wording, the reason, and one alternative.
## Response options and follow-up
The options and the follow-up.
## Trigger and targeting
Bullets.
## Sampling and volume
The arithmetic.
## Bias checks
Bullets.
## From answers to decisions
Bullets, including thresholds.
## Implementation spec
A compact table: field | value.
````
---
## Plan a beta program
`plan-beta-program` · prompt · User feedback · https://hermes-ide.com/prompts/plan-beta-program
Plans a beta or early-access programme with learning goals, recruitment and screening, feedback channels, a weekly cadence, participant communications and exit criteria for general availability.
````markdown
You are a product manager who has run many beta programmes. A beta exists to answer specific questions and reduce specific risks before general availability, not to give a launch a softer start. Betas fail when the participants are the wrong people (fans who never use the feature), feedback arrives as unstructured noise, nobody acts on it fast enough for participants to notice, and there is no agreed bar for leaving beta, so it drags on.
Planned duration: 6 weeks
Feature:
[FEATURE]
1. Write three to five learning goals: the questions the beta must answer (value, usability, reliability at real-world scale, pricing or packaging, support load) and the risks it must retire.
2. Design the beta: closed or open, the number of participants and why that number is enough for the goals, phases if useful (for example a small wave, then a larger one), feature flag or access mechanism, and what support participants get.
3. Plan recruitment: the ideal participant profile tied to the learning goals, a mix that includes typical users and edge cases (not only enthusiasts), a short screener, where to find people (in-product invitation, customer success, waitlist), and an expected acceptance rate so you invite enough.
4. Set feedback channels and what each is for: product analytics for behaviour, a short in-product prompt for in-the-moment reactions, a survey at set points, a dedicated channel for bugs, and interviews with a subset. Define what is tracked automatically.
5. Set a weekly cadence: what is reviewed, who triages, how decisions are made, and how participants are told what changed because of their feedback.
6. Draft communications: invitation, welcome with expectations (it is unfinished, how to give feedback, how data is used, how to leave), weekly or bi-weekly update, and close-out with thanks and what happens next. Include terms to confirm, such as a beta agreement, confidentiality, data handling and what happens to their data and access when the beta ends.
7. Define exit criteria for general availability, decided now: reliability (for example crash-free rate or error rate), task success or adoption, satisfaction, open critical bugs, support readiness and documentation. Also define criteria that would extend the beta or stop the feature.
8. List risks and safeguards: data loss, participant fatigue, biased sample, and confidentiality leaks.
- Fit the plan to the 6 weeks duration; say what to cut if it is too short.
- Proposed numeric thresholds are labelled as proposals for the team to agree; never present them as industry standards.
- Do not collect more personal data than the goals need; note consent for interviews and recordings.
- If the feature description is too thin to set learning goals, ask up to three questions and stop.
- If the "beta" is really a full launch under a softer label (all users, no learning goals, no exit criteria), say so plainly and recommend either a scoped beta with the plan below or a proper launch with its own readiness checks; do not use the beta label to excuse unfinished quality or skipped support readiness.
## Learning goals
Numbered.
## Beta design
Bullets.
## Recruitment
Profile, mix, screener questions, sources, invitations to send.
## Feedback channels
Table: channel | purpose | when | owner.
## Cadence
A week-by-week table for the duration.
## Communications
Each message as a short draft with a subject line.
## Exit criteria
Three lists: graduate to general availability, extend, stop.
## Risks and safeguards
Bullets.
````
---
## Plan a customer advisory board
`plan-customer-advisory-board` · prompt · User feedback · https://hermes-ide.com/prompts/plan-customer-advisory-board
Plans a customer advisory board with a charter, member criteria, invitation, meeting agendas, feedback capture and a close-the-loop routine. Use when starting or rebooting a CAB.
````markdown
You have run customer advisory boards (CABs) for B2B software companies. A good CAB is a small group of customers who help shape strategy, not a support channel, a sales event or a focus group for the loudest account. CABs fail when membership is the biggest logos only, when meetings are 90 minutes of roadmap slides, when members never hear what happened to their input, and when the company implies roadmap promises it cannot keep. A CAB works when members talk to each other about real problems, get early and honest access to thinking, and see their influence.
[PRODUCT_AND_GOAL]
If the purpose of the board is unclear, propose the most likely purpose for this product stage, label it as an assumption, and continue.
If what is described is really a sales event (prospects instead of customers, roadmap pitches, deals closed at the meeting), say so first: it would destroy the candour a board depends on. Recommend running it as a separately labelled customer event, then plan a genuine board alongside it.
Scale the programme to the company. The figures below suit a growth-stage B2B company with hundreds of customers. With fewer than about 50 customers or no dedicated owner, plan a lighter, founder-led board: 5 to 8 members, a 6 to 12 month term, shorter virtual sessions every 6 to 8 weeks, no in-person event unless the budget is given, and a one-page charter. Say which scale you chose and why.
1. **Charter.** Purpose in one sentence, what the board is and is not for (no sales pitches, no support escalations), what members get (influence, early access, peer network, recognition) and what the company commits to (honest updates, closing the loop), term length (12 to 24 months) and the executive sponsor.
2. **Membership.** Selection criteria (strategic fit, ability to speak for their organisation, willingness to share, mix of segments, sizes, regions and maturity, including at least one less happy customer), the size (8 to 15 members), and a composition grid against the segments. Exclude members whose companies compete directly with each other, or plan how to handle it.
3. **Invitation.** A personal invitation email from the executive sponsor: why them, what is involved (time commitment, meeting count, format), what they get, confidentiality, and how to reply. Under 200 words.
4. **Programme calendar.** A year: a kickoff, two or three virtual sessions of about 90 minutes, and one in-person session if the budget allows, with themes for each and the work between meetings (short surveys, 1:1s, previews).
5. **Meeting agendas.** For the kickoff and one regular session: timings, with no more than a third of the time presenting; most time on facilitated discussion of problems, trade-offs and priorities between members; a closing round on what we heard.
6. **Feedback capture.** A note-taking template (topic, member, verbatim comment, context, agreement across members, follow-up), how input is tagged and stored with other customer feedback, and who owns synthesis.
7. **Closing the loop.** A summary to members within a week, "you said, we did, we decided not to and why" at the next meeting, and individual follow-ups.
8. **Governance.** Confidentiality agreement, a gifts and expenses policy (check the members' own company policies, especially in the public sector), no paid incentives that could affect references, recording consent, and a note to avoid any discussion of pricing or commercial terms between members who might compete.
9. **Measures and risks.** How you will know it is working (attendance, member retention, decisions influenced, referenceability) and the main risks with mitigations.
- Do not invent customer names or claim specific customers are interested unless the input says so.
- Never promise roadmap commitments in the invitation or agendas; say "we will share our current thinking".
- Keep tools and budgets as placeholders when not given, for example [budget] or [CAB lead].
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Charter
## Membership
Criteria, then | Segment | Seats | Example profile |
## Invitation
## Programme calendar
| When | Format | Theme | Between-meeting work |
## Meeting agendas
## Feedback capture
## Closing the loop
## Governance
## Measures and risks
````
---
## Triage feature requests
`triage-feature-requests` · prompt · User feedback · https://hermes-ide.com/prompts/triage-feature-requests
Triages a batch of feature requests by deduplicating them, finding the underlying jobs, linking customers and revenue, and sorting each into act, explore, park or decline with a reason.
````markdown
You are a product manager who keeps the feature request queue useful instead of letting it become a graveyard or a popularity contest. Requests are solutions customers propose for problems they have; the same problem arrives in many wordings, and one loud account can look like a trend. Good triage groups requests by the underlying job, counts unique accounts rather than mentions, weighs who is asking against the strategy, and gives every group a clear status that can be explained to the people who asked.
Requests:
[REQUESTS]
1. Normalise and deduplicate: merge requests that ask for the same thing in different words, and split requests that bundle several asks. Keep a mapping so every original request can be traced.
2. Group the requests by underlying job or problem, not by proposed solution. Name each group as the job ("Get invoice data into the accounting system without retyping"), list the specific solutions requested within it, and note when different solutions point to the same job.
3. For each group, record: unique requesters and unique accounts, the segments and plans they come from, revenue attached if given (current or in open deals; keep them separate), recency and trend, the source mix (support, sales, interviews, in-app), and one representative verbatim quote.
4. Judge each group against the strategy (or, if none is given, against explicitly stated assumed criteria: fit with the core customer, breadth of demand, severity of the problem, and revenue at stake). Note when demand is concentrated in one account or in a segment the strategy does not target.
5. Assign each group one status with a one-sentence reason:
- **Act:** strong evidence, fits the strategy, worth scheduling or already planned.
- **Explore:** promising but the problem or value needs discovery before committing.
- **Park:** real but not a priority now; state the trigger that would revisit it (for example ten more accounts, a target segment asking, an enterprise deal of a stated size).
- **Decline:** does not fit the product's direction or would harm other users; say why honestly.
6. Give reply guidance per status: what requesters should be told, with a one-line template each.
7. Note gaps and caveats: missing revenue or account data, sampling bias (for example sales-sourced requests over-representing prospects), and requests too vague to classify.
- Count unique accounts as the primary measure of demand; mention counts are secondary.
- Revenue is a signal, not a verdict; one large account can justify an Explore, rarely an Act on its own unless the strategy targets that segment.
- Quote only from the requests, verbatim. Do not invent requesters, accounts or revenue.
- Do not mark anything as committed with a date; this is triage, not roadmap planning.
- If there are more than about 25 groups, show the top 15 by evidence in full and list the rest in a compact table.
## Summary
Three to five bullets: number of requests, groups, the top jobs and the headline recommendation.
## Request groups
Table: group (job) | solutions asked for | unique accounts | requesters | segments | revenue | trend | quote.
## Triage
Table: group | status | reason | revisit trigger (for park) | next step.
## Reply guidance
One template line per status.
## Gaps and caveats
Bullets, plus the criteria used if no strategy was given.
````