Use Your Co-Pilot to find support answers and recover from no matches

Your Co-Pilot helps you search support knowledge and customer history from inside Supportbench. Start with a specific question, read the cited evidence, and use the underlying case or article to verify the answer. When it returns no matches, the next step is to check the wording, selected mode, record access and available knowledge—not to assume the feature or answer does not exist.

Open Co-Pilot and ask a useful first question  ·  Give the question enough operational context  ·  Keep follow-up questions connected to the task  ·  Check the evidence before acting  ·  Work through “No authorized Supportbench matches were found”  ·  Example: understand a recurring customer issue  ·  How the knowledge team should fix a weak answer  ·  A practical team acceptance check

Open Co-Pilot and ask a useful first question

1. Select Your Co-Pilot, the sparkle control in the agent header. It is separate from the normal Search Supportbench control.
2. Choose Global Search when you want to find documentation or broader authorized support context. Use Recent Cases when your question concerns that case-focused scope; it is not a complete historical account report.
3. Name the product or feature, what you want to do, and the relevant situation. For example: “How do I connect Supportbench MCP to Codex CLI on Windows? I have never used a terminal.”
4. Read the response and open the article or case links. Confirm that they support the answer and match your product, customer and permissions.
5. If a step is unclear, ask a self-contained follow-up: “For Supportbench MCP setup in Codex on Windows, where do I type the command and what should happen after I press Enter?”

Co-Pilot uses available authorized evidence. A no-match response is not proof that a colleague cannot access the record, that no article exists, or that the product lacks the feature. If the control is absent, ask an administrator to check the account’s available AI capabilities and your role.

Give the question enough operational context

You do not have to use technical wording perfectly. Include the words the customer used and, where known, the feature label or exact error. If the answer uses a term you do not understand, ask for that term to be explained in the same product context.

Keep follow-up questions connected to the task

Co-Pilot retains conversation context on the current loaded page, but a new question can still lead to a new search. Closing and reopening the panel on the same page can preserve the exchange; refreshing the browser starts a new conversation. Do not rely on the panel as the durable record of a customer decision.

For a short follow-up, name the thing you mean. “What about running the CLI command for that MCP setup?” is clearer than “How do I run it?” If the assistant returns unrelated results, repeat the product, feature and intended outcome in one sentence. This helps isolate a search problem; it does not replace improving the underlying documentation.

Check the evidence before acting

1. Confirm the cited record is the intended company, contact, asset, case or article. A similar name can be a different entity.
2. Open the source and review its current state. A brief answer may omit prerequisites, an audience restriction or an important exception.
3. Separate recorded facts from the assistant’s proposed interpretation. Ask which activity supports a claimed commitment or cause.
4. For longer histories, ask for the relevant earlier activities. Do not interpret a compact recent-history result as an exhaustive review.
5. Before sending a customer reply, confirm recipients, product applicability, promised dates and private information. Use the normal case workflow to record the actual update.

A good answer can say that information is missing. If the next update time was never recorded, the useful action is to agree and record it—not to invent a plausible deadline.

Work through “No authorized Supportbench matches were found”

1. Check the mode. Use Global Search for a knowledge how-to question.
2. Retry with a short self-contained phrase including the feature: for example, Supportbench MCP Codex CLI. If you know the case or article ID, try that exact ID.
3. Use the normal Knowledge base workspace to search the feature or browse its topic. If you know the canonical article link, open it directly.
4. If the record cannot be opened normally, have the owner review access, publication and audience. Do not copy restricted information into a public location as a workaround.
5. If the article opens but Co-Pilot does not find it, capture the question, mode, article ID/link, role and outcome for the knowledge team. Human visibility and AI eligibility/indexing require separate checks.
6. If the article is found but does not explain the task, flag the exact missing step or scenario. “Explain how to open a terminal before the command” is actionable feedback.

Keep the failing query as a test case. After an update, repeat it and its follow-up. Successfully opening an article by ID does not prove that a beginner’s natural question will retrieve it.

Example: understand a recurring customer issue

Two contacts at the same manufacturer report equipment restarts. One mentions a firmware update; the other describes an interrupted overnight job. Begin with the exact company and relevant case IDs, then ask Co-Pilot to summarize the recorded symptoms, affected items, attempted fixes and unresolved differences.

Open the evidence before treating the cases as one incident. Similar symptoms may have different causes, and each contact may have a separate update commitment. Search knowledge using the equipment family, error and version once those facts are established. If a reviewed article applies, use its verification steps and retain the case-specific outcome in the case.

The operational benefit is a better shared starting point for the investigation. Co-Pilot does not replace deciding who owns the next action, confirming the customer’s business impact, or using the appropriate task/escalation workflow.

How the knowledge team should fix a weak answer

Investigate the failure before changing content. An inaccessible article needs an audience/eligibility review; an article that lacks the procedure needs better instructions; a follow-up that loses context needs a retrieval investigation as well. Keep those outcomes separate.

1. Write the task using the reader’s language in the title and summary. Include the prerequisites a new operator actually needs.
2. Keep the answer’s essential procedure near the beginning of a focused article, followed by explanations, alternate situations and recovery steps. Link it from the broader feature guide.
3. Add specific Search keywords for legitimate alternate phrases, such as “how do I run a CLI command” for the Codex terminal procedure. Keywords must describe content actually present.
4. Preserve the intended audience and review the current article’s AI eligibility through supported administration. Do not broaden access just to obtain a match.
5. Test the original question, an alternate phrase, an exact-ID lookup, and the follow-up as the intended role. Open the cited source and check whether its steps can actually be followed.

Long guides teach concepts and operational judgment; focused procedures make particular tasks easier to retrieve and complete. Both should contain enough detail to be useful without requiring the reader to infer missing steps.

A practical team acceptance check

Continue learning

• Connect external AI clients with Supportbench MCP
• Find and assess knowledge articles
• Flag missing or incorrect instructions
• Maintain knowledge through KCS
• Review company and contact context