Feedback.

Submit a bug with a P0–P3 severity label, a reproduction path, and an affected workspace. Staff move it through the pipeline — open → in progress → awaiting verify → resolved — and every transition is visible on the issue page the moment it happens.

Every issue and feature request carries a net vote count. Upvote what you've hit; downvote what sounds like a non-issue. The default sort by votes surfaces the real pain points without staff having to read every thread. Vote counts update live.

Submit a request with a what, a why and examples. Staff move it through considering → planned → building → shipped. The building and shipped banners surface automatically on the detail page — the community sees progress without having to ask.

Every issue and request has a discussion thread. Staff and community replies land in one chronological timeline. Status-change events appear inline — you can see the full history of a fix: when it was triaged, when a fix shipped, when a community member confirmed it closed.

When a fix ships, the issue moves to awaiting-verify and a banner prompts community members to retest. Only after the community confirms does the issue close. This keeps resolved counts honest — a fix isn't claimed until someone outside the team has verified it.

Issues and requests created by askFinz staff default to internal visibility — invisible to the public until explicitly published. Staff can investigate, draft responses and coordinate internally before anything is surfaced. Internal items are hidden from all public views.

Four real-time KPI cards anchor every list view — P0 open count (highlighted red when non-zero), total open, awaiting retest, and resolved fixes shipped. A quick glance tells you the health of the platform without opening a single issue.

When a new issue or request is submitted, the backend hashes the title and app ID combination and rejects near-identical duplicates before they're saved. The submitter is redirected to the existing item to add their vote and context instead.