A self-service portal is sold internally on the promise of reduced ticket volume, and most fail to deliver it because they're built around what IT wants to offer rather than what users are actually asking for. Look at your ticket history before building anything — the top ten or fifteen request types by volume are the ones that need a genuinely good self-service path, and everything else can wait.
Password reset is almost always the single highest-volume ticket type in any organisation, and it's also the easiest to self-serve properly with identity verification built in. A portal that nails password reset alone often cuts ticket volume more than a broader portal covering twenty different request types poorly, because the twenty-type portal spreads design effort thin across requests that individually don't move the needle.
The trap that kills adoption is a self-service form that still requires a human to review and action it manually behind the scenes. Users learn quickly that 'self-service' request took the same three days to fulfil as emailing IT directly, and they stop using the portal in favour of whichever channel feels faster, even if it's technically the wrong one. Genuine self-service means the request is fulfilled automatically, or genuinely faster, not just filed through a different form.
Measure success by deflection rate against your actual ticket history, not by portal usage in isolation. A portal with high traffic and no corresponding drop in tickets to the equivalent category isn't reducing load — it's adding a channel people browse before still filing a ticket, which is worse than not having built it, because it's now a maintenance cost with no offsetting benefit.
