For the first few months after launching, Stefan and I handled support the way most two-person teams do: whoever saw the email first answered it, and we'd occasionally both answer the same thing, contradict each other, and leave customers confused. One of us was apologizing for the other's answer while the other had already sent a follow-up. It was a mess.
The thing nobody tells you about customer support at a small company is that the problem isn't volume — it's context switching. Getting pulled out of a flow state to answer 'how do I reset my password' at 11am is expensive. Multiply that by 8-10 emails a day and you've basically lost half your coding output. We had to build a system, or we were going to keep shipping slower and slower.
The First Rule: One Inbox, One Owner Per Day
The simplest thing we did that made the biggest difference: we rotate support ownership daily. One person owns the inbox for the day. The other person is off-limits for support. Full stop. No pinging the other to check something, no 'hey can you handle this one', nothing. The person on support handles everything. The person off support is in deep work mode.
This sounds obvious but we resisted it for a while because it felt inefficient — what if the on-support person doesn't know the answer? The answer is: they figure it out, or they document 'I'll follow up tomorrow' and hand it to the other person. Customers are fine waiting 24 hours if you set expectations correctly. They are not fine getting contradicting answers from two different people in two hours.
Rotation doesn't have to be daily. Some teams do weekly. For us, daily works because neither of us wants to spend an entire week in support mode. Figure out what rhythm fits your pace.
Automate the 40% That's Always the Same
After about two months we sat down and looked at every support ticket we'd ever answered. Roughly 40% were the same five questions. Not similar — identical. 'How do I cancel?', 'I didn't get my confirmation email', 'Can I get a refund?', 'Does this work with X framework?', 'How do I update my billing info?'. We were writing these answers from scratch every single time like absolute idiots.
The fix has two parts. First, a proper FAQ that's actually linked to from error states and account pages (not buried in a footer). Second, canned responses. We use plain text files in a shared folder — nothing fancy. Here's roughly what our response template for missed confirmation emails looks like:
// scripts/generate-support-templates.ts
// We auto-populate customer info from our DB when preparing responses
const templates = {
confirmationEmailMissed: (customerName: string, email: string) => `
Hey ${customerName},
Sorry about that — confirmation emails occasionally get caught by spam filters.
A few things to check:
1. Spam/junk folder (search for "noreply@peal.dev")
2. If you use Gmail, check the Promotions tab
3. Make sure ${email} is the address you signed up with
If none of that works, reply here and I'll manually confirm your account — takes me 2 minutes.
— Robert
`.trim(),
refundRequest: (customerName: string, daysSincePurchase: number) => `
Hey ${customerName},
${daysSincePurchase <= 14
? "Totally fine — I've processed your refund and you should see it in 3-5 business days."
: "You're outside our 14-day window, but let me look at your situation specifically."
}
Let me know if you have any other questions.
— Stefan
`.trim(),
};
export { templates };The script part is optional — sometimes we just have the raw text and copy-paste. The point is that answering a support ticket takes 45 seconds now instead of 5 minutes. We still personalize every response slightly, but we're not starting from a blank page.
Log Everything in One Place (Seriously, Everything)
When you're two people, institutional knowledge lives in your heads. That's fine until one of you is sick, on vacation, or just had a terrible night's sleep and can't remember what you told that customer three weeks ago. We learned this the hard way when Stefan promised a customer a feature and I, three days later, told the same customer that feature wasn't on our roadmap. Not a great look.
Now we keep a simple support log. Ours is a Notion database but it could be a spreadsheet, a markdown file, whatever. The fields that matter:
- Date and customer email
- Issue category (billing, bug, feature request, general)
- One-line summary of what they asked
- What we told them / what action we took
- Whether it's resolved or needs follow-up
- Any commitments made (especially feature requests — this one is critical)
The 'commitments made' field saves us constantly. Before answering anything that sounds like a promise, we check if we've said something conflicting to someone else. It takes 20 extra seconds and has saved us from looking incompetent more times than I want to admit.
Set Up Smart Email Routing Before You Need It
We use a shared support@peal.dev inbox routed through Fastmail with some basic filtering. The setup is simple but effective:
// Example: tagging inbound support emails in your app
// so they route correctly before hitting the inbox
// In your contact form handler:
export async function POST(request: Request) {
const body = await request.json();
const { email, subject, message, category } = body;
// Send to your email service with tags
await resend.emails.send({
from: 'noreply@peal.dev',
to: 'support@peal.dev',
subject: `[${category.toUpperCase()}] ${subject}`,
replyTo: email,
text: `
From: ${email}
Category: ${category}
${message}
`.trim(),
tags: [
{ name: 'category', value: category },
{ name: 'source', value: 'contact-form' },
],
});
return Response.json({ success: true });
}
// Category options we use:
// 'billing' -> goes to Stefan (he owns Stripe)
// 'bug' -> goes to Robert (he owns infra)
// 'feature' -> goes to shared log, no reply SLA
// 'general' -> whoever is on support that dayThe category tag means that even when we're both getting pings, the right person gets the context immediately. A billing question hitting Stefan's phone at 9am is fine. The same question bouncing around waiting for the right person to claim it is annoying for everyone.
We also have one rule about response time SLAs: bugs get a reply within 4 hours during business days. Everything else gets 24 hours. We put this in our FAQ so customers know what to expect. Under-promising and over-delivering on support response time is a cheap way to seem more professional than you are.
When a Customer Is Actually Just Mad
This happens. Someone has a bad day and your product is a convenient target. Or something genuinely broke for them at the worst possible moment and they're venting. Our policy: never respond to an angry email immediately. Write the response, let it sit for an hour, then send it. We've caught ourselves being defensive or sarcastic more than once in that buffer period.
For legitimately angry customers, this template framing works almost every time: acknowledge the frustration first, take responsibility second, explain what happened third, offer a specific fix fourth. Most people calm down the moment they feel heard. The ones who don't calm down after you've been genuinely helpful — there's not much you can do, and that's okay.
Refunding someone who's furious and gives you a 1-star review is almost always worth it. Fighting a $29 refund to 'set a precedent' costs you more in mental energy than the $29. We've done both. Refund them.
Turn Support Into Product Intelligence
Here's the part most small teams skip: support tickets are the best product feedback you'll ever get, because they're unsolicited. Nobody fills out a support ticket to be helpful — they fill it out because something genuinely confused or frustrated them. That's gold.
Every week we spend 15 minutes going through the support log and tagging anything that's actually a product issue versus a user error. Three tickets about the same confusing UI flow? That's a design bug, not a user problem. We add it to the backlog. One ticket about a feature nobody else has asked for? It goes on a list we review monthly — if it stays lonely, it stays off the roadmap.
Some of the best improvements to our peal.dev templates have come directly from support tickets. A customer couldn't figure out how to configure the email templates. That turned into better inline comments in the code and a configuration guide. Another customer kept asking about multi-provider auth. That became a feature we shipped two months later. Support is a listening channel if you treat it that way.
The Tools We Actually Use (Nothing Fancy)
- Fastmail shared inbox — cheap, reliable, works with custom domains
- Notion for the support log — a spreadsheet works just as well
- Loom for complex explanations — sometimes a 90-second screen recording beats three paragraphs of text
- A shared folder of canned responses — plain .txt files, nothing more
- Resend for transactional emails so we get delivery receipts when something goes wrong
We've tried fancier tools. We used Intercom for about three months. It's great software but it was overkill for our volume and it was training us to think we needed more process than we did. When you're two people handling 20-30 tickets a week, a shared inbox and a Notion page beat any ticketing system because the ticketing system becomes something else to maintain.
The point we keep coming back to: don't add tooling to solve a people/process problem. Most support chaos at small companies isn't a tooling problem — it's a 'who owns this and what did we promise' problem. Fix that first.
If you're building on our Next.js templates from peal.dev, the contact form and email routing patterns above are already baked in — you just need to hook them up to your inbox. Saves you the afternoon of figuring out the right Resend setup.
The system we have now isn't perfect. There are still weeks where something slips through the rotation, or we both miss an email because each of us thought the other handled it. But those are exceptions now instead of the norm. The inbox is something we check twice a day, not something that follows us around like a haunted spreadsheet. That alone is worth whatever it took to get here.