Skip to content
Support/prologue

Support is the product

"Why we treat support requests as critical design and code feedback."

Authored by:Haider NadeemHaider Nadeem

Why this exists

Most agencies treat support as cleanup work for junior developers. We treat it as feedback. Every ticket, escalation, and bug report shows where our product failed. If we ignore these signals, the same errors will repeat.

Operational Flow

1

Triage: Classify every support request before writing code.

2

Bug Reporting: Document what broke, how it broke, and why.

3

Escalations: Follow our escalation path when clients get frustrated.

4

Knowledge Base: Save what we learn in Notion so we don't duplicate research.

5

Postmortems: Run blameless reviews for repeated or critical bugs.

What good looks like

  • A client receives a clear status update within two hours of reporting a bug.
  • We document and resolve a bug the first time it occurs, preventing future issues.
  • An engineer who wasn't involved in an incident resolves a similar issue using the runbook.
  • Escalations are handled cleanly without the client needing to find a manager.
  • The internal knowledge base is updated weekly with recent solutions.

What NOT to do

  • Don't treat this handbook as a checklist. Read it as a standard for building reliable software.
  • Don't hide behind process. The rules exist to fix bugs faster, not to justify why they happened.
  • Don't ignore low-priority tickets. Neglected issues erode client trust over time.

Support is where planning meets reality. A design decision from sprint planning becomes a bug report six weeks later. A vague requirement in a scope call becomes a confused client at midnight. This handbook exists because the gap between shipping code and keeping it working is where agency relationships break. This is where Kryft’s reputation is built.

This is not a guide for clearing a ticket queue. The entries detail classification, escalation paths, and postmortems. This prologue defines the underlying standard: support is how we find out what is actually broken. Every complaint is a clue. Every escalation is a measurement. Closing a ticket without updating a runbook or fixing the root issue is only doing half the job.