Without logs we can not make a proper warranty assessment. Furthermore we can not improve our product based on the learnings (we can not explain the crash reason). What to do if we face such cases?
We should in any case try everything possible to get hold off the logs. If this is not possible, we want to do as many credibility checks as possible to see if it was a technical failure and assess if we can trust the user. By default, assume that the user is telling us the truth!
Credibility checks
- Get the flight plan from the tablet. Check with the flight plan if the description of the user makes sense.
- Check the flight plan: was there an obvious planning mistake? check if terrain following was enabled and check the SRTM databaes for the flight location, eg with OpenCycleMap.
- Verify environmental conditions with weather forecasts for the flight location
- Hop on a call with the operator and go through the flight step by step
- preflight: everything normal?
- takeoff, transition, loiter
- crash happened where? explain in detail
- what was done to retrieve the drone?
- any unusual observations
- any unusual observations on the last few flights before the incident or in-office? Give some examples what "unusual" they could have faced, i.e.
- weird sounds
- tip over on landing
- dropped while handling
- ...
Warranty decision
Make a suggestion if you would replace the drone under warranty or not and why. Discuss your assessment and credibility checks with your team lead. Generally act customer friendly, but make sure to make as many credibility checks as possible.
If you decide to replace the drone on Wingtra cost, make sure that the case is perceived as a positive Wingtra experience!
Act fast!