A customer reports a problem. Before anyone starts solving it, someone has to choose the right portal, project, request type, category, priority, and assignment group.
We have made people understand our organization before we agree to help them.
Whether you use Jira Service Management, Servicely, ServiceNow, or another platform, the question is the same: does the system help people get work done, or does it give them more work?
I don’t think the blame belongs entirely to the software. Organizations buy flexibility, then configure every exception, approval, and reporting requirement into it. Eventually, the person asking for help pays for all those decisions.
1. Start with the problem, not the project
“I cannot access my account” should be enough to begin a request.
The person reporting it should not need to know whether identity belongs to corporate IT, platform engineering, or a customer operations team. That is our responsibility.
Start with a few understandable choices: report a problem, request something, plan a change, or track work. Ask enough to establish impact and route it.
If the routing is wrong, let the receiving team correct it without sending the person back to start again.
2. Ask for information when it becomes useful
An incident does not have a root cause when it is first reported. A proposed change may not have an execution date yet.
Yet forms often demand information simply because someone eventually needs it.
Separate what we need to start from what we need to finish.
At creation, capture the problem, the affected service if known, and the impact. During investigation, collect evidence. Before a risky change, require the necessary approvals and rollback plan. At resolution, record what actually happened.
A shorter opening form does not have to mean weaker records. It means collecting information at the right time.
3. Connect the work without duplicating the story
A customer request might lead to an incident, an engineering fix, and a production change.
Those are related, but they are not interchangeable.
Support owns the customer conversation. An incident commander coordinates restoration. Engineering owns the fix. A change owner manages its release.
Keep separate records where those responsibilities require them. But carry the context forward and make the relationships visible.
Nobody should have to paste the same explanation into four tickets and then maintain four versions of the truth.
One customer problem can require several kinds of work. It should not require the customer to coordinate them.
4. Make status mean something
“Open,” “in progress,” and “pending” are not useful if nobody knows what they mean.
Pending what? A customer response? An approval? Another team? A maintenance window?
A useful status should make the next action clear. It should also agree everywhere the work appears.
Closing an incident because service is restored does not mean every corrective action is finished. Equally, an engineering task marked complete does not prove the customer has received an update.
The system should preserve those distinctions without making people decode a workflow diagram.
Approvals need the same discipline. Require them where the risk justifies them, not because every request passes through the same template.
5. Use AI to remove effort, not create activity
I would rather have AI assemble relevant evidence than generate another ticket summary nobody reads.
Useful assistance could identify likely duplicates, suggest an owner, retrieve related changes, or draft an update from verified facts.
But suggestions need correction paths. Summaries need links to evidence. Consequential actions need appropriate authorization.
An automation that creates a ticket, posts three notifications, and assigns a queue has produced activity. It has not necessarily moved the problem closer to resolution.
Measure the difference.
How long until an accountable owner accepts the work? How often does it bounce between teams? How many times does the requester repeat information?
Those are better simplification targets than the number of automations enabled.
Simpler does not mean less control
We still need ownership, access boundaries, audit history, and evidence. Removing those would make the interface easier while making operations harder.
The goal is to hide configuration complexity, not accountability.
People should know what happens next, who owns it, and what is blocking progress. Everything else should earn its place on the screen.