It is Friday and your Level 3 PPAP is due to the customer this afternoon. You are inside the tool assembling the package when a document export comes back wrong. You do the thing every quality engineer does: you check whether it is you, confirm it is not, and then you go looking for the vendor's support link. You find a form. You describe the problem, attach a screenshot, and get an auto-reply with a ticket number and a promise of a response within two business days. Your submission is due in three hours. Two business days is Tuesday.
That gap, between the moment a tool fails you and the moment anyone on the vendor side does anything about it, is the part of software support that quietly wrecks deadlines. This post is about how we built ours to close that gap, why it is structured the way it is, and what specifically that means when the thing that breaks is on your account. It is also honest about where we are not there yet, because a support claim you cannot back with numbers is just marketing.
We run support as a corrective action, not a ticket queue
You already know the discipline for this. When a nonconformance shows up on your floor, you do not open a ticket and wait. IATF 16949 Clause 10.2 puts a clock and a structure on it: contain the problem, find the root cause, correct it, verify the correction worked, and prevent it from coming back. That is the 8D loop, and every supplier quality engineer has run one under a customer's eye.
We run our own software defects through the same loop. A problem on a customer account is a nonconformance. It gets contained, corrected, deployed, and closed, and each of those steps has a target time attached to it, the way a good CAPA has a due date on every discipline. We set four of them as company goals on July 21:
- Acknowledge the problem within one hour.
- Have a fix in eight hours.
- Deploy that fix to production within twelve.
- Close the loop with the customer inside twenty-four.
Those are goals, not guarantees, and I will show you in a minute exactly which ones we hit and which one we are still behind on. The point of naming them is the same reason you put a date on a CAPA: a target you track is a target you can be held to. Every miss gets a named owner in a weekly review, not a shrug.
What makes the loop fast is that it is run by agents, not a headcount
Here is the part no support desk staffed by people can structurally match. Our support loop is run by software agents, not a queue of humans waiting to be paged.
When something goes wrong on an account, the loop that picks it up does not wait for a human to be at their desk, read a ticket, reproduce the issue, and hand it to an engineer. An agent triages the report, reproduces the failure, drafts the acknowledgment, and hands a scoped fix to the part of the system that ships code. A person is in the loop on the judgment calls that need one. The mechanical latency, the hours a normal desk burns just moving a ticket from inbox to engineer, is mostly gone.
That is why the numbers look the way they do. On our last handful of customer issues, the median time to acknowledge a problem was about one hour. The median time to a fix, on our last five, was a little over four hours. Those are medians on a small, named recent set, not an average I am dressing up as a promise, and the sample is small enough that I would rather you read them as "this is what the loop did last week" than "this is a service level agreement I am selling you."
The bug we fixed before anyone reported it
The clearest version of this happened on a production account recently. Our batch file upload had a defect that mishandled very long filenames, the kind that come off a customer numbering scheme with a revision and a date stamped into the name. Left alone, one bad file in a batch could take the batch down with it.
An agent caught it, isolated each file in the batch so one bad name could not sink the rest, and shipped the patch. We fixed it before the customer reported it. Nobody on their side wrote a ticket, because by the time it would have bitten them, the fix was live. I want to be precise about the claim: before they reported it, not before they noticed it. I cannot see inside someone's day and prove what they did or did not observe. What the record shows is that no inbound report exists, because the problem was gone before one got written.
A human-staffed desk cannot do that, and not because the people are slow. It is structural. A ticket queue only starts moving when someone notices, writes it up, and hands it off. A loop that is watching the system does not need any of those three things to happen first.
Where we are not there yet
If I only told you the good medians, you would be right to distrust the rest. So here is the leg we are behind on.
Deploy, getting a finished fix live in production, is our weakest number right now. Our recent median is around sixteen hours against a twelve-hour goal, and it has been trending the wrong way. A fix can be written in four hours and then sit waiting for the release path to carry it to production. That is the seam we are working on next. Two of the other three goals also sit at risk on any given week, which is exactly why we track them out loud instead of quoting you a single flattering figure.
This is the same honesty a customer expects from you when a CAPA is not fully effective yet. You do not close it and call it done. You report the recurrence data and keep working it. We will get there on deploy. We are not there today, and the scoreboard says so.
We track our own quality the way we ask you to track yours
None of this is a feature you buy. It is how we operate the company. But it comes from the same conviction the product is built on, so it is worth saying where the two connect.
The reason we can put four SLAs on a board and name an owner for every miss is that we treat our own service metrics the way the Monitor module treats yours: real numbers, a live dashboard, a status on every KPI, and a review cadence that turns a red number into an assigned action. Monitor does that for your quality KPIs and audit readiness. We pointed the same discipline at our support desk.
And the loop itself, contain, correct, verify, prevent, is the exact workflow the Correct module runs for your CAPAs: 8D, 5-Why, and Fishbone, with the finding propagating back into your living PFMEA and Control Plan so the fix does not rot in a closed ticket. We did not invent a support methodology. We ran our own defects through the corrective-action discipline the product already knows, and let agents carry the mechanical parts so the clock is measured in hours, not business days.
If you want to see what that discipline looks like pointed at your own submissions, you can start a 30-day trial with no credit card and run a CAPA or a PPAP package through the tools that we run our own operation on.
The takeaway
When you evaluate quality software, the demo shows you the features. What you actually live with is what happens the Friday something breaks and your submission is due at three. Ask the vendor what their median time to acknowledge is, and whether they can name it. Ask what happens between the moment their tool fails you and the moment a human on their side reads about it. We built our answer to be short, and we publish the parts we have not gotten short enough yet.
FAQ
How fast does QualityEngineer.ai respond to a support issue?
On our last handful of customer issues, the median time to acknowledge a problem was about one hour, and the median time to a fix, on our last five, was a little over four hours. Those are medians on a small recent set, and they are company goals we set on July 21, not guaranteed service levels. We track four of them, acknowledge, fix, deploy, and close, and report the ones we miss.
What does it mean that your support is run by agents?
The loop that picks up a customer problem, triages it, reproduces it, drafts the acknowledgment, and scopes a fix is run by software agents, with a person in the loop on judgment calls. That removes most of the latency a human ticket queue spends just moving a report from inbox to engineer, which is why the loop is measured in hours instead of business days.
Did you really fix a bug before the customer reported it?
Yes, on a production account. Our batch file upload mishandled very long filenames; an agent caught it, isolated each file so one bad name could not take down the batch, and shipped the patch before any inbound report was written. We say "before the customer reported it," which the record proves, not "before they noticed," which we cannot prove.
Do you hit these targets every time?
No. Deploy, getting a finished fix into production, is our weakest leg right now, with a recent median around sixteen hours against a twelve-hour goal, and two of our other three targets sit at risk on a given week. We publish that on purpose. A support number you cannot back with data is not worth quoting.
How does this connect to the product?
The support loop runs the same corrective-action discipline the Correct module runs for your CAPAs, contain, correct, verify, prevent, and we track our SLAs the way the Monitor module tracks your quality KPIs. It is how we operate, built on the workflows the product is made of.
About the Author
Daniel Crouse is the founder of QualityEngineer.ai and has spent 15+ years in supplier quality, PPAP, and manufacturing systems. He built QualityEngineer.ai because quality engineers deserve better tools than Excel.
