Support and product teams investigating customer-reported issues / support

Issue Investigation

An evidence-backed conclusion in the canonical support thread: verified issue, bounded uncertainty, expected behavior, or not a product defect.

4 stages2 specialist agentsConnection required

The problem

Customer reports are either dismissed too early or turned into engineering work before expected behavior, reproduction, and impact are established.

AI can connect the full conversation, media, product context, and reproduction evidence while keeping task creation outside the investigator's authority.

What you do

  1. Provide the canonical thread and safe media refs.
  2. Answer bounded clarification questions about expected behavior, environment, timing, and impact.
  3. Review the conclusion and decide whether delivery work should be created.

What the agent does

  1. Read the full thread and media before forming a hypothesis.
  2. Separate report, expectation, evidence, reproduction, scope, and uncertainty.
  3. Ask only bounded clarifications, investigate safely, and post the conclusion in the same thread.
  4. Do not create delivery tasks.

When this workflow helps

A reusable method, adapted to the request.

  • A canonical Slack support thread exists and the issue needs diagnosis before delivery work is created.
  • The agent must read the whole support thread, include media/context, and produce a root-cause or bounded-uncertainty conclusion.
  • The operator needs a clear support conclusion before deciding whether to create delivery work.

Before it starts

Connection required

  • A canonical Slack thread with the complete feedback packet
  • Expected versus actual behavior, environment, timing, and impact context
  • Safe access to relevant media or reproduction evidence

What proves it worked

Evidence, not a success claim.

  • Full-thread and media refs
  • Reproduction and impact evidence
  • Same-thread conclusion with uncertainty
  • No task creation by the investigator

Workflow path

The reusable stages of the work.

A real run expands these stages around the request, context, selected tools, approvals, and dependencies.

4 ordered workflow stages
  1. 01

    Read Canonical Thread

    Read the full stored thread and source context before forming hypotheses.

    Passes to next stage
  2. 02

    Clarify Missing Context

    Ask a same-thread clarification only when missing evidence blocks a safe conclusion; otherwise record why clarification was skipped.

    Passes to next stage
  3. 03

    Investigate Issue

    Trace the symptom through project evidence, validate or bound root cause, and identify affected surfaces and delivery direction.

    Passes to next stage
  4. 04

    Post Support Conclusion

    Post the evidence-backed conclusion in the canonical thread and tell the operator that task creation is a separate instructed handoff.

    Verified outcome

Safe stopping and recovery

Useful even when the whole path cannot run.

  • Stop with bounded uncertainty; task creation requires a separate workflow and operator instruction.
  • If evidence or access is missing, state exactly what is unverified and ask the smallest useful question.
  • If a provider reply fails, preserve the conclusion and retry from the stored thread and action receipt.

Documented follow-on work

The next workflow is conditional, not hidden.

Specialists inside this workflow

Clear roles for each part of the job.

Connected work

Built to use the tools you already have.

Slack Bot