10 · Usage & ongoing use · Triage
Five words — “cannot receive” — are three completely different things
After the observation period, technical support triages by ticket: defect, operation problem, change. Every ticket has a number. Nobody promises a system change in a group chat, and this role does not work the go-live night shift.
Warehouse clerk: Cannot receive.
Technical support: Which document number? Is the prompt waiting for a supervisor, no privilege, or do you want it changed so over-receiving is allowed?
The mark of technical support is triage, not a promise on the spot
After the observation period, day-to-day problems go to technical support. On-duty watch in the go-live window, stopping paths, and night-shift handoff were already done by launch support. The mark of this role is translating one sentence into a routable ticket: document number, account, time, system prompt, what the user expected. A record with no document number is filled in first, then dispatched. Three classes still apply: defects go to development and test; operation problems go to training or a one-page note; changes go to the product owner, not to a development group. He no longer decides which production path to stop, and he does not night-shift in the warehouse.
He does not change production data directly, and does not lend an admin account for the customer to operate remotely. Acting for them turns the audit trail into support staff. When a tap must be done for them, the customer supervisor’s authorisation record keeps the document number. A promised fix time is given only after the defect has been reproduced, not in the first soothing sentence.
What counts as a ticket closed
Operation problem: the user finishes the next document alone from the note. Defect: there is a defect number, and close has a version number. Change: product has an accept or reject conclusion. None of the three closes as “use it this way for now.” “Use it this way for now” becomes a permanent bypass.
The same sentence: cannot receive
Three calls in one day all said cannot receive. After support split them they were completely different. One was over-receive waiting for a supervisor; he taught the rule: notify the supervisor. One was an account with no privilege on that warehouse; it went to the configuration consultant to add privilege and to find why it was opened wrong. One was a user who wanted over-receive to post straight to the books; it was logged as a change for product, not as a defect to chase development. Three records stayed apart, so product would not mistake pending confirmation for a broken system.
Repeated operation problems go to the trainer each week to change the material. Repeated defects: he chases the same number. He does not open a new defect on every call and wreck the counts. A second call on the same problem is linked to the original number. He does not open a new ticket that looks more urgent. A new ticket makes product think there are two incidents. He writes the user’s original words and the system’s original words, both kept. Keep only the user’s words, and development cannot reproduce. Keep only the system’s words, and the business thinks support did not listen. When a remote look at the screen is needed, he only lets the other side show the problem document. He does not take over the whole PC and browse files. Unrelated material found and leaked later cannot be attributed. Support records also do not paste a full mobile number. When a check is needed, a mask and the document number are used. Before close, support gets confirmation from the person who reported it. Confirmation is of the result, not of the mood.
The user saying “thanks, that was hard work” does not close it. Being able to receive the next truck alone does. If it cannot be verified on the spot, write the verification time and the owner. If nobody verifies when the time comes, he follows up. Follow-up is cheaper than a satisfaction score, and it exposes “it was fine then, the next shift it broke” earlier. After he rewrites a high-frequency prompt into a sentence the page can understand, he asks content operations to sync help. Change the page and not the help, and users still search up the old sentence. Old sentence and new page mismatch, and the phone comes back to support. He brings the top three problem types each week to product and training, not only a total. A falling total may only mean users stopped reporting. Classification still in place is how you know the system is actually stable, or everyone went back to phone and WeChat.