Customer Says the Feature Is Broken. Support Can't Tell If It's a Bug or a Config Issue.

The customer says bulk export is not working. Support opens a ticket. Is it a bug in the export service? A permissions misconfiguration on the customer's account? A feature flag that's disabled for their org tier? A rate limit that was hit? A deprecated API endpoint the customer is still using? All five of these present as "bulk export is not working." Without access to the codebase and the customer's org config, support has no way to distinguish them. Everything gets escalated to engineering.

This is one of the most expensive categories of support inefficiency: escalations triggered by triage inability rather than problem complexity. The bug scenario requires engineering. The other four require fifteen minutes from customer success, account management, a flag flip from the platform team, or a documentation link. When support can't distinguish them, all five become engineering escalations that often aren't.

Why support can't distinguish bugs from config

The distinction between a bug and a configuration issue is a codebase question. A bug means the code is doing something other than what it's supposed to do. A configuration issue means the code is doing exactly what it's supposed to do, but the configuration for this customer's account doesn't enable the expected behavior. You can only tell the difference by checking the code and the config model — neither of which support has access to.

Feature flags add another layer. A behavior that looks like a bug might be a feature that's intentionally disabled for certain orgs or tiers. The "broken" experience the customer reports is the expected behavior of the flag being off. Without reading the feature flag state for that org, this is indistinguishable from a genuine bug in the feature's code.

"Bulk export is not working" — what it actually might be:

  1. Bug in export-service code
     → Needs: engineering fix, new release
     → Routing: export-service team, P1-P2

  2. Permissions config — org not on correct plan tier
     → Needs: account team update org.permissions.bulk_export = true
     → Routing: customer success, no engineering needed

  3. Rate limit — org hit monthly export quota
     → Needs: quota reset or plan upgrade conversation
     → Routing: account management

  4. Feature flag — bulk export disabled for this org during beta
     → Needs: flag flip by platform team
     → Routing: platform team, 5-minute fix

  5. Customer-side error — they're using a deprecated API endpoint
     → Needs: documentation link to current API
     → Routing: support, no escalation

All five arrive as: "bulk export is not working." Without codebase
access, support can't distinguish them. All five get escalated.

The escalation cost of undifferentiated routing

When every "feature not working" complaint routes to engineering, engineers spend triage time distinguishing bugs from configuration issues. The config-related tickets — permissions, feature flags, rate limits, deprecated APIs — are typically resolved in minutes once they reach the right person, but that person is often not an engineer. By routing everything through engineering, support adds days of queue time to tickets that could be resolved by other teams in minutes.

Support escalates questions to engineering that have codebase answers — the same principle applies here. The question "is this a bug or a config issue?" has a codebase answer. The routing decision that follows doesn't require engineering judgment. It requires knowing what the feature flag state is and what the permissions model looks like for this customer.

The webhook agent that differentiates at intake

Kognita's webhook fires on ticket creation. The managed agent checks the affected service for recent changes (bug signal), checks the feature flag state for the customer's org (flag signal), checks the permissions model for the account tier (config signal), and checks whether the API version in the report matches the current API (deprecated endpoint signal). From these checks, the agent can classify the likely category and route to the correct team.

What the codebase tells a webhook agent about this ticket:
  -> bulk-export-service: no recent changes, last deployed 3 weeks ago (rules out #1 likely)
  -> org-permissions model: bulk_export field exists, defaults to false for standard tier
  -> feature-flags: BULK_EXPORT_BETA=false for this org_id
  -> rate-limits: export quota not implemented yet in current version

  Most likely cause: feature flag or permissions config.
  Agent response: "Bulk export appears disabled for this org (feature flag or
  permissions config). Routing to platform team for flag check. If this is
  intentional, routing to account team to review export permissions."

This doesn't require the agent to diagnose the problem definitively — it requires it to narrow the likely cause and route to the team equipped to resolve it quickly. A ticket likely caused by a feature flag routes to platform for a flag check, not to engineering for a code investigation. The resolution path is appropriate to the likely cause.

The broader impact on engineering queue quality

Teams that filter configuration issues, flag issues, and deprecated API issues from the engineering queue find that the remaining tickets are genuinely complex. The engineers who work the queue deal with actual regressions, reproducible bugs, and edge cases in new features — not with "the feature is off for this customer because the flag is false." The quality of engineering escalation work improves when the noise is filtered.

Final take

"Feature is broken" can mean five different things. Four of them don't require engineering. The one that does is a genuine bug. A webhook-triggered agent that reads the codebase can distinguish these at intake and route each to the team that resolves it fastest — not to engineering by default.

Bug or config? The codebase knows. A webhook agent that reads it at intake routes correctly. Engineering sees bugs. Account teams see config issues. Platform sees flag tickets. Resolution time drops because the right team gets it first.