If you rate a delivery badly, a ticket opens automatically. That has been true for a while. What was also true, and harder to defend, is that the median first response took about sixty-three hours — three days of not knowing whether anybody had read it.
As of this week every ticket is acknowledged in under twenty minutes. An acknowledgement is not a resolution and we are not going to dress it up as one, but those three days were never spent working on the problem. They were spent in a queue.
What the acknowledgement says
It names the job it is about, restates what you reported in one line so you can tell immediately whether we understood it, and says what happens next and who is looking at it. If the complaint is about one file in a batch, it says which file. It is written for your ticket rather than picked from three templates, which matters mostly because the wrong template is worse than no reply at all.
The person who picks it up is not starting from zero
Behind the acknowledgement, each ticket gets a diagnosis: the likely cause, the evidence from the job that supports it — which pipeline ran, the language pair, what the QA step reported, how the file was rated — and a recommended next step. That is waiting on our side before a human opens the ticket. The distance between a reply that starts with “let me look into this” and one that starts with the actual cause is most of the response time.
One thing it deliberately does not do
It does not answer old tickets. When we switched it on there were eighteen that had been open the better part of a week, and an automatic “thanks for reaching out, we are on it” against a five-day-old complaint is worse than the silence it replaces. Anything older than seventy-two hours is diagnosed for us and answered by a person. Any automation allowed to write to a client needs a limit of that kind, and it is much easier to add before the first send than after.
What the diagnoses told us about ourselves
The first batch produced a finding we did not expect. Almost none of these tickets are technical failures — jobs that actually break are well under half a percent. They are quality complaints, and grouped by cause they are not spread evenly across terminology, style and formatting the way we assumed.
The dominant cause, by a wide margin, is speaker assignment in multi-speaker audio: how many people the system believes are in a recording, and which of them said what. Not one of the first two dozen would have been fixed by a glossary or a style guide, which is exactly what we would have reached for. It is now a specific piece of work with a specific measurement instead of a general sense that audio is hard, and we will write about it when there is something to show.
Nothing to switch on. Tickets live under Support inside the app, and the first reply is already faster than this post took to read.
Want this in your workflow? Try Fily with one file — no card, no demo form.