Your Users Are Already Telling You Where to Focus

Most teams don't have a feedback problem. They have a focus problem.

The feedback is already there. It's sitting in support messages, bug reports, error logs, and the little sighs customers type when something doesn't work. Nobody reads all of it. So decisions get made on the loudest anecdote instead of the whole picture.

Jason Fried posted something last week that inspired us! His post describes Agent Clawdito, an AI agent at 37signals that runs a customer sentiment analysis every week and posts the results to a dedicated Basecamp project. It also keeps a running "What Keeps Happening" table of recurring issues. One report in a blog form that tells humans a story.

Here's how I implemented this idea for Sabi and how you can recreate it in your own app.

A Weekly report beats a dashboard

A dashboard shows you numbers. A weekly report tells a story.

The difference matters. A dashboard says "192 tickets this week." A report says "89 of those tickets are about connectors, customers are patient but confused about calendar syncing, and the same login issue has now shown up three weeks in a row."

Jason's frame helps make this work. The report isn't for engineers. It's for the humans deciding where to focus. That means plain English, real quotes, and a short lists to make it digistable. No charts. No jargon.

The other insight in the automation: it runs on a schedule, whether or not anyone asks for it. A report you have to remember to run isn’t helpful. An automation helps build week over week.

How we implemented this for Sabi

Our customers talk to Sabi all day. Last week alone: about 8,000+ messages from 239 people with 192 feedback tickets filed (89 resolved).

Before

Before, we had data spread out in too many places. A customer support ticket board, Sentry dashboard that tracked all errors and logs, a Supabase database of messages, GitHub PRs, and lots of Slack messages between team members.

Now

Every Sunday, an agent reads through all of it and writes one story from all sources like this:

1. Customer messages. Every conversation from the last 7 days. This is where sentiment actually lives, in the words customers use when they're happy or stuck.
2. Feedback tickets. What was filed, what got fixed, what's been sitting open too long. Status matters: a complaint about something we already shipped a fix for reads very differently than a fresh one.
3. Error logs. Sentry gives concrete stats. Anecdotes get checked against reality. If one customer complains but errors spiked 10x, the logs clarify.
4. What shipped. So the report explains "this was fixed Tuesday" instead of re-flagging solved problems.

• The week in numbers
• overall sentiment with real quotes
• "What Keeps Happening" section for recurring issues
• long-standing tickets that deserve attention
• And short list of suggested actions.

How to recreate this in your app

Your tech stack might not match ours, but you only need three things: your data, an agent that can read it, and a way to automate.

We packaged our whole process as a copy-paste skill, a single markdown file that tells the agent exactly what to read, how to verify claims, and what shape the report takes. You can read it in our repo and adapt it. Here's the skeleton to start from:

# Weekly Product Report ("State of the Customer")

Write one plain-English report covering the last 7 full days.
The audience is humans making product decisions, not engineers.

## Data sources
1. Customer messages from the last 7 days (your messages table or support tool)
2. Feedback tickets: filed, resolved, still open, and their statuses
3. Error logs (Sentry or equivalent): weekly counts, spikes, top issues
4. Changes shipped this week, so fixed problems aren't re-flagged

## Rules
- Dig before you claim: check ticket notes, duplicates, and shipped
  fixes before reporting any problem as current.
- Use real numbers and real (anonymized) customer quotes.
- Note sentiment honestly: warm, neutral, frustrated.

## Report structure
1. The week in numbers
2. Overall sentiment, with quotes
3. What Keeps Happening (recurring issues, with counts)
4. Long-standing open tickets
5. Error-log findings
6. Suggested actions (short, concrete)

## Delivery
Post the report where your team already reads (Slack, Basecamp,
Notion) every week on the same day, automatically.

Adjust for your data sources and set it to run weekly. The first report will be rough but just tweak it until you reach that concrete story.

A few things we'd tell you before you build it:

• Anonymize quotes. The team needs the sentiment, not the sender.
• Make it status-aware. The agent must “dig before you claim” and find what's already fixed. This is the single biggest trust-builder. Otherwise, early drafts re-raised shipped problems.
• Keep it plain. If the report needs a glossary, add a glossary. Ours defines every term a non-engineer might not know.
• Don't skip the schedule. The automation is the product. A great report that runs once is a demo. A decent report that runs every Sunday is an operating system.

Jason's version stores everything in one Basecamp project so there's a running history. We do the same in Slack. Wherever yours lives, keep it in one place. The month-over-month picture could add color to the narrative.

Your customers are already telling you what to build. The only question is whether anyone is listening on a schedule or making sense of it all.

Thanks for reading. If you build one of these, we'd genuinely love to hear how your first report reads.