Escalate Feedback to Support

Outcome

You will know when an item belongs with TMXIO support instead of staying in normal product review, and you will be able to escalate it without losing the context your team has already built up. The goal is fewer “what did you try?” round-trips and faster time to resolution on the items that genuinely need platform help.

When to Escalate

The hardest part of escalation is not writing the message; it is deciding whether the item should be escalated at all. Most Lens items belong in product review and stay there. A minority are platform or hosting issues that need TMXIO intervention. The table below covers the most common symptoms and which side of the line they fall on.

Symptom	Keep in product review	Escalate to support
Copy or layout issue on a page.	Yes	No
Visual regression after a content change.	Yes	No
Lens widget is missing on an environment where it should be enabled.	No	Yes, after confirming the install (see Lens settings in TMXIO).
Feedback items are not appearing in TMXIO after submission.	No	Yes, after confirming the environment (see Environment behavior).
Site is intermittently slow or returning errors.	No	Yes; this is a hosting concern, not a feedback concern.
Reviewer cannot reproduce a reported issue.	Yes	No; treat it as a triage decision.
Item involves credential rotation or access changes.	No	Yes.
Item is a feature request.	Yes	No.

Escalation message template

Copy this template into a comment on the Lens item before you escalate. Filling in every field once is faster than answering follow-up questions later.

Site: <site name>
Environment: <production | staging | preview>
Feedback item URL: <link to the Lens item in TMXIO>
Page or route involved: <URL>
Expected behavior: <what the reviewer expected>
Observed behavior: <what actually happened>
What we tried:
  - <step 1>
  - <step 2>
  - <step 3>
Impact: <who is affected and how much>
Approximate timing: <when it started, how often it happens>

Escalating Cleanly

Once you have decided an item needs support, do the escalation in a single pass rather than handing it off and then adding context piece by piece.

1. Confirm environment first. Switch to the same environment the item was submitted against and verify the issue there. Most “support” escalations are environment confusion in disguise; see Environment behavior.

2. Reproduce or document why you cannot. Either reproduce the issue on the environment under review or write down exactly what you tried and what happened. Both are valid; silence is not.

3. Fill in the template above as a comment on the Lens item. Keep it in the same item rather than starting a new thread elsewhere. The Lens item is the source of truth for what your team has done so far.

4. Move the item to escalated. This signals to the rest of the team that the next move is on support, not on them.

5. Track the support case separately. Note the support case identifier in a comment on the Lens item so the two can be linked later.

6. When support responds, update the Lens item. If support resolved it, move the item back through in progress or directly to resolved depending on whether more product-side work is needed.

What to Include in the Escalation

The escalation comment should stand alone. A support engineer reading it for the first time should be able to act without opening other tools.

• The site and environment, named exactly as they appear in TMXIO.
• A direct link to the Lens item.
• The page or route involved.
• A short, factual description of what was expected and what happened.
• The steps your team already tried, in order.
• Approximate timing: when it started, how often it happens, and whether it is still happening.
• Impact: how many users or how many environments are affected.

What Not to Include

• Long chat transcripts or screenshots of unrelated conversations.
• Credentials or secrets in plain text. If credential rotation is part of the request, support will handle the exchange through a secure channel.
• Speculation about root cause without naming it as speculation.

What Success Looks Like

• Support receives enough context to act without asking basic follow-up questions first.
• The Lens item, the support case, and the eventual fix are all linked.
• The triage owner can explain at a glance which items are still waiting on support and which are back in product review.
• Escalation volume stays low because environment confusion is caught before it becomes a case.

Related

Manage a feedback item

Lens status workflow

Environment behavior

Troubleshooting