Ticket Triage for Plex ERP: How Small BA Teams Decide What Gets Fixed First
It is 7:40 am on a Monday morning and your inbox already has four Plex problems in it. A supervisor at one plant cannot print labels. An accountant at another company cannot close last month's books. Somebody - you are not sure who - reports that "Plex is slow." And a text message from a plant manager says a workcenter stopped recording production two hours ago.
Four tickets. One of you. Which one do you touch first?
If your answer is "whichever one I saw first" or "whoever is loudest," you do not have a support process - you have a reaction process. The fix is an old idea borrowed from emergency medicine: triage. This article covers what ticket triage is, why it pays for itself in a Plex ERP environment, the five-step pass I recommend for every incoming ticket, and the specific challenges that hit small Plex business analysts who support more than one company, in more than one location, at the same time.
Listen to the podcast version of this post:
What triage actually is
In an emergency room, triage is the discipline of sorting patients by how much harm delay will cause - not by who arrived first, and not by who complains the loudest. The patient who arrived an hour ago with a sprained ankle waits. The one who just walked in with chest pain does not.
Ticket triage is the same discipline applied to support work. It is the short, structured pass you make over every new request to answer four questions before any fixing starts:
- What is actually broken? (Or asked for - not every ticket is a break.)
- Who is affected, and how badly?
- How fast does it need attention?
- Who owns it, and what happens next?
Two clarifications matter. First, triage is not solving. A good triage pass takes two to five minutes per ticket. Its product is a decision - a priority, an owner, and a first response - not a fix. Second, triage is not a one-time setup. It is a habit you run on a rhythm: at the start of the day, again mid-day, and whenever a true emergency lands.
Why triage pays for itself
It protects production, not feelings. In a plant running Plex, a stopped workcenter or a label printer that will not print is not an IT inconvenience - it is product that does not ship. Without triage, that ticket sits behind a password reset because the password reset arrived first. Triage is what makes "the line is down" jump the queue by rule instead of by luck.
It ends loudest-voice prioritization. Every plant has a supervisor whose every request is "urgent." When priority is assigned by a visible, agreed matrix instead of by volume, you stop having arguments about fairness - you point at the matrix.
It creates the data that gets you help. Categorized, prioritized tickets turn into a backlog report: how many incidents versus how-to questions, which modules generate the most pain, how often the same root cause returns. That is the evidence you take to management when you ask for training, a configuration change, or a second set of hands. Untriaged inboxes produce anecdotes. Triaged queues produce numbers.
It makes vendor support faster. When a problem really is a Plex product issue, the quality of the case you open decides how fast it moves. A triaged ticket already contains the business impact, the scope, and the reproduction details Plex Support will ask for - so the first exchange is progress, not twenty questions.
It keeps trust. Most user frustration is not slow fixes; it is silence. A triaged queue means every requester gets a fast first response - "got it, this is a P2, here is what happens next" - even when the fix itself takes a day. Acknowledged people wait patiently. Ignored people escalate, loudly, to your boss.
The five-step triage pass
1. Capture: one front door
Triage cannot sort what it cannot see. Requests will still arrive by hallway, phone, and text - that is plant life - but the rule is simple: if it is not in the queue, it does not exist. Log the hallway request into the same system as everything else (your ticketing tool, a shared form, even a disciplined spreadsheet) with the requester's name, company, and location. One queue per company you support, or one queue with company as a required field - but never five inboxes and a notebook.
2. Clarify: six questions before you classify
Most tickets arrive under-specified: "Plex is broken" is a symptom report, not a ticket. Before you assign anything, get answers to as many of these as you can - by reply, by phone, or from the ticket form itself:
- What were you trying to do, step by step?
- What happened instead - exact error message or a screenshot?
- When did it start, and did it ever work before?
- Who else is affected - just you, your shift, your plant, or every site?
- Is there a workaround, and are you using it?
- What business deadline does this hit - a shipment, a close, an audit?
These six answers are the difference between a ticket you can route in two minutes and one that bounces back and forth for two days.
3. Classify: name the type before the priority
Priority arguments go in circles when people mix up what kind of work a ticket is with how urgent it is. Classify the type first:
- Incident - something that worked is broken.
- How-to / training gap - the system is fine; the user needs knowledge. Route to training material, not the fix queue.
- Service request - new access, a new report, a label format change. Planned work with a queue of its own.
- Data problem - wrong part data, a bad BOM, a stuck transaction. Often the real root cause behind "incidents."
- Change / enhancement - "Plex should do X." Deserves a backlog and a business case, not an emergency slot.
Classification alone fixes a hidden tax: in most Plex shops, a large share of "support tickets" are really training gaps and master-data problems wearing incident costumes. Each type has a cheaper cure than your scarcest resource - you, troubleshooting.
4. Prioritize: impact times urgency, in the open
Priority comes from two questions: impact (how much of the business is hurt - a line, a plant, a company, one person?) and urgency (how fast does the harm grow - is a shipment, a close, or a shift at stake?). Cross them and you get four working priorities:
| Priority | What it means | Plex-flavored example | First response |
|---|---|---|---|
| P1 - Critical | Production stopped or a core process blocked, no workaround | Workcenters cannot record production; shipping cannot print labels at ship time | Within 30 minutes |
| P2 - High | A department or a whole function degraded; workaround exists but hurts | Accounting cannot post a batch the day before close; DCS checksheets failing for one line | Within 2 business hours |
| P3 - Medium | One user blocked, or a team working around an annoyance | A planner's saved grid view broke; one operator cannot clock in correctly | Same business day |
| P4 - Low | Questions, cosmetic issues, requests with no deadline | "Can this report show one more column?" | 1-2 business days |
Two override rules keep the matrix honest. Data corruption and security jump the line - anything that is quietly writing wrong data (wrong costs, wrong inventory) is a P1 in disguise, because every hour it runs, the cleanup grows. And deadlines beat volume - a P3 that blocks Friday's payroll or a customer audit outranks a fresh P2 with a comfortable workaround.
Publish the matrix where your users can see it. When people can predict the priority you will assign, half of them triage themselves before they ever write the ticket.
5. Route, respond, escalate - with an owner
Every triaged ticket leaves the pass with three things: a named owner (even if the owner is "me, Thursday"), a first response telling the requester the priority and what happens next, and - when it is a product issue - an escalation. The most common triage failure is the bystander queue: three people saw the ticket, each assumed another had it. One owner, named in the ticket, ends that.
Escalating to Plex Support: send a case that gets answered
Your internal triage also decides what becomes a vendor case - and in Plex, that gate matters more than in most systems, because only your company's authorized support contacts can open cases with Plex Support (two contacts on the included Silver tier, four on Gold). If you are one of those contacts, every sloppy case spends your credibility; every sharp case builds it. Support runs 24/5 for standard cases and 24/7 for critical ones, so a genuine P1 should never wait for Monday.
A vendor-ready case includes: the business impact in one sentence ("Line 3 has not recorded production since 06:10"), the scope (one user or all, one plant or every PCN), exact steps to reproduce, the error text or screenshot, when it started and what changed, and the workaround in use. Write that during triage and escalation becomes a copy-paste instead of a second investigation.
The small-BA problem: many companies, many locations, one you
Everything above gets harder when you are a small team - or a team of one - supporting Plex for several companies or a company with several plants. These are the challenges I see most, and what actually helps:
Every site runs a slightly different Plex. Different modules, different customizations, different settings, sometimes different habits around the same screen. The fix that worked at Plant A breaks Plant B. What helps: a one-page profile per company/site - modules in use, key customizations, their authorized Plex contacts, their quirks - kept where you can open it in ten seconds during triage.
Your priorities collide across companies. Two clients' P2s land the same morning and both believe they are your only job. Without per-company expectations agreed in advance - response targets, triage windows, what counts as a P1 - every collision becomes a negotiation. What helps: a short, written support agreement per company, even a one-pager, that both sides signed when things were calm.
Time zones and shifts eat your day. A ticket filed at the end of second shift at an East Coast plant is a Monday-morning surprise in California - and a "P2" filed at 6 AM is a line-down P1 by the time the next shift cannot work around it. What helps: scheduled triage blocks that bracket your sites' shift starts, and urgency defined by their clock, not yours.
Intake is inconsistent. One plant uses the form, one emails, one plant manager texts you photos of error messages. The tickets you cannot see are the ones that age worst. What helps: one intake form per company (even a simple one) plus a standing rule you repeat kindly and constantly: if it is not on a ticket, it is not in line.
You are the single point of failure. Your knowledge of each site's workarounds lives in your head, which means vacations are fiction and every absence is an outage. What helps: triage notes that close the loop - root cause and fix written on the ticket itself - so your queue doubles as a searchable knowledge base, and a named backup at each site who can at least run the clarify questions.
Context switching shreds your focus. Five companies means five mental models, and every switch costs you twenty minutes of re-immersion. What helps: batching - triage everything in set blocks, then work P2s for one company in a block before switching - instead of living in interrupt mode all day.
Get the one-page cheatsheet
I have condensed this article into a one-page PDF: the five-step triage pass, the priority matrix with Plex examples, the six clarify questions, and the vendor-case checklist. Print it, pin it, share it with your sites: Plex ERP Ticket Triage Cheatsheet (free PDF). It is also listed with the other free resources at themerlanos.com.
Pair it with the fillable Plex ERP Site Profile template (free fillable PDF) - one page per company or plant you support: modules in use, key customizations, authorized Plex contacts, escalation path, and local quirks, ready to open in ten seconds during triage.
The bottom line
Triage is the cheapest process improvement in support: no software to buy, no project to approve - just a visible matrix, six honest questions, and the discipline to sort before you solve. For a big support organization it is good practice. For a small Plex BA carrying several companies and locations, it is the difference between running your queue and being run by it.
Start Monday: one front door, the six questions on every ticket, and the matrix posted where your users can see it. By Friday you will feel the inbox getting quieter - not because there is less work, but because for the first time, the work is in order.
