What happens to an incoming request before a person reads it

Read a month of it before changing anything

Take one month of requests from your main intake point and sort them by what was actually being asked, not by who sent them. Almost every organisation that does this finds the same two things: a small number of categories covers most of the volume, and one category that everyone assumed was significant turns out to be three messages. Both findings change what is worth building.

Separate urgency from importance, because they route differently

An urgent request needs to reach somebody now; an important one needs to reach the right person eventually. Treating them as one scale produces a queue where the loudest message wins, which is neither. Write down what counts as urgent in your organisation - concretely, in terms somebody could apply without asking - before building anything that claims to prioritise.

The honest limit of automatic classification

Software can read a request and say which published category it resembles, and it is good at that. It cannot tell that a politely worded message is from a customer about to leave, and it cannot weigh a request against commercial context it has never seen. Use it to remove the sorting work, not to make the judgement - and keep a path by which anything can reach a person without being categorised correctly first.

Acknowledge immediately, answer honestly

The single cheapest improvement to any intake point is telling the sender what happens next and when, immediately, in terms that are actually true. "We have your request about X, it goes to the accounts team, who answer within one working day" is useful. "Your request is important to us" is not, and a promised response time you do not meet is worse than no promise at all - it converts a wait into a grievance.