Skip to main content
Bug reports usually arrive incomplete. The intake layer should preserve the original customer language, add context, and run a repeatable repro checklist before creating engineering work.

​
What It Does

The intake and repro-gathering function:
  • Receives customer reports from support tickets, chat, email, or webhook events
  • Normalizes the customer report into a structured bug intake record
  • Links the bug intake record to the original support conversation
  • Fetches account, product, environment, version, incident, and recent activity context
  • Checks for reproduction steps, expected behavior, actual behavior, impact, logs, screenshots, and affected objects
  • Detects likely duplicates or known incidents
  • Asks customer follow-up questions when required information is missing
  • Passes repro-ready cases to the engineering issue workflow
NeedDuckie component
Receive customer reportsTicketing, messaging, email, or webhook deployment
Normalize and link recordsBug intake workflow
Fetch customer and product contextApp tool, custom tool, or MCP tool
Interpret messy descriptionsAutonomous bug intake agent
Ask missing-context questionsCustomer follow-up workflow or support ticket agent
Track repro completenessCategories and attributes

​
Flow

​
Repro Checklist

Start with a checklist that engineering actually uses.
FieldWhy it matters
Customer impactHelps engineering prioritize severity and urgency.
Affected account or workspaceLets the team inspect the right record.
Product areaRoutes the issue to the right owning team.
EnvironmentCaptures browser, device, app version, region, integration, or API version.
Steps to reproduceTurns a complaint into an actionable bug.
Expected behaviorClarifies what the customer thought should happen.
Actual behaviorStates the failure in observable terms.
FrequencyDistinguishes one-time confusion from reproducible defects.
Logs or errorsGives engineering debugging material.
Screenshot or recordingHelps verify the state quickly.
Known incident matchPrevents duplicate escalation for active incidents.
Duplicate issue matchLinks the customer to existing engineering work when possible.

​
Customer Follow-Up Questions

Ask only for information that changes engineering action. Good follow-up questions are:
  • Specific
  • Short
  • Written in customer-friendly language
  • Tied to one missing field
  • Sent in the original conversation
  • Stored as part of the bug intake state
Example: 
Thanks for reporting this. Could you send the exact steps you took right before the dashboard went blank, plus the browser and device you were using? That will help our engineering team reproduce it.

​
Suggested Intake Contract

{
  "support_ticket_id": "ticket_123",
  "customer": {
    "account_id": "acct_123",
    "segment": "business",
    "support_tier": "priority"
  },
  "bug_report": {
    "product_area": "dashboard",
    "impact": "cannot view project data",
    "expected_behavior": "dashboard loads project metrics",
    "actual_behavior": "dashboard is blank after login",
    "steps_to_reproduce": ["log in", "open dashboard"],
    "environment": {
      "browser": "Chrome",
      "device": "desktop"
    },
    "logs": [],
    "screenshots": [],
    "missing_fields": ["console logs"]
  },
  "links": {
    "original_ticket_url": "https://helpdesk.example/tickets/123",
    "known_incident_url": null,
    "duplicate_issue_url": null
  }
}

​
What to Track

Track categories and attributes from the start:
  • Product area
  • Severity
  • Customer segment
  • Support tier
  • Repro completeness
  • Missing field type
  • Duplicate issue match
  • Known incident match
  • Follow-up question status
  • Time waiting on customer

Creating Deployments

Create the customer-side intake deployment.

App Tools

Use connected tools to read support, CRM, and product context.

Custom Tools

Add internal lookups for logs, product events, or account data.

Attributes

Track severity, completeness, and waiting states.