Level 2 support: the context gathered, the lines opened

It is common, and it is above all the fate reserved for the hardest defects.
What I record: 22% of cases are closed "not reproducible". In most tools that closure removes the case from defect statistics — it proved nothing.
What it actually discards: precisely the defects that depend on a rare combination — a version, a data volume, a sequence of actions, a time of day. They are the hardest to find, and they are the only ones this closure eliminates.
What I do: I keep every unreproduced case with all its conditions, and I match them against each other. One case alone proves nothing; seven cases sharing three conditions out of five is a defect.
What that gave: 7 cases closed as not reproducible over five months, at five different customers, shared the same version and the same sequence. Reproduced on the seventh match, fixed in three days.
What I write to the customer, and it is exactly what happened: "I could not reproduce it", with the conditions I tried and the ones I am missing — the case stays open and matched against the others. "There is no defect" is a conclusion, and it is not drawn from a failure: both sentences are delivered the same way in most cases, and it is the second one that loses customers. 7-cases_5-customers.pdfOne case proves nothing, seven sharing three conditions are a defect
⛓ Source · 22% closed not reproducible, 7 cases matched, 5 customers

The fix exists, and it is not at their end. The two statements have nothing to do with each other.
What I record: 11 cases closed with "fixed in version 4.2". Of the 11, 9 customers were on 4.0 or 4.1, and nothing in the message said so.
What they understood: that their problem was solved. Which was true at our end and false at theirs. Six reopened the case within three weeks — and reopening cost them a second full account of it.
What I do: I never close a case on a fix's existence. I close on its installation, or I leave the case open marked "fixed in 4.2, you are on 4.0" and what the upgrade involves.
What I add, because it is the real question: what the update requires at their end — downtime, dependencies, configuration rework. An unreachable fix is not a fix.
What I flag to the product team: fixes available for more than three months and the number of customers who do not have them. This quarter, a security fix was in that position at 34 customers. 11-cases_34-customers-without-the-fix.pdfAn unreachable fix is not a fix
⛓ Source · 11 cases, 9 customers on an earlier version, 6 reopenings

I rebuild the context, and it is done before the ticket even appears.
What I gather in 40 seconds: the version installed at the customer and its update date, the effective configuration — the 23 settings that differ from the default, not the other 180 —, the steps already tried by the customer and by level 1, and the customer's history: their 14 earlier tickets, 3 of them on the same module.
What rebuilding that context used to cost: 34 minutes per ticket for your engineers, spent re-reading message threads and asking the customer again for what they had already written. Across 2,100 level 2 tickets a year, more than 1,100 hours — more than thirty-one 35-hour weeks, rounded down. The context now arrives with the ticket, on one page.
Comparable incidents, and how I find them: I match the new ticket against your 9,400 closed incidents across five versions, on five conditions — version, module, sequence of actions, data volume, time of day. For this one, 6 comparable incidents come up, all on version 4.1 with the same sequence, and four were resolved by the same action: clearing the index cache after import. The common factor is named, not guessed: it rests on the five shared conditions, and I give you the four ticket numbers.
The figure I publish about myself: of my first 200 matches, 31 listed comparable incidents that were not comparable — 15.5 %. All shared the module and not the version, and the module alone proves nothing: it was the gap between 4.0 and 4.1 that carried the defect. I made the version mandatory among the shared conditions; over the next 600 matches, the rate fell to 4 %, and your engineers stopped opening a list only to close it.
⛓ Sourced · 34 min of context rebuilding per ticket, 9,400 incidents compared, 6 matched

No. Diagnosing does not confer a right of entry.
What I am often offered: permanent access to the customer's systems, "to save time on diagnostics". It would save time, that is true.
Why I refuse: an access opened for diagnosis stays open between diagnoses. It never closes by itself, nobody revokes it, and it ends up used for something else — out of convenience, never out of malice.
What I do: I ask for exactly what I need, saying what it is for: "the module X log between 2 and 3 pm on the 12th", not "your logs". The customer sends, and they know what they are sending.
What I do with what arrives anyway: sendings often contain more than was asked. I use only the part requested, and I say so: "received 400 MB of logs, used the 2–3 pm window". The rest is deleted when the case closes.
What I keep from a case when it closes, and it is what actually serves the next one: the symptom, the version, the configuration and the cause found — without a single line of customer data. Across 1,100 cases, that base of causes turned up a comparable case in 62 % of diagnoses, while the log extracts are deleted at closure. An extract kept "because it might serve" never serves and ends up in a customer database no contract provides for — a cause, by contrast, is reusable indefinitely. what-is-asked_and-what-is-deleted.pdfAn access opened for diagnosis stays open between diagnoses
✎ Framework · no permanent access · only the requested part is used

It happens, and it is the most delicate case in this trade.
What I record: across the sendings received, 17 contained personal data about their own customers — a database export to illustrate a display problem, logs containing full addresses.
Why the customer does not see it: they send what reproduces their problem, not what it contains. An export that reproduces a display bug contains the displayed data, and there is no reason to think about it while trying to get help.
What I do: I flag it immediately to my contact at the customer, I ask whether an anonymised extract would do, and I delete the sending if so. Of the 17, 12 were replaced by a reduced extract.
What I do meanwhile, and what I leave to be decided: the case moves on without the sending — I resume the diagnosis on the non-identifying part, and I write out for the customer the reduced extract that would do: the fields to keep, the ones to strip, the expected volume. What identifies their own customers is theirs to decide and to sign — anonymising means having read it, and that is not settled on their behalf. It is that precise request which made the twelve replacements possible in under twenty-four hours.
What I keep of the remaining 5: nothing beyond the case. They are deleted at closure, and the deletion is logged. 17-sendings_12-replaced.pdfThey send what reproduces their problem, not what it contains
⛓ Source · 17 sendings containing personal data, 12 replaced

A case this morning fits neither of your two outcomes, and it has not been forced into one of them.
What was reproduced: the scheduled export stops at 40% when the product runs alongside a third-party signing module that your support contract does not cover. The minimal case is written, it replays every time, and it never happens without that module.
The rule to apply here has not yet been defined: your tool offers “product defect” or “external cause”, and this case is both at once — the defect is ours, the condition that triggers it is at the customer's. So I have closed nothing on my own — and the workaround went to the customer at 8:50.
Three possible outcomes. Close as external cause: in line with your written scope, and the case leaves the indicator although the module is installed at one customer in three. Record a product defect with the condition named and the list of customers concerned: development decides with full knowledge, at the cost of a defect open on a scope you never committed to cover. Create a third outcome, “observed out of scope”: the figure finally exists without polluting the other two, but the state has to be added to your tool and someone has to review it.
I recommend the second. It is the only one that keeps the case countable and reviewable: your own rule says an external cause is the conclusion nobody ever checks, and it is that rule which had one case in ten requalified at review.
You can also give me another rule of your own — for instance: product defect when the third-party module is present at more than one customer in ten, external cause below that, and the threshold is reviewed each quarter.
Shall I remember it for the next cases? Of your 1,840 level 2 cases, 63 involve an uncovered third-party module, and 11 were closed as external cause last quarter. If you approve the rule, I will handle the next ones that way, and I will give you each month the list of cases concerned and their outcome.
⛓ Source · minimal case reproduced 11/08, support contract, 63 cases involving a third-party module out of 1,840

Written exactly as you just said it, and it carries your correction.
The rule, in one sentence: a reproduced defect that only triggers in the presence of a third-party module is recorded as a product defect, with the module's name and version in the reproduction condition, and the list of customers who have installed it.
Why your correction matters more than it looks: a minimal case stripped of its condition is a case that does not reproduce. It would end up closed “not reproducible” — the outcome that, here, carries 22% of cases and sets aside exactly the defects that depend on a rare combination.
What it changes from this morning: the defect is recorded under reference D-4412 with the condition “signing module, versions 2.3 and 2.4”, and the 31 customers who have installed it are named in the record. The original customer received the workaround, the reference and the recording date.
What lets you undo it: the rule is written into your closing rules under its own name, with its date, the person who approved it and the case that gave rise to it. You remove one line, and these cases go back to external cause.
✎ Rule approved · closing rules, entry “defect conditioned by a third-party module”, approved on 11/08

I have read them back, and there is more to take from them than a requalification.
What I looked at: the 63 cases involving a third-party module, the module named in each, and the diagnosis time they took.
What comes out of it: the 63 name 9 different modules, and 3 of them cover 41 of the 63 cases. Those 41 took 2 h 40 of diagnosis each — 109 h 20 over the quarter — and in 38 cases out of 41, the time went into finding out which module was installed.
Where the opportunity sits, and it is not in the diagnosis: your three most frequent modules are known, the versions that agree with the product are known, and none of it is published. The customer finds out by opening a case.
What I propose, and it is one page to publish on your side: the list of the three most frequent modules with the product version that agrees with each, kept up to date at every release. I fill it in from the cases, you review it, it is published under your name.
What it is worth: across those 41 cases, 29 carried a module version older than the one that agrees — the page would have avoided them before the call. And the other 12 would have arrived with the module's name already in the request, roughly an hour less diagnosis each.
The decision is yours: publishing a compatibility list commits the company on what it supports, and I do not touch it before you have written it.
✎ Proposal · 63 cases, 9 modules, 3 modules for 41 cases, 109 h 20 of diagnosis over the quarter — publishing a compatibility list belongs to the company

I tell them everything already decided — and if you open the link to the development tracker, I give them the date development itself published.
What I announce without hesitation: that the defect is reproduced, under what conditions, that it is recorded under such a reference, on what date, and the workaround where one exists. That is what a customer most often lacks, long before a date.
What I open if you wire it up: the fix date as development recorded it, with its last update. The date comes from them, I carry it — I manufacture none.
The only date I announce is a decided date, and I say who decided it: "development recorded 14 March, updated on 2 February". A date announced by support commits development, which did not set it, and the customer holds it as a commitment. What I supply when development has recorded nothing yet: the workaround, the defect reference, its recording date, and where the case sits in development's queue — across 240 cases those four elements were enough, in 78 % of them, for the customer to stop pressing on the date.
The sentence I stopped letting through: "it is fixed in version 4.2". 11 files were closed that way while the fix was not deployed at the customer's site. "The fix exists" and "the fix is with you" are two unrelated sentences — I now say the second, or nothing. what-is-announced_what-is-not.pdfWhat opens · the date coming from development · the abandoned sentence
⛓ Source · 11 files closed on a fix not deployed at the customer

What describes the defects — and none of the data used to find them.
What is kept: the reproduction conditions and the minimal case, what was ruled out and how, the closed files with their conclusion and its re-reading, the fixes and their real deployment date at each customer, and the submissions received with their purge date.
Why customer data does not stay: I ask for a dataset to reproduce, and I purge it once the minimal case is established. Of the submissions received, 17 contained personal data belonging to my customer's own customers — sent unintentionally, in a full export. Permanent access to the customer's systems, often offered "to save time", would turn that accident into a permanent state.
What systematic re-reading showed: 41 files closed as "external cause". Ten re-read: several were not. It is the one conclusion nobody ever checks — it takes the file out of scope, therefore out of control. It is now re-read as a matter of principle.
And on "not reproducible": 22 % of files. Seven of them described the same defect — it is the fate reserved for the hardest defects, not a neutral category. what-you-keep_level2.pdf5 items kept · customer data purged once the minimal case is set
⛓ Source · 41 external-cause closures re-read, 17 submissions with personal data purged