Have you ever wondered what happens to your IR/ER/PR once you hit that “send” button? I’ve heard a lot of questions about this topic, so I thought I’d do a little digging and shed some light on the process for you.
First, let’s start with “What is an IR/ER/PR?” Most of you reading this will already be well-versed in the differences (you can skip ahead), but for anyone who’s a newbie just getting started, let me explain.
IR stands for Incident Report. This is a broad term that covers any request you place. ER stands for Enhancement Request. This is when you would like improvements to an existing feature or an entirely new feature altogether in the software. PR stands for Problem Report. This is when the software is not working as it should.
Every online request begins its journey as an IR. From there, the Global Technical Access Center or GTAC determines if it should be escalated to an ER or PR.
GTAC representatives are the people you call when you need help with NX. If you call in, they will log your request online and identify it accordingly. GTAC assists you to resolve IRs. But what happens once they change the status to an ER or PR?
Product managers are notified of ERs that fall under their realm of expertise. (PRs go to product developers, so for the purposes of this blog, I’ll only be focusing on ERs from here on out.) Each product manager has his or her own way of processing the requests. For this article, I interviewed Dave Wingrave, whom many of you know as the NX product manager for Drafting, PMI and Layout.
“Customers are passionate about NX and always looking for ways to get their job done faster with less effort. This aligns with what we, as product managers, aim to achieve,” Dave explains. “As a result, we review ERs on a regular basis looking for input customers feel would add value to our solutions.”
“As product managers, our goal is to get closure on as many requests as possible, so our customers know we’re listening and value their input,” Dave says. “The challenge sometimes is finding the business value in a request.”
He also offers a bit of advice for anyone who logs a request. “Requests that clearly indicate business value stand out from those that don’t. Generally most people are able to communicate ‘what’ it is they want; however, often the ‘why’ is missing.” Dave explains. “The ‘why’ is actually the most important part, because it helps us to understand the value. Providing metrics with such input as how often (i.e. hourly, daily, weekly, monthly, etc.) a specific workflow impacts users in your organization also helps with business justification.”
Dave notes a misconception about the ER process: “Some people might feel that logging an ER doesn’t matter. This might be because they logged an ER in the past that has not been addressed and therefore feel we’re not listening or don’t care. That’s simply not true,” he says. “ERs help product managers understand what is important to customers, identify common requests and prioritize investments. After all, we are not unlike any other business; we want to make our customers successful and maximize our ROI.”
If you have any questions or want to know more, feel free to post in the comments below or private message me @AmyReyes1.
Keep your eyes peeled for more posts to come on GTAC and the services they provide!