Build a Support Ticket Router That Scales
The Scenario You've just joined the engineering team at a growing SaaS company. The support team receives customer tickets from multiple channels — all of them land in a single JSON log file. Right now, support staff are manually reading…
Create a free account to upload your work. Your progress saves as a draft until you submit.
What You'll Be Doing
The Scenario
You've just joined the engineering team at a growing SaaS company. The support team receives customer tickets from multiple channels — all of them land in a single JSON log file. Right now, support staff are manually reading every ticket and deciding where it goes. It's slow, error-prone, and not scaling.
Your tech lead has asked you to build a ticket routing module: a Python script that reads the raw ticket data, assigns each ticket a priority level, routes it to the correct support queue, and outputs the processed results. This is a real, working proof-of-concept — not a diagram or design doc.
Ticket data arrives in this format:
{
"tickets": [
{
"id": "T-1001",
"customer_id": "C-4421",
"customer_tier": "premium",
"subject": "Cannot log in to account",
"description": "Unable to access my account for two days. Urgent.",
"submitted_at": "2026-03-15T09:32:00Z"
},
{
"id": "T-1002",
"customer_id": "C-8810",
"customer_tier": "standard",
"subject": "How do I export a report?",
"description": "I cannot find the export button on the reports page.",
"submitted_at": "2026-03-15T09:45:00Z"
},
{
"id": "T-1003",
"customer_id": "C-2233",
"customer_tier": "standard",
"subject": "Billing question",
"submitted_at": "2026-03-15T10:01:00Z"
}
]
}
Priority Rules
| Priority | Condition |
|---|---|
| HIGH | Ticket is from a customer_tier of "premium" OR the subject or description contains any of these keywords: "urgent", "cannot", "broken", "down", "failed" |
| MEDIUM | All other tickets that have a non-empty description |
| LOW | Tickets with no description (the field is absent or empty) |
Routing Rules
| Priority | Destination Queue |
|---|---|
| HIGH | "urgent-queue" |
| MEDIUM | "standard-queue" |
| LOW | "backlog-queue" |
Expected Output Format
Your script should print (or return) the processed tickets. The exact format is your choice — a list of dicts, a formatted print statement, or JSON — as long as it clearly shows each ticket's id, assigned priority, and destination queue.
How Your Work Will Be Scored
What to Submit
ticket_router.py
Format: .pdf, .doc, .docx, .rtf, .txt, .md
-
Write a Python 3 script that reads ticket data from a JSON file, applies the priority and routing rules above, and outputs the processed result
-
Your script should handle all the edge cases described in Section B of the README — the code itself should reflect your reasoning, not just the README
-
You are writing a working proof-of-concept — it does not need to be production-ready, but it must run correctly
-
Include at least two test inputs in the file (one expected-path case, one edge case) with output shown in comments or a docstring
-
Sign in to upload files
README.md
Format: .pdf, .doc, .docx, .rtf, .txt, .md
-
Section A — Design Decisions (300–500 words): Explain the choices you made in building your solution. What was the hardest part to get right? What trade-offs did you consider? What would you do differently with more time?
- Section B — Edge Case Reasoning (no AI tools): In your own words, explain how your solution handles each of the three edge cases listed below. Do not use an AI assistant for this section — we want to understand how you think about the problem space, not how AI describes it.
The three edge cases you must address in Section B:
| # | Edge Case |
|---|---|
| 1 | A ticket where the description field is entirely absent from the JSON object (not present at all — not just an empty string) |
| 2 | A ticket where the customer_tier value is one your priority rules do not explicitly cover — for example, "enterprise" or "trial" |
| 3 | Two tickets with the same customer_id submitted within 60 seconds of each other — what does your system do, and why? |
Note: Section B must be written without AI assistance. Your code may handle these cases however you choose — what we're evaluating here is your independent reasoning about the problem, not the AI's.
- Section C — AI Usage Log: See the mandatory template below — this section must appear verbatim.
Section C — AI Usage Log (Mandatory)
This is not a trick. We want to see how you work with AI — not whether you used it.
In a short section of your README, document your AI collaboration process. For each significant interaction with an AI tool, briefly note:
- What you asked the AI to help with
- What it gave you
- What you kept, changed, or rejected — and why
Three interactions documented is sufficient. The log does not need to be exhaustive.
Sign in to upload files
Video Walkthrough
Format: .mp4, .mov, .webm
Video Submission Guide
Your video should be 3–5 minutes. Structure it however makes sense to you — but hit these four points:
What to Cover
1. The problem and your solution One to two sentences on what you built.
2. Walk through your script Explain your key design choices — not just what the code does line by line.
3. The mandatory AI question Name a specific moment you redirected AI output.
4. One thing you would do differently with more time Be specific.
Communication note: Speak naturally. We're assessing your thinking process and ideas — not verbal polish. Filler words and pauses are normal and not scored against you.
Sign in to upload files
Create a free account to upload your work. Your progress saves as a draft until you submit.
On this page