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 dashboard work is a search followed by a decision. Filter to this week's negative feedback, read six items, archive four, assign one, note the last. The dashboard assistant does the searching and leaves you the decision. There is nothing to set up: it is already signed in as you, on the project you have open.
It acts as you
Start here, because it explains every limit further down.
The assistant has no identity of its own: no API key, no service account, no elevated access. Every request goes out on your browser session and every action is checked against your membership of the project you are on, which are the two checks the dashboard already makes. No tool it can call accepts a user id, so "do this as the owner" is not a request it declines. It is one it cannot express.
Your role is its role. As a member it can triage feedback and edit quest and theme drafts. It cannot publish a quest, publish a quest theme, or change project settings, because those are owner-only. Ask anyway and it names the role the action needs and the one you hold.
Your plan is its plan, meaning the project owner's plan, which gates every other feature on the project too.
Your projects are its projects. It sees the one you have open. An id from another project comes back as "not found" rather than "forbidden", so nothing leaks the existence of what you cannot see.
Two people in one project get two different assistants, which is correct. Yours does exactly what you can do.
Where to find it
The assistant has no page of its own. Open it anywhere in the dashboard and it already knows the page you are on, the record in front of you, and anything you have ticked.
Which is why short requests work. "Archive this" needs no id, "assign these to me" needs no list, and "add a question about pricing" needs no quest name.
Replies stream as they are written, and each tool call leaves a one-line record: "Searched feedback (14)", "Archived a feedback item". Every line links to the screen where that work landed, so you can go and look rather than take its word.
Three things to ask it
"Triage this week's negative feedback"
The assistant filters the inbox to negative items since Monday, reads them, and reports back with a couple of clusters and the outliers. A filtered search also ticks those rows for you, so the next instruction can be "archive the first group, assign the checkout one to Ada".
It will not guess at bulk destruction. Archiving is reversible, so it goes ahead. Anything less recoverable gets a question first.
"Make this theme darker and publish it"
Those are two different actions on a quest theme. Darkening edits the draft, so nothing a visitor sees changes. Publishing makes it live at once, and every embed on your pages picks it up on the next load. No staging step stands between you and a mistake.
So it asks first, summarising what publishing would do and what is live right now. Nothing is written until you agree, and refusing still keeps the draft.
Thumbs-embed themes are the exception. They are not versioned, so there is no draft and no publish, and an edit is live at once. "Make the thumbs theme darker" is a production change.
"Build me a 3-question onboarding quest"
You get a draft quest with the questions filled in and a link to it. Then you read it, change the wording, reorder, drop one, in the editor or by asking. When it is right, you publish.
That is the honest shape of it. The assistant is faster than you at the first eighty per cent of a quest and has no idea what your onboarding feels like.
Drafts and live versions
Quests and quest themes each have two states, and most worry about an AI editing your content goes away once you know which one it touches.
Your draft is visible only in the dashboard, and the assistant edits it freely and immediately. A live version is what every visitor running the embed receives, and nothing changes it until somebody publishes.
So the assistant only writes drafts. Publishing is a separate owner-only action that always asks, because it is the one thing it can do that a visitor would notice.
If a summary of a quest surprises you, check which state you are being told about. The live version is what visitors are answering and it can sit several edits behind the draft. Ask for it by name and you get it.
Rollbacks are uneven. Undoing a bad quest-theme publish needs the version id that was live before, so look before you publish. Quest history is listable, so "put the previous version back" works unaided there.
The page keeps up
When the assistant changes something, the dashboard updates where you are standing. Archive an item and the row goes; edit a quest draft and the editor reloads it. You never reload, and you never read a screen that disagrees with what you were just told.
It works the other way too. Tick rows, change a filter, open a question, and it sees that, which keeps the conversation about the thing in front of you.
Two deliberate limits. An unfiltered listing leaves your selection alone, so a broad question will not tick fifty rows out from under your four. And a ceiling of 120 reads and 30 writes a minute, which you only meet if something has looped.
When it says no
| 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 refusals are by design. It will not act as another user, because no tool accepts an identity. And it will not publish without being asked twice, once by you and once through the confirmation.
What needs Pro
The assistant is a Pro feature. On a free project it is visible but gated, and asking opens the upgrade prompt rather than failing quietly. A downgrade changes nothing about your data; the assistant just stops answering until the project is back on Pro.
Next
The platform API is the JSON API underneath all of this, for when you would rather write the automation yourself. Feedback insights generates the themes the assistant reads when you ask what people are complaining about.