Resolve unanswered questions

Why this page is the most useful one

Every question that goes unanswered, whether by the system itself or by a thumbs-down from a user, lands in a queue your admins can review. That queue is also your documentation backlog.

That single sentence is the most important thing about Muninnbase. Every other AI tool guesses when it doesn't know. Muninnbase keeps a list, and you can work the list. The unanswered events page at /admin/qa-log/unanswered is where that list lives, and this article is the workflow that makes the claim real.

What lands here, and why two sources

Two kinds of events show up in the queue, side by side, with different badges:

No answer. The system told the user "I don't have an answer to that in the available documents." Retrieval returned nothing relevant, so no answer was generated. This signal means a document is missing. The answer isn't anywhere in the library yet.

Feedback. A user thumbed an answer down. The system returned something, but the user told you it was wrong, incomplete, or out of date. This signal means a document is there but the answer it produced isn't good enough.

The two failure modes need different fixes. No-answer events usually mean uploading something new. Feedback events usually mean updating something that exists.

The queue itself

The default filter is Open, sorted by most recent. You can also filter by source (No answer / Feedback / All) to focus on one failure mode at a time, which is useful when you're doing a sweep with a specific kind of fix in mind.

When the open queue is empty, the page reads "No open gaps. Every question employees have asked has been resolved or ignored." That's the goal state. Most weeks it's aspirational, but the queue does drain when you work it.

Screen capture coming

From /admin/qa-log/unanswered, capture clicking Review on an open event, reading the question and the original answer, picking Resolved from the status dropdown, typing a one-line note ("Added new PTO policy section to handbook v3"), clicking Save, and watching the history entry appear in the panel below.

The three resolution states

Three states, and every event ends in one of them:

Open. The default. Needs your attention.

Resolved. You fixed the underlying gap. Added a doc, clarified a section, updated a policy. The next time someone asks this question, the answer should be there.

Ignored. The question is not a real gap. A typo, a joke, something employees shouldn't be asking the system in the first place. Ignored events stay in the history so you can see the pattern, but they're out of the active queue.

All three are valid endpoints. The point is that every event reaches one of them. Open events left to pile up unattended is the failure mode this page is designed to prevent.

Re-opening

If you marked something Resolved and later realize the fix didn't actually land (maybe the new document still doesn't have the section you thought, maybe a user thumbed it down again the next day), set the status back to Open from the dropdown and save. The history row records the change with a timestamp, so the audit trail stays honest.

Notes that future you will thank present you for

When you resolve, add a one-line note explaining what you did. Which document you updated, which section you added, who you talked to. The note shows in the history panel under the event, and it is what makes the queue self-documenting six months later.

"Resolved" with no note is a dead end. "Resolved. Added Section 4.2 of Handbook v3" is a paper trail. The first one feels efficient in the moment and looks like a mystery the next time you (or the next admin) come back to verify the fix held up.

A weekly rhythm that works

Twenty minutes on Monday morning. Filter to Open, work top to bottom. Resolve what you can resolve, ignore what's not real, leave the genuinely hard ones flagged for the Tuesday meeting with whoever owns the underlying policy.

Most small businesses find that the queue stabilizes after the first month. The questions that keep showing up week after week are the ones your documentation actually needs to address. The transient ones drop off on their own as employees rephrase or move on.

Why this matters

Each resolved gap is one fewer recurring interruption to a senior employee. The dental hygienist stops asking the office manager how to log a sick day because the handbook now actually explains it. The new framer stops asking the foreman where to find the safety form because the IT runbook now links to it. Multiply by your headcount and a year, and it's hours.

The queue is the difference between a knowledge base that gets better and one that doesn't.

What to do next

Use the Q&A log to spot patterns before they become repeated thumbs-downs. When you're ready to think about plans and billing, plans, pricing, and your free trial covers the picture.

Related