@APS-C It cannot be inaccurate if it is a description of what actually happened, the conclusion may well be “inaccurate” or overstated and then applied to an entire department but it is a personal conclusion drawn by the author, based upon an actual experience, and presented in frustration.
If there are a lot of complaints about the investigating process (!?) then surely that indicates possible issues with that process (at least that the communication of “what to expect” to the customer is missing, if nothing else!?).
But I am not convinced that there are “lots of complaints”, they do crop up from time to time and in a topic requesting help because DxO Support has failed to live up to its name, or at least the user feels that is the case.
Most users expect obvious questions to be asked but they also expect a reaction that seems to indicate an understanding of their problem, a progression in the conversation, and a possible change in direction of that conversation when the answers are given.
In this case the product is not in a state whereby the user cannot use it so actually uninstalling and re-installing are unlikely (but not totally impossible) to have a positive outcome!
But worse is the fact that such an action might actually destroy an opportunity to gather additional details about the fault, i.e. the “script” is missing a decision box that should have taken the first responder to the step of gathering whatever diagnostics the product automatically gathers from the user and/or establishing with the user if there is a possibility of running the test again with additional diagnostics in place!
But this step needs to be explained to the user because it requires their co-operation.
In spite of using every diagnostic tool I can lay my hands on when investigating DxPL I have never been “trained” nor seen details of the logging mechanisms and given their importance in situations like this I feel that there is a missed opportunity there.
I have used the mechanism on occasion under instructions from DxO support staff and having designed, built, tested and supported systems all of my 36 year IT career I am well aware of the importance of logging.
Programs I developed had the option of activating logging via the operator console for short periods of time (customers don’t like their systems being reduced to a crawl) and if all else failed I would request that it was activated for a given (short) period of time.
But in this case @MarshallG had identified a “problem”, found someone to confirm its existence, reported the exact way that it could be reproduced and expected that DxO could reproduce the problem on their own system(s) and I believe many customers feel that should be possible when they report a problem.
On my customer’s systems part or all of the code was unique and while my final customer had a Test bed that could be used to safely reproduce problems, most customers didn’t and if the operators phoned in the middle of the night then the test bed wasn’t going to be much use at that point anyway.
In this case DxO will have limited systems available to them, running the latest version (and future versions) most probably and even using VMs unlikely to be able to set up the test environment to reproduce the problem, hence, the need to make use of the users own system to gather diagnostics, in the first instance at least.
But this needs to be explained to the user and referring to it as a “crash reporting tool” in this case simply caused @MarshallG to doubt that DxO support were listening because his system hadn’t crashed!
Because it was not explained, is it the users responsibility to second guess why they are being asked to do something or the first responders responsibility to explain the “why as well as the what” they want you to do.
You know what my answer is going to be to that!
It is the only way but that needs to be explained not assumed.
There is a failure here and it is not @MarshallG that is at fault, his only “failing” was to be too blunt in the way that he introduced the topic and in identifying the support individual by name.
While it is not a common forum topic a number of problems I have investigated over the years have started because DxO support failed to help the customer and left them with a problem and potentially more confusion than they started with and with no explanation and no course of action.
The problem might be that the training of DxO staff is not adequate or the scripts are wrong or the training is wrong or the attitude to customers is wrong or the management is wrong and on a case by case (person by person) basis?
Some or any of these could lead to a variability in the experience of different users when contacting DxO support.
However, @Joanna made a point
I took this to be a humorous response but are DxO actually using AI to handle support requests!? If the answer is yes then the model needs improvements!
However, as for this particular item from @Fabrice-B,
It is full of innuendo and the bit about “share assumptions and generalizations” so accurately describes the statement itself!
“Forums are a place where customers who care about a product and are dissatisfied with what the developer is doing with that product or not doing with that product or charging for that product or …” would be slightly more accurate but the implications of the original statement is that only “trouble makers” are using the forum!?
If this attitude pervades DxO Support then !!??
“The job would be great if it wasn’t for the customers!” was an expression used in my customer support training as an example of the wrong attitude to those who directly or indirectly paid our salary!
