Feedback arrives in a mess
Once an app is live, messages come from several directions: store reviews, an email address, a form in the app, maybe social media. They mix bug reports, questions, praise, complaints and requests for features. Without a routine, the loudest message gets attention and the useful quiet ones get lost. A basic user support routine does not need special software. It needs a single place to collect everything, a few categories, and a regular time to deal with them.
Gather everything in one place
Pick one list, such as a spreadsheet or a simple issue tracker, and copy each message in as one row. Note the date, where it came from, the app version if known, and a one-line summary. Copying is slightly tedious but it means you only have to look in one place, and you can spot repeats.
Store reviews are public, so people can see how you respond. Support email is private. Treat them a little differently, but log both.
Sort into four categories
Most messages fit one of four groups:
- Bugs: something does not work as it should.
- Questions: the app works, but the person cannot find or understand something.
- Requests: an idea for something new or different.
- Concerns: privacy, billing, safety or accessibility issues.
Concerns come first. A message about a charge the person does not recognize, or about data they want removed, deserves a prompt and careful reply. Billing is often handled by the store rather than by you, so the honest answer may be to explain where the person can request a refund or review a purchase. People who suspect unexpected charges are often worried, so a calm and direct answer helps.
Triage bugs by impact and frequency
For bugs, ask two questions: how bad is it, and how many people does it affect? A crash on launch affects everyone it touches severely. A misaligned label on one rare screen is cosmetic. A rough order is:
- Data loss, security or payment problems
- Crashes and features that do not work
- Confusing behavior
- Cosmetic issues
Check your crash reports alongside the messages. A single email describing a crash is easier to take seriously when the reports show it happening to others. If you cannot reproduce a problem, ask for the phone model, operating system version and what the person was doing, and say that you understand if they cannot remember every detail.
Treat questions as design feedback
If the same question arrives three times, the app is probably unclear, not the users. Note it as a candidate for better interface microcopy, a clearer onboarding flow, or a short help page. Answering the person is the first job; reducing the number of future questions is the second.
Handle requests honestly
Feature requests are useful, but they are not promises. Keep them in a list, tally how often each appears, and compare against what you can reasonably build. When you reply, thank the person and avoid committing to a date unless you are sure. Something like “I have added this to my list and cannot promise when” is honest and still kind. Over time, a pattern of requests can inform what to build, though a handful of requests rarely tells you what most users want.
Reply well
Good replies are usually short:
- Say what you understood the problem to be.
- Give the answer or the next step.
- Say what you do not know yet.
- Avoid blaming the person or the phone.
Writing a few templates for common situations saves time, but personalize the first line so it does not read like a form letter. For public reviews, the same tone applies; there is more detail in the article on negative review replies. Not every negative message is about a real problem, and some are simply venting. Responding politely and briefly, without arguing, is usually enough.
Protect privacy when you support people
Users may paste screenshots, account details or personal information into a support message. Ask only for what you need, never ask for passwords, and delete sensitive material once the issue is resolved. If a message includes someone else’s data, handle it with extra care. If you collect support data, your privacy policy should reflect that.
Close the loop
When you fix something a person reported, tell them if you can. A short note saying the issue is fixed in the next version is often appreciated, and it turns a frustrated user into a more patient one. Mention the fix in your release notes too.
A weekly rhythm
For a small app, a regular slot works well:
- Spend 20 to 30 minutes collecting new messages into the list (this duration is only a suggestion; adjust it).
- Reply to concerns and quick questions.
- Tag bugs and decide which to fix this cycle.
- Update the request tally.
If support begins to take more time than you can give, that is useful information. It may mean the app needs better in-app guidance, or that it is time to think honestly about the app’s future.