6 Lesser Known Helpdesk Ticketing Features Everyone Loves
We track feature usage. And as it turns out, along with the "core" helpdesk functions, like tight email integration (creates tickets from incoming emails), or "single sign-on" (authenticates users against the company's existing accounts), here's some lesser known but VERY productive help desk features our customers love:
How we migrated a 1TB database from Win to Linux with no downtime
Our helpdesk app, both the SaaS and the self-hosted version - is powered by SQL Server. The SaaS version additionally uses S3 (to store file-attachments), Redis (to persist in-memory cache between deploys and restarts) and other fancy cloud stuff, but there's still one big ass SQL Server database at the heart of it.
And this Christmas we've migrated it to Linux.
SLA's are sadly uncommon in the SaaS space
After the recent Facebook outage I got curious how many SaaS B2B products have an actual SLA - a Service Level Agreement with a legally binding uptime commitment. Turns out SLA's are very uncommon in the SaaS space. Here's a little comparison table I compiled, just for illustration purpose.
Amazon vs. the rest of the FAANG
About eight years ago someone hacked into our AWS account and launched hundreds of GPU virtual machines for cryptomining. Our monthly bill went from the regular $200 to over $50k overnight. We did not have a paid "support" plan, we were not a VIP client (on the contrary, we were two scared kids trying to grow our little SaaS). But one phone call - and the problem was solved in 10 minutes.
How Can You Support Your Agents in 2021?
Behind every successful help desk are agents who make them run.
You rely on your agents to help form the impression that customers or users get of your service, to provide genuine help when people need it and to gather and pass on valuable feedback that will help your company move forward successfully.
Best Practices for Tickets with no Customer Response
How should a support agent deal with unresponsive users - who create tickets and then don't respond? ITIL tells us an incident should only be closed by the user who created it. Otherwise the ticket should be put "on hold". But in reality... There's only so much you can do: