Case study

A day in the life of a support engineer using Momentum.

A composite picture based on how real support teams use the product. The engineer is fictional — Alex, L2 support at a mid-size SaaS — but every workflow is real.

Setup

Alex is an L2 support engineer at a 150-person SaaS company that sells a data integration platform. The support team has 8 engineers across L1 and L2. They're on Freshdesk for ticketing, and they adopted Momentum six months ago. Today is Tuesday, April 7th. Alex starts their shift at 9am.

9
9:02
Queue check

Alex opens /cases and switches to the kanban view. Eight cases in the "open" lane, three assigned to them overnight. Two look straightforward (login issues); one has the critical flag and the words "data missing" in the title.

They pull up the critical case first. The ticket came in at 3am from an enterprise customer whose sync job has been stale for 14 hours.

9
9:05
Case detail, matched runbooks

As the case loads, Momentum surfaces three matched runbooks on the right rail, ranked by semantic similarity: "Data sync is stuck or delayed" (94% match), "Enterprise sync timeout troubleshooting" (81%), "OAuth token expiration patterns" (76%).

Alex clicks the 94% match. The runbook has six steps. They've done steps 1-4 before on similar cases, but step 5 — "check for the sync-retry-storm pattern in upstream rate limits" — is something they wrote after the last P1.

9
9:09
Reproducing the state

Alex opens the customer's sync job logs. Last successful sync was 14 hours ago. Latest three attempts: 429 from the upstream API. Matches step 5 of the runbook exactly.

Instead of opening a new Momentum note to track the investigation, Alex types into the case's "comment" field. Internal comments land on the case activity timeline, so the work is visible to anyone else who picks it up.

9
9:14
CaseAIde drafts the first response

Alex wants to get the customer informed quickly — the runbook says resolution for this pattern is 2-6 hours depending on upstream behavior. They click the CaseAIde button above the reply area.

They pick tone: Formal (this is an enterprise account) and reply type: First response. Claude streams a draft in 4 seconds: an acknowledgment, the identified root cause (paraphrased from the runbook), and a concrete ETA.

Alex edits two sentences — tightens the ETA language — and sends. Total elapsed since case open: 12 minutes.

9
9:18
Parallel work: the two login cases

While the enterprise case is waiting on the upstream API to recover, Alex picks up the two login cases. Both match the "Customer can't log in" runbook (98% and 91%). Both are 5-minute turnarounds.

One of them has an interesting wrinkle — a 2FA recovery flow the runbook doesn't cover. Alex solves it, closes the case, and clicks Save as runbook on the way out.

Claude drafts a new runbook from the case context: the symptoms the customer described, the 2FA recovery steps Alex walked through, the resolution, a few tags. Alex reviews in 90 seconds, edits the symptoms list to add two more phrasings they expect future customers to use, and saves.

10
10:30
A novel case arrives

A new case comes in from a customer on a legacy plan. The symptoms don't match any runbook cleanly — top match is only 44%. The bug description mentions a behavior Alex has never seen in two years at the company.

Alex spends 20 minutes investigating, confirms it's a real bug, and realizes this is out of scope for L2. Time to escalate to engineering.

10
10:54
Escalation handoff

Alex opens the case's activity timeline and reviews what they've done. The timeline has everything: original report, their comment trail, runbook-lookup attempts, the failed hypothesis.

They write the escalation handoff in the case comment: hypothesis, what's been tried, customer context (enterprise plan, 3-year customer), and the specific engineering team they're routing to. Reassign the case.

The on-call engineer picks it up 8 minutes later with the full context already written down. No ping to Alex for background.

11
11:30
A customer call

Alex has a scheduled call with a customer integrating Momentum's API into their own support workflow. They open /meetings to start recording.

After the 30-minute call, Momentum generates a summary: key customer asks, three action items extracted automatically, meeting prep notes carried forward for the follow-up. Alex forwards the summary to the customer, adds the three action items to their capture inbox for triage later.

13
13:00
Lunch, then queue dive

Back at 1pm. Alex pulls up the enterprise P1 — the upstream API is back online, the sync job has caught up, and the customer has replied thanking them for the clarity.

Alex closes the case with a short resolution note. Presses Save as runbook again — this time reviewing the existing "Data sync is stuck or delayed" runbook and adding the sync-retry-storm pattern as a new symptom entry and step. The runbook was already good; now it's better.

14
14:30
Daily note

Alex takes five minutes for their daily note. Three bullets: the P1 with its resolution, the novel bug escalation, the customer API call action items. This used to be a ritual they skipped on busy days. With Momentum's daily note streaks and capture integration, it's become automatic.

16
16:00
Afternoon triage volunteering

Alex opens the triage queue to help L1. They take two cases from the unassigned queue — both match existing runbooks, both close in 10 minutes. They assign three more to L1 agents with specific runbook suggestions noted in the assignment comment.

17
17:30
Shutdown

Alex checks the daily dashboard before logging off. Cases closed today: 11. Runbook saves: 1 new, 1 updated. Avg time-to-first-response: 4 minutes (vs. 35 minutes pre-Momentum). Time spent on routine login triage: 15 minutes (vs. 90 minutes pre-Momentum).

The shape of the day was different. Six months ago, Alex would have spent half the day switching between Slack, Freshdesk, Confluence, and a scratch Google Doc trying to piece together context. Today, the context was always one click away, the drafting was assisted, and the team's knowledge grew by two runbooks.

The takeaway

The shape of the day is different — not the workload.

Alex still handled 11 cases. They still hit escalations. They still had a customer call and a novel bug. The difference is the friction around each of those activities.

Routine work compressed — login cases took minutes instead of hours. Novel work got clearer escalation paths. Every case added to the team's knowledge instead of evaporating once closed. The next person to see a sync-retry-storm won't spend 90 minutes rediscovering what Alex already figured out.

That's the value of Momentum: not magic, not replacing judgment, but removing the friction between your team's knowledge and the work in front of them.