Founder Field Note: Our Support Case Study Turned Into Free Queue Cleanup

The polite little case study with a knife under the table

We were hiring a Customer Ops lead at a small SaaS company with the usual startup starter pack: one overwhelmed support manager, three half-owned workflows, and a shared inbox that looked like a raccoon had been given admin access.

The team wanted a “practical” exercise.

Not a theoretical culture fit interview. Not another “tell me about a time you influenced without authority” séance. Something real.

So someone suggested: give finalists a sample support queue and ask them to propose a triage model.

Reasonable, right? A Customer Ops lead should be able to look at messy tickets, spot patterns, and explain how they’d reduce chaos without hiring twelve people and a priest.

Then the exercise grew teeth.

First it was “review 12 anonymized tickets.” Then it became 40. Then we added churn-risk notes, escalation history, macro performance, and a request to “recommend improvements to our current tagging system.” By the time the PDF went out, it was no longer an interview exercise. It was an unpaid take-home assignment wearing a tiny blazer.

The candidate we liked most sent back a thoughtful diagnosis. She found duplicate tags, broken escalation paths, missing SLA definitions, and a weird habit where enterprise customers got faster responses only if they used angry words in the subject line. Elegant system.

In the debrief, somebody actually said:

“Could we use parts of this next week?”

That was the moment the room should have gone quiet. Instead, the room did what rooms do when a candidate’s free work solves an internal problem: it pretended this was signal.

No. It was labor.

Takeaway: “Practical” is not automatically fair

A practical exercise is fair when it tests how you think.

It becomes extractive when it asks you to clean up their real backlog, design their process, write their copy, prioritize their roadmap, or hand them implementation-ready work.

Before you start, ask:

“Is this based on a real current business problem, or a representative sample created for evaluation?”

If they dodge, you learned something useful before spending your Tuesday night doing unpaid ops surgery.

The hidden scorecard was not hidden from the candidate

Our official scorecard had normal things on it:

• Diagnosis quality
• Prioritization
• Customer empathy
• Cross-functional judgment
• Communication clarity

Very adult. Very laminated.

But the hidden interview scorecard was different.

What the team really wanted was:

• Can this person fix the inbox without making us feel bad?
• Can they absorb chaos without asking for headcount?
• Can they build process but not become “too process-oriented”?
• Can they tell Product we’re causing half the tickets without starting a civil war?
• Can they make leadership feel like this was always under control?

That is not a support case study. That is a hostage negotiation with Zendesk screenshots.

The candidate saw it. Strong candidates usually do. They can smell the difference between “show us how you think” and “please solve the thing we have avoided naming for six quarters.”

Her answer was good because she split her work into two lanes:

1. Evaluation lane: what she was willing to provide for the interview.
2. Implementation lane: what would require deeper access, stakeholder interviews, and paid time.

That boundary was not rude. It was senior.

Takeaway: separate diagnosis from implementation

Use this line when the assignment starts looking suspiciously useful:

“I’m happy to show my diagnostic approach and a sample recommendation. I’ll keep implementation details high-level unless this becomes a paid work trial or live working session.”

That sentence does three things:

• Shows confidence.
• Protects your expertise.
• Forces them to admit whether they want assessment or free consulting.

If they punish you for that boundary, congratulations: you found the job’s real onboarding experience.

The “two-hour exercise” math was a crime scene

The recruiter told candidates it should take “about two hours.”

This is recruiter-speak for “someone on the hiring team guessed while eating almonds.”

Here is what the exercise actually required:

• Read the role description again: 10 minutes
• Review the ticket packet: 45 minutes
• Categorize ticket types: 45 minutes
• Identify root causes: 45 minutes
• Build a triage model: 60 minutes
• Draft recommendations: 60 minutes
• Make it presentable: 45 minutes
• Rehearse the presentation: 30 minutes
• Quietly question your life choices: ongoing

That is not two hours. That is five to six hours if you are competent and care about not submitting a napkin with vibes on it.

And because candidates are trying to win, they over-deliver. They add charts. They clean formatting. They make the thing executive-readable. They include a phased rollout. They do the work of someone already hired, except without a laptop, salary, health insurance, or the sacred company hoodie.

Then hiring teams call it “initiative.”

No. It is desperation taxed as professionalism.

Takeaway: time-box the work in writing

Before starting, reply with a scope cap:

“Thanks — I’ll time-box this to two hours as requested. I’ll focus on diagnosis, prioritization, and a sample operating model rather than a complete implementation plan.”

Then actually time-box it.

At the top of your submission, write:

“Prepared within the requested two-hour window; recommendations are directional based on the limited sample provided.”

This protects you from the candidate screening process where everyone secretly compares your capped work against someone else’s unpaid weekend.

The best candidate did not give us the whole machine

The strongest finalist did something I still respect.

She gave us proof, not the keys.

Her deck had three parts:

1. What I noticed

She named patterns in the queue:

• Billing confusion was creating avoidable tickets.
• Escalations lacked severity definitions.
• Support macros solved speed but not resolution quality.
• Product feedback disappeared after tagging.

2. How I would decide

She explained her decision rules:

• Rank work by customer risk, ticket volume, and operational reversibility.
• Fix routing before tooling.
• Define escalation criteria before adding automation.
• Measure resolution quality, not just first-response speed.

3. What I would validate after joining

This was the magic boundary:

• Interview support reps.
• Audit 30 days of tickets.
• Compare churn notes with support contacts.
• Review macro usage against CSAT.
• Align with Product on feedback loops.

She did not write our full macro library. She did not rebuild our tags. She did not hand over a ready-to-ship operating system.

She showed judgment.

That is the game: enough proof to make your competence obvious, not enough free labor to let them use your brain and then send the classic “we went with someone more aligned” email from the HR fog machine.

Takeaway: build proof blocks, not free deliverables

For any unpaid take-home assignment, turn your answer into proof blocks:

• Problem spotted: “The queue lacks severity definitions, causing inconsistent escalation.”
• Action logic: “I’d define severity based on customer impact, revenue risk, and reversibility.”
• Evidence from your past: “In my last role, this reduced urgent misroutes by 32% in one quarter.”
• Boundary: “A full implementation plan would require access to ticket history, team capacity, and customer segments.”

This gives them signal without donating the operating manual.

If you’re preparing to explain those proof blocks in a live interview or AI interview screen, an interview copilot like NoSweatKing can help decode the question and shape the answer in your own voice, especially when the prompt is pretending to be harmless while grading five different things.

The debrief exposed our laziness, not her limits

After her presentation, the team’s comments were revealing.

One person said, “She’s very structured.”

Another said, “Maybe too structured?”

There it was: the startup classic. We had asked someone to bring order to chaos, then got nervous when she brought order to chaos.

Someone else said, “I wonder if she’s a strong culture fit for how scrappy we are.”

Translation: will she tolerate broken systems politely?

This is where candidates get humiliated by fog. You do the work. You diagnose the mess. You communicate clearly. Then the team uses “strong culture fit” as a wet blanket because your competence made their dysfunction visible.

That does not mean you failed.

Sometimes the interview process is a mirror, and companies hate mirrors. They prefer candidates who hold up flattering watercolor portraits titled “You’re Innovating.”

Takeaway: watch what they dislike about your strength

After a take-home or presentation, listen closely to their follow-up questions.

If they ask:

“How would you adapt this with limited resources?”

Good. They are testing judgment.

If they ask:

“How would you handle a team that doesn’t really want process?”

Useful. They are revealing the job.

If they say:

“We’re worried this is too much structure for us.”

That is not a rejection of your skill. That is a disclosure of their operating model.

Your response:

“That makes sense. My approach is to introduce the minimum useful structure, not process for its own sake. In messy environments, I usually start with one shared severity definition and one escalation rule, then measure whether it reduces rework.”

Now you’ve turned “too structured” into an operating philosophy.

How to answer the case without becoming unpaid staff

Here is the candidate-safe version of a real-world case study response.

Use this when they hand you a messy prompt and call it a “quick exercise.”

Start with assumptions

“Based on the limited sample, I’m assuming the goal is to reduce avoidable escalations while protecting high-risk accounts.”

This prevents them from grading you against secret context they never gave you.

Show your triage lens

Use a simple role-evidence map:

Role need	What you’ll show	What you won’t donate
Diagnose messy systems	3-5 patterns you noticed	Full audit of their operation
Prioritize work	Decision criteria	Complete roadmap
Communicate cross-functionally	Sample stakeholder framing	Internal change plan
Improve customer outcomes	Metrics you would track	Finished dashboard/specs

This is how you stay useful without becoming free middleware.

Include one small example

Give one concrete sample, not the whole library.

For example:

“For billing confusion tickets, I’d separate true billing errors from plan-understanding issues. A sample macro could clarify the invoice line item, link to plan definitions, and route repeated confusion to Product Marketing for copy review.”

One sample proves you can do it. Twenty samples proves you can be exploited.

Close with validation steps

“Before implementation, I’d validate this with ticket volume, customer segment impact, agent interviews, and churn correlation.”

That sentence is a boundary with a clipboard.

Takeaway: your answer should have a locked door

A strong case answer says:

• Here is how I think.
• Here is evidence I’ve done this before.
• Here is a sample of the work.
• Here is what I would need before building the full solution.

If your answer has no locked door, some hiring team will walk through it carrying your weekend.

Boundary scripts for the awkward part

You do not need to sound combative. You need to sound like someone who has paid rent before.

When the assignment is too broad

“I’m excited to complete this. To keep the scope aligned, which part matters most for evaluation: diagnosis, prioritization, or implementation detail?”

When they ask for real company-specific strategy

“I can provide a directional approach using the sample provided. A detailed implementation plan would require internal data and would be better handled as a paid work trial.”

When they add extra requests after submission

“Happy to discuss my reasoning in the next round. If you’d like additional analysis beyond the original scope, I’d suggest converting that into a paid working session.”

When they say other candidates completed more

First, elegant red flag. Second, try:

“I understand. I followed the stated time box so the evaluation would reflect the requested scope. I’m happy to go deeper in a structured paid session.”

When you want to decline without burning the bridge

“Given the current scope and unpaid format, I’m going to withdraw from the exercise. I’d be glad to continue with a live discussion of my past work or a smaller representative prompt.”

A company worth joining may negotiate.

A company worth avoiding will act offended that you did not bring your own shovel to dig their basement.

Takeaway: boundaries are part of your signal

Good teams do not fear reasonable boundaries. They respect candidates who can scope work, protect quality, and name constraints.

Bad teams call that “not hungry enough.”

Let them. Hunger is not a compensation plan.

The rule I wish we had used from the start

If I could rewrite that hiring process, I would use one rule:

If the output can be used by the company without hiring the candidate, the candidate should be paid or the exercise should be redesigned.

That would have fixed almost everything.

We could have created a fictional queue. We could have used a live working session with a narrow prompt. We could have paid finalists for deeper analysis. We could have asked candidates to walk through a past support transformation using behavioral interview answers and the STAR interview method instead of baiting them with our actual mess.

But modern hiring loves to confuse access with assessment.

It wants your time, your judgment, your examples, your strategy, your references, your take-home, your fifth-round smile, and then it wants the option to disappear into a vague job rejection like a raccoon into drywall.

You are allowed to participate without surrendering the deed to your brain.

Final takeaway: show the recipe, not the restaurant

For your next take-home:

1. Ask whether the problem is real or representative.
2. Confirm the time box in writing.
3. Separate diagnosis from implementation.
4. Use proof blocks tied to the role.
5. Provide one sample, not the full operating system.
6. State what deeper work would require.
7. Convert extra requests into a paid work trial or live working session.
8. Treat pushback as data about the company.

The goal is not to be difficult.

The goal is to stop confusing dignity with compliance.

You can prove you’re excellent without becoming a free department for a company that has not even decided whether to send you a badge.