Alejandro Melnyk

Alejandro Melnyk is the founder of CaseMargin, a tool that turns long support threads into structured case briefs. He built it after watching agents spend the first few minutes of every reply re-reading conversations they didn't start.

His writing covers the operational side of support: how tickets move between agents, where handoffs lose context, what makes an escalation stick or fall apart, and how much queue time disappears into re-reading. He focuses on the parts of support work that rarely get documented but shape every response time metric on the board.

What he writes about

The through-line across everything here is the handoff — the moment a ticket changes hands and the context does not follow it. That single failure produces most of what support teams experience as unrelated problems: escalations that bounce back for more information, tickets that stall for two days because the person who understood them went on leave, resolution times that will not come down no matter how much the team is trained, and customers who explain their own environment to a fourth agent.

Four subjects come up repeatedly:

• Handoffs and escalations. What a receiving agent or a higher tier actually needs, why negative findings matter more than positive ones, and why an escalation without an explicit ask sits in a queue.
• Documentation that survives contact with a live queue. Not documentation projects — capture that costs close to nothing at the moment the knowledge exists, because anything requiring a later write-up does not get written.
• Where resolution time actually goes. Decomposing the metric into touch time, waiting, queueing, and rework, and being honest that hands-on work is usually the smallest share.
• MSP and managed service desks specifically. Multi-client environments, shift and follow-the-sun handoffs, and the billing-defensibility problem that internal IT teams never have to think about.

How this is written

The articles here are written from operator experience and from building the tooling around this problem, not from secondary research. Where a claim can be checked, it is stated so it can be checked — specific error codes, specific workflows, specific numbers with their assumptions shown. Where something is an estimate or a rule of thumb, it is labelled as one rather than dressed up as data.

There is no attempt to be neutral about CaseMargin: it is the product behind this site and it appears in the articles where it is genuinely the answer. It is not presented as the answer to problems it does not solve, and several pieces here recommend approaches that involve no product at all.