Support requests inbox
The admin view of the Help Center's four request forms — where submissions land, what the statuses mean, and how to answer, triage and clear the queue.
Last updated 2026-08-11
Summary#
Support Requests in the admin console is the inbox for the Help Center's Contact & requests forms at /help/support/ — bug reports, feature requests, customer support messages, and SEO specialist consultation requests. Every submission is stored in the support_requests table in D1 the moment the visitor sends it, and relayed to hello@metricvaultai.com as a courtesy copy. This screen is the authoritative queue: it shows each request with the details its form collected, moves it through New → In progress → Resolved, opens a prefilled email reply, exports the queue as CSV, and deletes what should not be kept.
Purpose#
Before this screen existed, form-shaped requests either arrived as unstructured email or not at all. Storing them first and emailing second means a failed email cannot lose a request, and a queue with statuses means two admins do not answer the same message twice. The per-kind fields — a bug report's severity and steps to reproduce, a consultation request's website and timeline — arrive attached to the request instead of having to be asked for in a second reply.
Requirements#
The admin console, signed in as an admin. The section reads the worker's D1 database, so if MONITOR_DB is unreachable the screen reports that it could not load rather than showing an empty queue.
Permissions#
Any active admin — the three /api/admin/support/* endpoints verify the caller's token the same way every other admin route does. There is no owner-only action on this screen; see Getting admin access for how admin roles are granted.
Navigation Path#
Admin console → Support Requests
The sidebar entry carries a badge with the count of requests still in New. The queue also loads with the dashboard, so the badge is current as soon as the console opens.
Step-by-Step Guide#
1. Read the queue#
Each card shows the request type, the sender's name and email, when it arrived, its status, the one-line subject, the message, and whatever extra fields that form collected — severity, where it happened and steps to reproduce for bugs; importance for feature requests; topic for support messages; website and timeline for consultations. The list shows the latest 500 requests, newest first. The four stat cards — total, new, in progress, this week — count the whole table, not the current filter.
2. Filter and search#
The type filter narrows to one of the four forms, the status filter to one of the three statuses, and the search box matches against name, email, subject, message and the extra fields. Filters combine, and they only change what is listed — never the stat cards or the badge.
3. Answer and move the status#
Reply opens your mail client with the recipient, a Re: [type] subject line, and the original message quoted. Sending that mail is not tracked, so set the status yourself: Mark In Progress while you are working on it, Mark Resolved when it is done, Reopen if it comes back. A request leaves the badge count the moment it leaves New.
4. Export or delete#
Export CSV downloads the loaded queue — every request the screen fetched, not just the filtered view — with the extra fields flattened into one details column. Delete removes a request permanently after a confirmation; there is no undo and no archive, so resolve rather than delete anything you might need to reference.
Troubleshooting#
| Symptom | Likely cause | Fix |
|---|---|---|
| "Could not load support requests" | D1 unreachable, or the session token expired | Reload the console and sign in again; if it persists, check MONITOR_DB |
| The badge shows a number but the list looks shorter | A filter is active | Set both filters back to All — the badge counts the whole table |
| A submission a customer swears they sent is missing | The form's bot checks silently drop trap-filled and instant submissions; more than 10 requests per day from one IP are refused | Ask them to resend once, taking at least a few seconds; the same content also went to hello@metricvaultai.com if it was accepted |
| Reply button does nothing | No mail client is configured for mailto: links in that browser | Copy the address and write the reply directly |
| A request is gone and nobody resolved it | Another admin deleted it | Deletion is permanent; agree as a team to resolve instead of delete |
FAQs#
Do these requests appear in Contact Messages or Bug Reports? No. Those two sections read the older Supabase tables fed by the founder contact widget. The Help Center forms write to the worker's D1 table and only appear under Support Requests.
Does replying by email update the status? No. The Reply button only drafts the mail. Statuses change only when someone presses a status button on the card.
Is the customer notified when a status changes? No. Statuses are internal triage state. The customer hears from you when you reply by email.
Why does the queue stop at 500? The list endpoint caps at the latest 500 to keep the screen fast. The stat cards still count everything, so a total above 500 tells you older resolved requests have scrolled out of the list.
Where do the extra fields come from? Each form sends only the fields defined for its type, and the worker drops anything else before storing, so the details column can only contain the documented fields.
See also
Was this article helpful?
Thanks — feedback noted for the docs team.