Add guide for deciding when to involve Engineering

contents/handbook/growth/sales/deciding-when-to-involve-engineering.md

@@ -0,0 +1,53 @@
+# Deciding when to involve Engineering
+
+TAMs and TAEs own the customer problem from start to finish. Sometimes that means solving the problem yourself, and sometimes it means bringing Engineering into the conversation.
+
+This guide helps TAMs and TAEs determine when an issue can be resolved independently and when Engineering should be involved. Following these guidelines helps customers receive faster answers, reduces unnecessary escalations, and ensures Engineering has the context needed to investigate efficiently.
+
+## Before involving Engineering
+
+Before escalating, confirm you've:
+
+- Understood what the customer is trying to accomplish
+- Confirmed the expected behavior and the actual behavior
+- Determined whether this is an implementation issue, product question, or product bug
+- Checked the documentation and known issues
+- Looked for a viable workaround
+- Reproduced the issue, or gathered enough information for someone else to reproduce it
+- Collected SDK version, deployment type, platform, logs, screenshots, and other relevant context
+
+## When should you involve Engineering?
+
+Consider involving Engineering if:
+
+- The issue appears to be a reproducible product bug.
+- A product limitation is blocking a customer's rollout, adoption, or expansion.
+- The issue involves security, privacy, or compliance.
+- The product's behavior appears unexpected or undocumented.
+- You've exhausted the available documentation and are no longer confident in the correct answer.
+- Documentation appears incorrect, incomplete, or out of date.
+
+## Before creating an escalation
+
+Providing good context helps Engineering investigate quickly and reduces back-and-forth.
+
+Include:
+
+- Customer name
+- Customer impact: What are they trying to accomplish? What is blocked?
+- Expected behavior
+- Actual behavior
+- Steps to reproduce
+- SDK version(s)
+- Deployment type: Cloud or self-hosted
+- Relevant screenshots, logs, session links, or error messages
+- Any workarounds you've already tried
+- Customer timeline or urgency, if applicable
+
+## Guiding principle
+
+Engineering should never be the first stop simply because a question is technical.
+
+Your role as a TAM or TAE is to understand the problem, investigate what you can, and involve Engineering when their expertise will meaningfully move the customer forward.
+
+When escalating, explain **why the issue matters**, not just **what the issue is**. Customer impact often provides the context Engineering needs to prioritize and investigate effectively.