Exploring IBM Maximo support can sometimes feel like navigating a maze—communication delays, unanswered questions, and unclear next steps can frustrate even the most seasoned users. Drawing on my own experience submitting support cases, here are structured, actionable guidelines to help you gain clarity and move issues toward resolution more efficiently.

Define Severity Clearly

Severity levels help signal urgency and set expectations. Using the following definitions from IBM can help, but understanding how agents interpret these will help too.

• 1 – Critical: Production or core functionality is down.
  Note: Use this if you are ready to take action 24x7. If you have a hosted instance with IBM you might use this but I have never used it.  

• 2 – Significant: A system is down but not mission-critical.
  Note: I rarely lead with this, but when my priority 3 cases start to linger for months and I want to up the priority, I upgrade the severity to a 2.  

• 3 – Minor: Small disruptions or user inconvenience.
  Note: Most of my cases start here. These are normal requests for me. They don’t get priority like a severity 1 or 2. I think of these as cases that get worked during normal hours, and a couple days of delays between communications is expected from both parties.  

• 4 – Minimal: How-to questions or non-critical issues.
  Note: I use this when I want to report something but there is not anything time sensitive about it. I often downgrade the severity of cases to a 4 when I know I can’t loop back to them for a week or more. Agents work there once all their 1, 2, and 3 severities have been handled so they can easily go a week or more without activity.  
  ‍

Assigning the correct severity when creating cases and adjusting the severity as needed helps communicate your priority and needs over the life of the case.  

Crafting an Effective Description

IBM’s system does a decent job in guiding you on what to put in the description. I follow these to include a description, steps to reproduce, and my expectations. I also ensure that I call out exactly what version of MAS and Manage I am on. Something new with MAS that I have started to include is the must-gather data. I have found that if I don’t include it, even when I don’t think it is helpful, this is the first thing that is asked for. It can be very helpful to the team working on your case because it contains a ton of system information and logs. It can also be frustrating to gather because elevated access is required to pull them, and often, I have already looked at the logs and will include the snippet of them that is relevant if it exists.  
‍

Steps to run the must gather:

https://www.ibm.com/support/pages/obtaining-mas-mustgather-data-using-ibm-mas-cli-utility

Working the Case

Often agents don’t try and reproduce, which requires a ton of back and forth. If it is something that they should be able to reproduce, ask them if they have tried. They may have to get an environment provisioned. I have found that once they can reproduce, everyone agrees that it isn’t just customization in your environment, and hopefully the issue is fully understood.  
‍

Web sessions tend to be very helpful too. Normally I give a case a couple interactions before offering a web session. These sessions have served me well because they allow me to communicate the issue with more detail and answer immediate questions. I have also had scenarios where I didn’t mention a detail but the agents see it while screen sharing.  

Auto Close

IBM Cases may be auto‑closed due to inactivity. Over the last year, I have seen this get more aggressive with automated emails. Staying on top of responding to cases will help minimize this. I have also found that lowering severity also helps. Avoid abrupt case closure by leaving a comment that clearly conveys your timeline, such as:

‍

“I’ll revisit this case on [date], please keep it open until then.”

Escalating

If you think your case isn’t getting the priority it deserves, it is time to escalate. You have two levers to pull. First is adjusting the severity, as the situation evolves, don’t hesitate to raise severity if the impact grows. I normally start at 3 and escalate to 2. The second lever is the “Escalate Case” feature, proactively request escalation if resolution timelines extend or urgency increases. Combining these two things has proven very effective.

Defect delivered

If the issue is accepted as a product defect, ask for the defect number if it isn’t provided, as this helps you reference the bug across conversations. I also ask for expected timing to understand whether this will be resolved via patch, hotfix, or upcoming version. Normally smaller things will be fixed in the latest version code branch and then backported to older version when possible. Getting clarity on where it will be fixed help me set a plan for the system. You can request to keep the case open until resolution or delivery status is available. I do this for things I want to keep an eye on and know as soon as a fix is available. If applicable, explore hotfix paths using a customization archive or workaround with the person working your case. This can be especially useful for issues that are in Manage that can be fixed with a customization archive.

Closing Case

When the issue is resolved to your satisfaction, close the case proactively. I will send a final “Thank you” note, acknowledging the resolution and stating your intention to close the case. Then, click the “Close Case” button to officially close the case.