You can track support requests long before you are big enough for a help-desk platform. What breaks most small teams is not missing software. It is that requests arrive in five places at once — email, a contact form, Instagram DMs, a text message, someone catching you after a call — and nobody can say out loud what is open, who owns it, and what was promised. One spreadsheet, built carefully in an afternoon, closes most of that gap.
Here is the whole system: one row per request, a severity level tied to a response target, a named owner, a resolution note, a root cause tag, and a recovery action. Everything below is how to build it and how to run it without it rotting after three weeks.
Rule One: One Intake Point, One Row, One Owner
Pick a single destination — usually a support alias like help@yourdomain.com — and forward everything into it. DMs get a short reply: Send that to help@ so it does not get lost and I can get you an answer today. That one sentence is the difference between a system and a memory game.
Then the non-negotiable habit: a request is not real until it is a row. Give each one an ID in the format YEAR-NNNN (2026-0147) and use that ID in your reply subject line. Customers will quote it back to you, which saves you searching.
Owner must be a person, not a team. „Support“ owns nothing. If you are a solo operator, you are the owner on every row — write your name anyway, because the column has to survive your first hire.
The Columns You Need to Track Support Requests
Fifteen columns cover almost everything a small business needs. Add nothing else until a real problem forces it.
- Request ID — 2026-0147
- Received — date and time, not just date
- Channel — email, form, DM, phone, in person
- Customer — name and order or invoice number
- Summary — one sentence, in the customer’s words, not your diagnosis
- Severity — S1 to S4 (defined below)
- Owner — a person
- Response due — calculated from severity
- First response at — when a human actually replied
- Status — New, Waiting on us, Waiting on customer, Resolved, Closed
- Resolved at
- Resolution note — what you actually did
- Root cause — one of seven tags
- Recovery action — what you did beyond fixing it
- Follow-up date — when you check back
Add two formula columns. Target met: =IF(FirstResponse<=ResponseDue,“Yes“,“No“). Age in days for anything unresolved: =IF(Status=“Resolved“,““,TODAY()-Received). Conditional formatting on those two is your entire dashboard.
Set Severity and Response Targets Before You Need Them
Severity is not about how upset the customer sounds. It is about what they cannot do.
- S1 — blocked or money is wrong. They paid and cannot access the product, were charged twice, or there is a data or security concern. Respond within one business hour. Update every four business hours until it is closed, even if the update is „still working on it.“
- S2 — partially blocked, workaround exists. One file is corrupted but the rest works. Respond same business day.
- S3 — question or how-to. Respond by end of next business day.
- S4 — feedback or feature request. Acknowledge within three business days. Never promise a delivery date.
Decision rule: when you cannot choose between two levels, take the higher one. Downgrading later costs you nothing. Upgrading after four days of silence costs you the customer.
Set targets you can hit during your worst week, not your best one. A target you miss routinely is worse than a slower target you always meet, because you stop trusting your own sheet.
A Worked Example: The Duplicate Charge
Tuesday, 4:52 p.m. A customer emails: I was charged twice for the same order and the download link says expired.
The row goes in like this. ID 2026-0147. Received Tue 16:52. Channel email. Customer Dana R., order 8842. Summary: charged twice, download link expired. Severity S1 — money is wrong and she is blocked. Owner: you. Response due Wed 09:52 (one business hour from the next morning’s open). Status: Waiting on us.
Wednesday 9:05 a.m. you reply, refund the duplicate, and issue a fresh link. First response Wed 09:05, target met. Resolved at Wed 09:20. Resolution note: Refunded duplicate charge 8842-B, reissued download link valid 30 days.
Now the two columns most people skip. Root cause: checkout — double submit on slow connection. Recovery action: apology email naming the specific failure, link extended to 30 days, personal note that we are fixing the checkout button. Follow-up date: next Wednesday.
Six days later you send two lines confirming the refund landed. That follow-up is the entire difference between a fix and a save.
Root Causes Are Where the Spreadsheet Pays for Itself
Use a short, fixed tag list so the column stays sortable: unclear instructions, product defect, billing or payment, delivery or access, expectation mismatch, third-party outage, human error. Seven options, no free text.
Once a month, sort by root cause and count. Standing rule: any category that produces three or more requests in a month gets a fix with an owner and a due date — not a better reply template. If „unclear instructions“ keeps appearing, the answer is rewriting page four of your onboarding, not replying faster.
This is where a support log turns into a product roadmap. You stop guessing what to improve because your customers already told you, in order, with dates. We cover related operational habits across the Cursiqa blog, but this one column does more work than most reporting setups.
Service Recovery: Fix It, Then Repair the Relationship
Resolving the issue and recovering the customer are two separate jobs. Run recovery in four steps.
- Name the specific failure. „You were charged twice and your link expired“ beats „sorry for any inconvenience.“ Vague apologies read as denial.
- State what you did, past tense. Refunded, reissued, replaced. No conditional language.
- Make them whole, on a ladder. Decide in advance: S3 gets a clear answer and nothing more; S2 gets a fix plus an extension or replacement; S1 gets a fix, a refund where appropriate, and a personal message from the owner.
- Close the loop on a date. Set the follow-up column and actually send it.
One boundary: never promise an outcome you do not control, especially anything about someone’s payment processor, bank timing, or legal position. Describe what you did and what happens next.
The Weekly Twenty-Minute Review
Same slot every week. Work the sheet top to bottom:
- Filter Status = Waiting on us. Anything older than its target gets handled now.
- Filter Waiting on customer. Older than five days — one nudge, then close it.
- Check the Target met column. Any „No“ gets a one-line reason.
- Fill in every blank root cause tag from the week.
- Send every follow-up whose date has passed.
- Pick one root cause to fix and put it on next week’s list.
Be Honest About Where a Spreadsheet Stops
A sheet is genuinely enough for a solo operator or a team of two or three. It stops being enough when any of these are true: you are carrying more than roughly forty open requests at a time, more than three people need to edit it simultaneously, you need threaded message history attached to each row, customers start asking for a status page, or a contract obliges you to prove response times with an audit trail.
The practical trigger: when you spend more time maintaining the log than answering the requests in it, migrate. The work is not wasted — your columns, severity ladder, and root cause tags become the configuration spec for whatever tool you buy, which is why teams who logged manually first set up software in a day instead of a month.
If you would rather start from something already built than design the columns yourself, the Customer Support & Service Recovery Tracker packages this exact workflow as a PDF guide plus an Excel tracker with the severity ladder, response-target formulas, and root cause reporting already wired up. You can also browse the rest of the Cursiqa shop if a different part of your operation is the louder problem right now.