Current workflow
Show where the work starts, who is involved, and what happens now.
Feature Request
Shape the next improvement
Describe the Workflow, Not Just the Feature
The strongest requests explain what your team is trying to accomplish, what slows the work down today, and what a better outcome should look like.
Friction point
Call out the manual step, missing visibility, or repeated handoff creating delay.
Desired outcome
Explain what should become faster, clearer, safer, or easier to manage.
REQUEST SIGNALWorkflow contextWhat happens today
PRODUCT REVIEWPattern & impactWho it helps and why
NEXT STEPClearer decisionPrioritize with context
Feature request
Give the Product Team Enough Context to Evaluate the Idea
Keep it practical. A short description of the real workflow is more useful than a long list of imagined settings or screens.
Helpful detailIf the request involves an integration, include the tool and the information that needs to move between systems.
Privacy noteDo not include passwords, API keys, private customer data, or other sensitive credentials in the request.
Useful scopeDescribe the smallest useful version of the improvement first. It gives the product team a clearer starting point for understanding the request.
Business contextMention the role or team affected, how often the issue appears, and what currently happens when the workflow breaks or slows down.
How requests are read
A Request Becomes More Useful When the Impact Is Clear
Product feedback is easier to compare when it connects a real operational problem to the people, frequency, and business context around it.
Is the problem repeatable?
Recurring workflow friction usually gives the team more context than a one-off preference.
Who runs into it?
Explain which role or team feels the problem and how often it appears in normal work.
Where does it belong?
Requests are easier to understand when they map naturally to automation, analytics, integrations, control, or monitoring.
What changes if it works?
Focus on the result: fewer manual handoffs, clearer visibility, faster review, or better control.
After you submit
What Happens Next
A feature request is treated as product context, not an instant commitment. The details you share help the team understand the workflow, compare similar needs, and decide whether more discovery is useful.
Clear requests are easier to revisit later because the problem, affected team, and desired outcome stay attached to the idea.
Request capturedYour feedback is collected with the workflow, product area, and outcome context you provide.
Use case reviewedThe idea can be compared against relevant product areas, recurring workflow needs, and the practical impact described in the request.
Follow-up when usefulIf more context would help clarify the use case, the team can use the contact details you submitted to continue the conversation.