Feature requests go to the same place as everything else: support@rec.review. There is no separate form and no voting board — a plain email reaches the people who build the product.
What to put in it
The requests that get built are the ones we understand. Four lines is enough:
- What you are trying to do. The job, not the feature. “I need to send the same cut to two clients who must not see each other’s comments” tells us more than “add multi-client sharing”.
- How you do it today. The workaround you have. It usually shows where the real friction is.
- How often it comes up. Once a quarter and twice a day are different products.
- A screenshot, if there is a screen involved. Mark up where the thing should live.
Say if it is blocking work. That changes the order things get built in.
Bugs are not feature requests
If something is broken rather than missing, send it as a bug instead — see Contact support for what to include so it can be reproduced in one round.
Following what shipped
- In the app: open the avatar menu and click What’s new. A dot on the menu marks releases you have not seen.
- On the site: What’s new lists the same releases publicly, so you can point a colleague at a change without sending a screenshot.
Tip: When something you asked for ships, it appears there. Skimming it once a month usually beats asking whether a request went anywhere.