Submit App Feedback and Feature Suggestions
Published · Updated
To submit app feedback, explain the task, problem, impact and outcome you need. Distinguish a bug report from a feature suggestion, provide useful evidence and follow the request through an available channel with a clear reference.
Identify the feedback type and outcome
Start with what you tried to accomplish. Feedback might concern existing behavior, a proposed function or a question about usage. In a service request app, a saved request missing from a list calls for investigation; filtering that list by status is an improvement idea. If you do not know whether behavior is intentional, ask instead of immediately labeling it a defect. This distinction helps the reader identify relevant information and the next step needed to understand the situation rather than treating every message as a request for implementation.
Write a short title describing the action and outcome, followed by a paragraph of context. “Very important” or “The app is bad” does not identify the topic. Explain who is affected and what became impossible or difficult without inventing frequency or impact figures. Keep one connected issue per request when unrelated topics require separate decisions. If several symptoms belong to the same case, connect them in the description while distinguishing confirmed observations from your explanation of their cause. The reader should know which statements are evidence and which remain uncertain.
- Name the task and feedback type.
- Use a descriptive issue title.
- Explain impact without invented estimates.
Make a bug report reproducible
Organize the report into steps, actual outcome and expected outcome. For example: open a saved request, return to the list and observe its absence despite still being able to open it. Include account role, environment, time and time zone where relevant without sharing login credentials. Copy any error message and state whether the behavior repeated or happened once. Identify sample data when used. The reviewer should understand your observation and what needs checking rather than reconstructing steps from a general complaint or guessing the intended result.
Attach a relevant screenshot or short recording after removing keys, tokens and unrelated customer information. An image alone does not explain expectations, so describe the difference. Mention a nearby successful case and what differed without claiming an unproven cause. Do not repeat an action sending a real request or message merely to prepare evidence before checking the previous attempt. If reproduction is unavailable, provide existing observations and mark missing information. A limited, accurate report is more useful than filling its gaps with details you do not actually know.
- Provide steps, actual and expected results.
- State conditions and missing details.
- Review relevant evidence before attaching.
Connect a feature idea to a real need
Explain the problem before the proposed interface. Instead of “Add a button”, describe how the team needs to find pending requests and why the current list makes that difficult. Offer a status filter as an option, not the only acceptable implementation. Name the user, situation and information available during the decision. State what should become easier or clearer. Avoid unsupported claims about doubling productivity or saving a specific number of hours. Describe the interrupted task and the repeated manual step instead, so the team can assess the need.
Give an example and an inspectable outcome: choosing pending shows records in that state, and clearing the filter restores the expected list. Include a useful exception, such as no matching results, with the expected user experience. Describe an existing workaround and why it is insufficient. Do not combine a small suggestion with rebuilding the entire app. Keep additional ideas for separate topics. Distinguish the need that must be addressed from implementation details for which the team can choose a suitable alternative during design and subsequent review.
- Describe the need before the solution.
- Give an example and outcome criterion.
- Separate essentials from negotiable options.
Use an available channel and follow the reference
For feedback about Infera Agent, check the help or feedback channel actually available in your account or on the official page. Do not rely on an unverified address or form. Review the text and attachments, submit through the appropriate option and retain a request reference or copy when available. An acknowledgment is not a commitment to build a feature or a promised fix date. Record precisely what the response confirmed. Answer follow up questions with information connected to the case rather than large collections of unrelated files or project history.
Update the same request with new information, such as better steps, a successful case or a version in which behavior changed. Avoid duplicate reports merely because no immediate response arrived. If a correction is announced, repeat the original case in the available version and record the outcome. Explain remaining differences if expectations are still unmet. Separate a new issue when the task or proposed explanation changes. Useful follow up keeps the conversation understandable and reduces repeated reconstruction, while distinguishing receipt, review and an implemented change that can actually be tested.
- Verify the actual contact channel.
- Keep the reference and confirmed response.
- Follow up with new evidence and tests.
Questions
Should I send an idea or a bug report?
For existing behavior that differs from expectations, provide reproduction steps. For a need requiring a new function, explain the problem and desired result as a suggestion.
What if I do not know the cause?
A final diagnosis is unnecessary. Provide observations, expectations, steps and evidence, distinguishing confirmed facts from explanations you have not tested.
Should I attach the entire project?
Start with evidence relevant to the case. Review attachments, remove unnecessary information and add files when the team explains what it needs and why.
Does acknowledgment mean approval?
No. Record what the response says and add new information to the reference. Test an announced change rather than assuming acceptance or resolution from an acknowledgment.