The Dashboard Assistant: Ask For It Instead of Clicking For It
An AI assistant built into the qaid dashboard that reads your feedback, drafts quests and edits themes — acting as you, with your role and your permissions.
Most of what you do in the qaid dashboard is a search followed by a decision. Filter the inbox to this week's negative feedback, read six items, archive four, assign one, leave a note on the last. The dashboard assistant is that loop in one sentence: you describe the outcome, it does the searching, and you keep the decision.
There's no setup: no key to mint, no client to configure, no scopes to reason about — it's already signed in as you, on the project you're looking at.
It acts as you, not as a shared robot
This is the part worth understanding before anything else, because it explains every limit further down.
The assistant has no identity of its own. It has no API key, no service account, and no elevated access. Every request it makes is authenticated by your browser session, and every action is checked against your membership of the project you're on — the same two checks the dashboard itself uses. There is no way to ask it to act as someone else: no tool it can call takes a user id, so "do this as the owner" isn't a thing it can decline, it's a thing it cannot express.
Three consequences:
- Your role is its role. If you're a
member, it can triage feedback, edit quest drafts and edit themes — and it cannot publish a quest, publish a quest theme, or change project settings, because those are owner-only. Ask anyway and it tells you which role the action needs and which one you hold. - Your plan is its plan. More precisely, the project owner's plan, which is the same plan that gates every other feature on the project.
- Your projects are its projects. It's scoped to the one project you have open. An id from another project doesn't come back as "forbidden" — it comes back as "not found", so nothing leaks the existence of things you can't see.
Two people in the same project therefore get two different assistants, correctly. Yours can do exactly what you can do.
Where to find it
The assistant lives in the dashboard, alongside your project rather than on a page of its own — open it from any dashboard screen and it already knows where you are. It reads the page you have open, the record you're looking at, and anything you've ticked, and folds all of that into the conversation before you've typed a word.
That's why short requests work. On a feedback item, "archive this" needs no id. In the inbox with nine rows selected, "assign these to me" needs no list. On a quest, "add a question about pricing" needs no name. The context you can see is context it has.
Replies stream in as they're written. When it uses a tool, you get a one-line record of what it did — "Searched feedback (14)", "Archived a feedback item", "Updated the quest draft" — each one a link to the screen where that work landed, so you can check it rather than take its word.
Three things to ask for
"Triage this week's negative feedback"
It searches the inbox filtered to negative items since Monday, reads them, and comes back with what it found — usually a couple of clusters and the outliers. Because the search was filtered, it also ticks those rows in the inbox for you, so the next instruction can be "archive the first group, assign the checkout one to Ada" and it already knows what you mean.
It won't guess at bulk destruction. Archiving is one item at a time and reversible, so it just does it; anything less recoverable gets a question first.
"Make this theme darker and publish it"
On a quest theme, that's two very different actions and the assistant treats them differently. Darkening the theme edits the draft — nothing your visitors see changes. Publishing takes that draft and makes it live, and it happens the moment it happens: every embed already on your pages starts serving the new version on its next load. There's no staging step to catch a mistake.
So it asks first. You get a summary of exactly what publishing would do — which theme, which version number, what's live right now — and nothing is written until you say yes. Say no and the draft is still saved; you've lost nothing but a click.
Thumbs-embed themes are the exception, and it's worth knowing: they aren't versioned. There's no draft and no publish — an edit is live immediately. Treat "make the thumbs theme darker" as a production change, because it is one.
"Build me a 3-question onboarding quest"
It creates the quest as a draft, with the questions, types and options filled in, and hands you the link. Then you look at it. Change the wording, reorder, drop one — either in the editor or by asking. When it's right, you publish.
This is the honest shape of the feature: it's much faster at the first eighty per cent of a quest than you are, and it has no idea what your onboarding actually feels like. Draft-first is what makes that division of labour safe.
Drafts, live versions, and why publishing asks
Quests and quest themes both have two states, and almost every complaint about an AI editing your content dissolves once you know which one is being edited:
| Draft | Live version | |
|---|---|---|
| Who sees it | You, in the dashboard | Every visitor running the embed |
| What edits it | The assistant, freely | Nothing, until you publish |
| When it changes | Immediately | Only on an explicit publish |
The assistant only ever writes the draft. Publishing is a separate, owner-only action that always asks for confirmation, because it's the only thing it can do that a visitor would notice.
If a summary of a quest ever surprises you, check which one you're being told about — the live version is what your visitors are answering, and it can be several edits behind the draft. Ask for the live version specifically and you'll get it.
One asymmetry to keep in mind on rollbacks: to undo a bad quest-theme publish you need the version id that was live, and the quickest way to have it is to have looked before you published. Quests are friendlier — their version history is listable, so "put the previous version back" is a request the assistant can carry out on its own.
Changes appear on the page you're on
When the assistant changes something, the dashboard updates in place. Archive a feedback item and the inbox row goes; edit a quest draft and the editor reloads it; edit a theme and the theme list refreshes. You don't reload, and you don't end up looking at a stale screen that disagrees with what you were just told.
The same works in reverse. Tick rows, change a filter, open a question — it sees that too, which is what makes the conversation feel like it's about the thing in front of you rather than about the database.
Two limits, both deliberate:
- An unfiltered listing doesn't touch your selection. If you've hand-picked four items and then ask a broad question, it won't tick all fifty out from under you.
- There's a ceiling on how fast it can work — a busy read-heavy conversation is capped at 120 requests a minute, writes at 30. You'll only meet this if something has gone in a loop, and it says so plainly rather than stalling.
Troubleshooting
| What you see | What it means | Fix |
|---|---|---|
| "requires a Pro plan" | The assistant is a Pro feature | Upgrade the project; it works immediately |
| "requires the owner role on this project" | You're a member, and this is publish or settings | Ask an owner, or have your role changed |
| "Project not found" on something you can see | The record belongs to a different project | Open that project and ask there — the assistant is scoped to one at a time |
| "Sign in to use the assistant" | Your session expired | Sign in again; the conversation is still there |
| It described a quest you don't recognise | You're being told about the live version, not the draft | Ask for the draft explicitly |
| It says it couldn't do something | The tool failed and reported it rather than pretending | The reason is in the message; read the record back before retrying a write |
| Too many requests | The per-minute ceiling | Wait for the reset, and prefer one broad question to twenty narrow ones |
Two things it will not do, by design. It won't act as another user — no tool accepts an identity. And it won't publish anything without being asked twice: once by you, once by the confirmation.
Pro feature
The dashboard assistant requires a Pro plan. On a free project it's visible but gated, and asking opens the upgrade prompt rather than failing silently. Nothing about your data changes on a downgrade — the assistant simply stops answering until the project is back on Pro.
Next steps
- The platform API — the JSON API underneath all of it, for when you'd rather write the automation yourself.
- Feedback insights — the AI themes the assistant reads when you ask it what people are complaining about.