Customer Support
How we handle support at Hardal - who owns it, how we respond, and how we close the loop.
Support is not a separate team's problem. At Hardal, the people who built the product are responsible for the support. That makes us better at both - engineers understand what customers are struggling with, and customers get answers from people who actually know the system.
Support channels
Customers reach us through:
- Email - support@usehardal.com, monitored daily
- Dedicated Slack channels - for customers on Professional and above
- In-app chat - for onboarding and implementation questions
We don't provide support over LinkedIn DMs or Twitter replies. If someone reaches out there with a real issue, point them to the right channel - don't try to solve it over social media.
Support rotation
We rotate support ownership weekly. The on-support engineer is the first point of contact for incoming questions that week. They're expected to:
- Respond to new tickets within the same business day (within 4 hours if urgent)
- Triage issues - distinguish between "customer needs guidance" and "something is actually broken"
- Escalate P0/P1 issues immediately (see Bug Prioritization)
- Close the loop when issues are resolved
Being on support rotation doesn't mean doing nothing else. It means support comes first when something comes in.
How to respond
Respond like a person, not a support ticket.
Don't send template responses to real questions. Read the question, understand what the customer is actually asking, and give them a specific answer.
If you don't know the answer, say so and tell them when you'll have one. Don't leave tickets unanswered while you figure it out.
If the issue is a bug you can fix in an hour, fix it and tell them it's been fixed. Don't open a ticket, assign it, add it to the sprint, and send the customer a status update. Just fix it.
Response time expectations
| Urgency | Expected response |
|---|---|
| P0 - tracking broken, data loss | Within 1 hour, including outside business hours |
| P1 - significant issue, workaround exists | Within 4 business hours |
| General questions | Same business day |
| Feature requests | Acknowledge within 2 business days |
For customers on dedicated Slack channels, be more responsive - they're paying for access.
What support teaches us
The support queue is a direct signal about what's confusing, broken, or missing. Pay attention to patterns:
- If the same setup question comes in three times, the docs are wrong or missing
- If customers keep hitting the same bug, it should be prioritized regardless of its technical severity
- If customers misunderstand what a feature does, the design or copy is unclear
Bring what you learn from support into sprint planning. "Three customers this week couldn't figure out how to configure their consent layer" is a better argument for fixing a UX issue than any amount of internal debate.
Feature requests
When a customer asks for a feature, log it in Linear with the customer's name and context. Don't promise timelines. Do tell them you've logged it and will let them know if it's prioritized.
If the same feature is requested multiple times, it moves up the priority list. Keep track of this - it's valuable signal.
When a customer is angry
Stay calm. Don't get defensive. Understand what happened from their perspective before explaining what happened from yours.
If a customer is angry and right - we messed up something that affected their business - own it directly. "We got this wrong and here's what we're doing to fix it" is more valuable than a polished apology that sidesteps responsibility.
If a customer is angry but wrong (they misconfigured something, misunderstood a limitation), help them fix it without making them feel stupid. They still need to trust us.