Support process design: a shared inbox and a ticket sheet

A customer rings the owner and says they have already complained twice. The owner finds one email in the owner's own inbox, a WhatsApp message on the service engineer's phone, and a voice note that went to accounts. Nobody ignored the customer. Three people each held a third of the case, and each thought another was on it. You fix that with one shared address, one sheet, one name against every case and a date for the next move. No helpdesk is needed to start.

Where one complaint ends up living

Look at where complaints arrive today: the owner's mail, the engineer's WhatsApp, the front desk's phone diary, a courier's remark at the gate. Write those places down. Each is a leak, because the person holding the message may be on a site visit, on leave or simply busy.

The aim is not to stop customers using the channel they like. It is to make sure that whatever channel they use, the case lands in one place within the same working day. The inbox catches mail. The sheet catches everything else, typed in by whoever heard it.

Four rules for the shared address

Set up one address, say support@ on your own domain, and put it on invoices, delivery slips and email signatures. Then agree these on paper.

1. One person owns the inbox itself. They read it first thing and give every new message a name in the sheet. Only they assign. If three people assign, two cases get two owners and one gets none.
2. A second person covers. Name them in advance, before the first leave day clashes with a festival rush.
3. Replies go from the shared address. Replies sent from a personal account leave the history in that account, and it disappears when the person does.
4. Calls and WhatsApp get typed in before the shift ends. If you hear it, you log it.

If you get a few messages a week and one person answers all of them, skip the shared address. The sheet alone is enough.

The sheet, laid out

Ten columns is the limit. Past that, people tend to skip it on a busy day.

No. | Received (date, channel) | Customer + phone | Order or invoice no.
Problem, in the customer's words | Type | Owner | Status | Next contact
Closed on + what fixed it

Keep two columns on fixed lists. Type takes one of: fault, delivery, billing, how-to, other. Status takes one of: new, with owner, waiting on customer, waiting on us, closed. If people may type their own, you will get "pending", "will check" and "done?" within a week, and the column becomes useless for sorting.

The ticket number runs from 1 and is never reused. Put it in the reply subject line so the customer can quote it on the next call. The "closed on and what fixed it" cell is compulsory before a row may be marked closed. Read it after a few months and the repeats show you what to change in the product, the invoice wording or the delivery slip.

One case across a working week

Take an industrial sewing machine dealer in Tiruppur. Illustrative, not a real client. A garment unit writes on Monday that a machine's needle bar is jamming and a production line is idle.

• Monday, 10 am. The coordinator who owns the inbox logs it as ticket 41, type fault, owner the service engineer, and replies from the shared address with the number and the engineer's name.
• Monday, 4 pm. The engineer phones, asks for a photograph and sets status to waiting on customer.
• Tuesday. The photograph shows a worn part. Status moves to waiting on us, because the spare must come from the supplier. The coordinator writes a next-contact date for Thursday.
• Thursday. The part has not come. The date is today, so the row sits at the top of the sorted sheet. The coordinator tells the customer, who can now arrange a temporary machine rather than discover the delay alone.

The dealer's first attempt did not go like this. The status cell held free text, ownership was left blank on most rows, and the inbox was read by the owner between meetings. A similar jam sat as "pending" for nine days, and the customer had to call to find out. They moved inbox duty to the coordinator, locked the status list and coloured any row without an owner red. The delay did not shrink, since parts still took as long, but the customer heard about it on the day.

Closing a ticket without arguments

Close when the customer confirms the problem is gone. If you have asked twice and heard nothing, close it with the note "no reply after two attempts". Do not close because you believe the work is done; a case closed early can return as an angrier message. If the same customer reports the same fault, reopen the old row so the history stays in one place.

For ownership, use a plain rule: whoever can fix it owns it. Billing goes to accounts, a fault to service, a late delivery to dispatch. Unclear? The inbox owner holds it for the day and writes why. The owner also tells the customer what is happening, even when someone else does the work.

Signs the sheet has run out

The sheet strains when you need photographs and call notes attached to most cases, when more than three people work tickets at the same moment, or when you want automatic acknowledgements. It also strains when you cannot say how long cases stay open without counting by hand. Until then, a paid tool may cost more in learning time than it saves.

When the signs appear, choose the tool after you have written down the routine it must follow, not before. For the harder cases that need an apology and a decision, see handling complaints and escalations.

Test the columns on last month's complaints

Before you build anything, enter the complaints you can remember from recent months by hand. Whichever columns you cannot fill show where the process is weak. If you want help turning that into a routine your staff will keep, tell us what you need; how support feeds repeat buying is covered under sales.