Support Engineer

Support Engineer

When to Use

• Investigate a customer bug or "it doesn't work" report
• Reproduce issues across environments (browser, API, mobile)
• Analyze logs, request IDs, and HTTP/API error payloads
• Draft technical response with steps, workaround, or ETA
• Escalate to engineering with minimal repro and impact
• Author or update KB articles after resolved issues

When NOT to Use

• Support queue SLAs, CS metrics, renewals, dunning → customer-ops-specialist
• Company-wide outage incident commander role → incident-management-engineer
• Implement product code fixes in repo → fullstack-software-engineer
• Public API reference documentation → tech-writer-researcher
• Security incident or SOC alert investigation → defensive-security-analyst

Related skills

Core Workflows

1. Intake and triage

Capture before deep dive:

• Customer ID, environment (prod/sandbox), region
• Timestamp with timezone
• User role and exact URL or API endpoint
• Error message verbatim; request/correlation ID
• Recent changes (release, config, integration)
• Severity: blocked vs degraded vs question

Route billing/access-only issues to customer-ops-specialist if non-technical.

See `references/ticket_triage.md`.

2. Reproduce

1. Follow customer steps on comparable environment 2. Reduce to minimal repro (fewest steps, clean account if possible) 3. Note deterministic vs intermittent 4. Capture HAR, server logs, or curl with redacted secrets

See `references/reproduction_debugging.md`.

3. Isolate root cause

Document hypothesis and evidence; avoid guessing in customer reply.

4. Resolve or escalate

If known issue: link KB, workaround, linked engineering ticket + ETA.

If new bug: file engineering ticket with:

• Title: [component] short failure description
• Impact: customer count, blocked workflows
• Repro steps, expected vs actual
• Logs/IDs attached

See `references/escalation_engineering.md`.

5. Customer communication

• Acknowledge impact; no blame
• State what is known, unknown, and next update time
• Provide workaround before permanent fix when possible
• After fix: confirm with customer; close loop

See `references/customer_comms.md`.

6. Knowledge base

After fix verified:

• Symptom → cause → resolution → prevention
• Searchable title; tags for product area
• Link to public API doc if applicable

See `references/kb_article.md`.

When to load references

• Priority and intake → references/ticket_triage.md
• Repro and logs → references/reproduction_debugging.md
• Engineering handoff → references/escalation_engineering.md
• Customer updates → references/customer_comms.md
• KB template → references/kb_article.md

Customer communications

Table of contents

1. Update template

Update template

Hi [name],

**Status:** [investigating / workaround available / fix deployed]
**Impact:** [what we understand]
**Workaround:** [steps or "none yet"]
**Next update:** [time]

[Optional technical detail in plain language]

Thanks,
[agent]

Avoid internal ticket numbers unless customer-facing portal shows them.

Engineering escalation

Table of contents

1. Ticket quality bar 2. Severity for engineering

Ticket quality bar

Engineering should not need to ask:

• [ ] Clear repro or explicit "cannot reproduce" with attempts listed
• [ ] Single owner on support side
• [ ] Customer impact quantified
• [ ] Regression yes/no and first seen version/date

Label: customer-reported, repro-confirmed, regression.

Severity for engineering

Match internal engineering severity if different from customer-facing P-level.

Knowledge base article

Table of contents

1. Structure

Structure

# [Symptom as customers search it]

## Symptoms
- Bullet list

## Cause
Brief technical cause (no internal jargon overload)

## Resolution
1. Numbered steps

## Prevention
Optional configuration or upgrade note

## Related
- Links to API docs

Retire or redirect article when product fix makes workaround obsolete.

Reproduction and debugging

Table of contents

1. Repro template 2. Log fields

Repro template

## Environment
- Tenant / account:
- Product version or build:
- Browser or SDK version:

## Steps
1.
2.

## Expected

## Actual

## Attachments
- HAR / curl (secrets redacted)
- Request ID:

Log fields

Collect when available:

• request_id, trace_id, correlation_id
• HTTP status and response body (truncate PII)
• User ID and resource IDs (not passwords or tokens)

Ticket triage

Table of contents

1. Severity 2. First response

Severity

Align with customer-ops-specialist SLA table if company-defined.

First response

Within SLA:

• Confirm receipt and severity
• List info still needed (IDs, screenshots, repro permission)
• Set expectation for next update