IT helpdesk software for teams that run support out of a mailbox

Most Indian IT teams we meet are not replacing a helpdesk. They are replacing support@, a WhatsApp group and someone who remembers things. This is what changes in the first month, what it costs, and what you should deliberately not do yet.

The problem is not the mailbox. It is that nothing is countable.

A shared mailbox works better than people admit. Requests arrive, somebody answers, work gets done. It keeps working right up until the day your manager asks how many requests came in last month, or which ones took longest, or whether the new laptop rollout actually generated the support load everyone predicted. Then you discover that the mailbox has answers but no data, and reconstructing three months of work from threads is a weekend nobody wants.

The second failure comes earlier and hurts more. Two people reply to the same request because there is no way to say "I have this one". Or nobody replies, because each assumed the other had. A mailbox has no concept of ownership, so ownership becomes a social convention, and social conventions fail exactly when the desk is busiest.

The third is silent. Requests that arrive when someone is on leave sit unanswered until the requester chases, and a requester who has to chase concludes that IT is slow — even when the median reply time is twenty minutes. You are judged on the few that fell through, and a mailbox guarantees that some will.

What a ticket actually buys you

A ticket is not paperwork. It is four things a mail thread cannot have: one owner at any moment, a state everyone agrees on, a clock, and a history that survives the person who handled it leaving the company.

Owner means no two people work the same request, and no request has nobody. State means "waiting on the requester" is a real thing the system knows, so your response clock pauses instead of punishing you for someone else's delay. The clock means you can promise something and check whether you kept the promise. And history means that when the same printer fails in March the fix from November is one search away rather than in an ex-colleague's sent items.

• Every request gets a number the requester can quote, and a link they can open.
• Replies by email still work — the requester never has to learn a portal to get help.
• Assignment is explicit, and unassigned tickets are visible rather than invisible.
• The SLA clock stops while you are waiting on the requester and starts again when they reply.
• Everything is searchable across years, including tickets handled by people who have left.

The first month, in the order that works

Teams that succeed with a helpdesk do roughly the same five things, in roughly this order, and teams that struggle usually tried to do all of it at once.

• Week one: point support@ at the desk and change nothing else. Requests become tickets, people keep emailing exactly as they did. Do not announce a portal yet.
• Week two: agree four or five categories, no more. Hardware, access, software, network, other. You can split them later; you cannot easily merge a taxonomy of thirty.
• Week three: set one response target and one resolution target, in business hours, and publish what "business hours" means. One pair of numbers you keep beats five you do not.
• Week four: write the ten articles you are tired of typing. Password reset, VPN setup, printer mapping, new-joiner kit, expense-portal login. Link them in replies.
• Month two: look at the numbers before you change anything else. Volume by category, median time to first reply, the five requesters who raise the most, the five articles nobody reads.

What not to do yet

Almost every helpdesk rollout that stalls, stalls because somebody built the process they will need in three years during week two. A few specific traps:

• Do not build an approval workflow before you know which requests actually need approval.
• Do not create a queue per team until a queue has too much in it to read.
• Do not write a priority matrix with five levels. Two are enough until they are not.
• Do not force people onto a portal in month one. Email intake first, portal when the knowledge base is worth visiting.
• Do not import five years of mailbox history. Import nothing; let the archive stay where it is.

Where Support IT Helpdesk fits

This edition is the service desk and nothing else, deliberately. Tickets, SLAs, a knowledge base, a portal, live chat, reporting and an API, with incidents and service requests — and problems and changes from Growth. If you later need an asset register, employee and vendor records, licences, or onboarding and offboarding, that is what SupportCentral Enterprise is for, and the whole workspace moves across with one encrypted transfer file from Settings → Account data.

Either way the commercial shape is the same: you pay per agent, everyone who raises a request is free and unlimited, the price is in rupees with GST shown, and your data sits on infrastructure in India. There is no per-ticket charge, so nobody on your team is ever incentivised to close a ticket that is not finished.

What it costs a ten-person IT team

Take a company of four hundred employees with six people in IT, four of whom actually answer requests. You buy four agent seats. The other two people get a free requester login like everyone else, and can be added as agents the month they start answering tickets. Nothing about the four hundred employees costs you anything.

That is the whole model, and it is the one place we are stubborn: per-agent pricing with unlimited free requesters is the only arrangement where the tool does not become more expensive the more useful it becomes. See the pricing page for the current numbers — they are printed there rather than here so that one page is always the truth.

Questions