Customer Success - Get Started
      Back to home
      1. Help Center
      2. Wingtra Internal
      3. Customer Success - Get Started

      How to classify support tickets

      Understand how to label tickets for tracking of reliability and frequent questions.

      We classify customer tickets on Hubspot in order to

      • Track reliability
      • Pinpoint areas of improvement
      • Enable efficient support

      Below the following Hubspot properties are described in more detail.

       

      Ticket handling

      For Ticket owners:

      • Create one ticket for one incident
        • Document all issues and requests in a ticket also from calls, trainings, internal tests
        • Merge tickets if multiple tickets were opened for one incident
        • Open an existing ticket, if customer gets back after the ticket was closed
      • Document relevant customer inputs and findings in ticket note on the go
        • Start note as soon as ticket is open: Factual reporting, no feelings or background stories
        • Edit note when more information is available
        • Keep operational discussions and investigation apart
          • E.g. One note incl comments to resolve issue with dev, start new note to clarify shipment.
      • Tag and assign Ticket owner engineer Best practices for escalating a ticket
        • If more information is required to answer an email
        • Once relevant information is available (logs, images, ...)
        • If relevant information is not provided by the customer (FYI @...)

      For Ticket owner engineers:

      • When assigned as ticket owner engineer
        • Help investigate issue / find solution
        • Assigning cause label or track on backlog
      • When tagged in note
        • Answer potential questions
        • Assign cause label or track on backlog
      • Relevant ticket properties for Ticket owner engineers
        • Only filled out by ticket owner engineering:
          • HW investigation
          • User fault?
          • Underlying Cause Sub-Classification
              • Technical / Cause comments (free text)
              • Related GitHub Issue(s) - optional
              • Fixed
            • Properties filled out by ticket owner and double checked by ticket owner engineering:
              • Product Issue Criticality
              • Addressability

          Ticket pipeline

          The pipeline defines the ticket properties that are required to fill out by ticket owners.

          Support pipelines: Wingtra can not do something to address the cause of the ticket. E.g. Lost items, Misunderstandings, Proactive replacements

          Technical support pipeline: Wingtra can do something to address the cause of the ticket. All tickets need to have a ticket owner engineer. If you are unsure who to assign the ticket to, assign the ticket to Andrea.

          Ticket Priority

          The property ticket priority indicates how urgent the ticket should be resolved. The priority does not indicate how bad an incident is. It is filled out by the ticket owner, when opening a ticket. The ticket owner can update the priority at a later stage, if the urgency of the case changes.

          High

          • Customer is prevented from flying and has a project to finish
          • Information is required to close important deal
          • Reseller is stuck in demo (preparation, on the field, or processing of images)
          • Reliability relevant, potentially affecting multiple customers

          Medium

          • Customer is prevented from flying but no urgent project to finish
          • Reliability relevant but not preventing from flying

          Low

          • Questions to project in the future
          • General postprocessing question
          • Not reliability relevant

          Expected answer from devs

          • High: 1 day
          • Medium: up to 3 days
          • Low: up to 1 week
          • Ticket owner engineering should inform ticket owner in case analysis takes longer

          Ticket main category

          This property allows clustering of tickets. All reliability relevant tickets need to go to “Product Issue / Malfunction”. Please apply the "worst" category if in doubt. E.g., if a customer complains about battery estimation and says it should be better, treat it as a "product issue" rather than a feature request.

          • Reliability relevant: "product issue / malfunction". Please apply this label as the FIRST in the list in case you add multiple (the order of labels matters for reliability KPI counting)

          Product issue / malfunction

          • Wingtra product did not work as designed/expected, also if it is a user fault.
          • Ticket owner engineering: P&I, SW, HW

          Photogrammetry Questions

          • Any issues related to 3rd party photogrammetry SW (Pix4D, Agisoft, Propeller, ...)
          • Questions to camera settings
          • Exclude WingtraHub bugs -> Product issue / Malfunction
          • Exclude WingtraHub & Base station questions -> Geotagging Questions
          • For ticket owner eng:
            • Evaluate if there is an issue with Wingtra data
              • If yes
                • change ticket main category to Product issue malfunction
                • reassign to corresponding ticket owner eng
              • If no
                • Set "Underlying Cause Sub-Classification" and "Technical / Cause comments (free text)" 
                • Suggest possible debugging steps
                • Do not request data for processing, but forward case to pix4d, bentley, propeller, agisoft or micasense support
                • Offer application consulting

          Geotagging Questions

          • Base station / Rinex compatibility
          • Coordinate system questions
          • WingtraHub Questions

          WingtraPilot Questions

          • Flight planning recommendations
          • Unclear functionality
          • Ticket owner engineering: Andrea

          Feature request

          • Ticket contains input regarding functionality that could be added but is not there yet. 
          • If the feature is required to acquire/process useful data it is a product issue / malfunction (criticality: suggestion, annoyance or prevented user from getting useful data). E.g., state of charge improvements are most likely product issues / malfunctions.
          • All requests need to be tracked on canny
          • In case additional information insights in ticket, link ticket in internal canny post or tag responsible person in ticket

          Maintenance / Extended Services

          • Check up requests -> sell new maintenance products
          • Questions about Extended Services (SYW, ADP, ...)
          • Proactive log analysis -> assign dev

          Regulation / Certification

          • EASA / FAA regulations
          • Pilot license
          • Drone registration
          • Risk assessment

          Web applications

          • Distributor Dashboard
          • Knowledge base
          • Feedback Portal
          • Ticketing tool

          Shipping Process

          • Shipping/FedEx Complaints
          • Customs issues
          • Missing item in shipment
          • NOT shipping damages ( -> Product Issue / Malfunction)

          General questions

          • Not related to any other main category

          Product issue criticality

          This field must be filled in by the customer success team. It answers the question "how (bad) was the customer experience"

          1 Crash-like

          • ‌The worst kind of customer experience.
          • In many cases, crash-like incidents feature "uncontrolled behavior." Unlike "unsafe behavior," the drone does not recover but actually hits the ground
          • There is usually a risk that either people get hurt or property damaged
            • Example: crash, fly-away, "emergency land" >100m from take-off spot
            • Example: motor failure on take-off leading to the drone travelling more than 5m, e.g. "video" here
            • Motor failure on landing, again drone travelling more than 5m before hitting the ground: video (last part)

          2 Unsafe behavior

          • ‌There were parts of the flight where people felt unsafe, usually because there was unexpected or uncontrolled behavior.
          • Whether or not it felt unsafe for the user can be hard to judge. One tip: If the user was scared to continue flying until he notifies support, then FOR SURE it felt unsafe.
            • Example video 1: getting pushed over due to wind
            • Example video 2: sidestand stuck in ground
            • Example video 3: violent flip of an early WingtraOne :)
            • Counter example: Not to be confused with "tipping," which involves the drone falling over relatively slowly on landing -> a tipping per se is classified as an annoyance if nothing was broken on the drone. example tipping video
            • Example: emergency landing > 10m but < 100m (emergency landing by itself should not be "unsafe" usually)
            • Example: flip / falling over at take-off due to multiple reasons:
            • Very weird flight behavior (like didn’t loiter down, or drifted towards obstacles)

          3 Damaged drone/parts

          • ‌Parts on drone or accessories breaking or malfunctioning in a way that it prevents safe flying or data acquisition
            • “Dead on arrival” for some reason
            • Plane (composite, plane-middle stand interface, top cover, nose cover)
            • Camera mount
            • PPK module
            • Charger
            • Drivetrain
            • Telemetry (damaged module)
            • Tablet

          Examples

          • Consistent camera connection problems -> needed to exchange the camera mount to fix the problem (e.g. here)
          • Hard landings leading to damages, examples like drivetrain not providing enough thrust, not enough charge in the battery state of charge estimation (here and here)

          4 Prevented user from getting useful data

          • ‌Customer prevented from getting useful data, but the issue was fixable without exchanging parts
          • To distinguish these cases from "annoyances," think about how much time was wasted for the customer. A good guideline is: if the user could not get data same day; it's "prevented user.."
            • Could NOT get data the same day, but in the end the incident was fixed by re-flying / location change / re-trying or fixed with the help of remote support, without exchanging parts
            • Help from support was needed to continue to fly or process the data

          Examples

          • No images taken or missing PPK data, happening only intermittently (e.g. here, here)
          • Safety checklist not passing through (e.g. here), or e.g. crashing app (e.g. here)
          • Geotagging or WingtraHub problems that are fixable with re-trying, different base station settings or re-flying (e.g. here, here)

          5 Damaged consumable (battery, middle stand, side stand, propeller, SD card adapter, pitot tube, top / nose cover, “tape-fixable” composite damage)

          Consumable = things that are easily replaceable and designed to be replaced. The idea is that customers are not really obstructed in what they want to achieve as long as they make sure they have a spare consumable on hand.

          • Battery
          • Middlestand (only if it is totally damaged criticality is 3)
          • Propeller
          • SD card adapter
          • Pitot tube
          • Side stand
          • “Tape-fixable” composite damages
          • Telemetry cable

          6 Annoyance

          • ‌Product and / or workflow limitations that lead to detours or cause annoyances for customers. E.g., there's a limitation in the current product, but the customer was more or less able to achieve the desired result, even if only after consulting support
          • Tipping during landing that does not prevent customer from flying again and there are no broken parts

          7 Suggestion

          • Product improvement suggestions

          Damaged / Malfunctioning Parts

          • Which part did not work as expected or was damaged
          • Only consider hardware items
          • If item is not on the list, tag Andrea to extend it

          Parts Replaced

          • HW parts that was replaced

          HW Investigation

          • By default set to "No back-shipment needed"
          • Property to track progress of investigation
          • Filled out by Ticket Owner Engineer
          • Returns need to be approved by Youssef/Jonas/Constantin/Michi

          Underlying Cause Sub-Classification

          The field answers the question: "what was going on," usually from a technical point of view.

          Correspondingly, "what can we do to prevent such a case in the future."

          These fields should ONLY be filled in by the R&D team, usually "ticket owner engineering." Customer wizards are welcome to suggest how they would classify (@mentioning people and suggesting their classification in the note).

          Notes to Devs

          • If you would like to apply a label which is not existing yet, @mention Armin or write via Skype what label you would like to have created
          • If you add a label to a ticket where you are not the "engineering ticket owner," it's good practice to add a note and tag the engineering owner to avoid disagreements

          Technical / cause comments (free text)

          More details to the cause or extent of the issue. Summary of technical issue in few words. Mandatory field to be filled out by ticket owner engineering.

          User fault?

          Distinguishes user faults from technical failures. If case is not understood, "User fault?" field is filled out according to best guess. Mandatory field to be filled out by ticket owner engineering.

          Addressability

          This must be filled in by the customer support team, and can be filled in by anyone. The field answers the question: “who can do something to prevent such an incident from happening again in the future?”

           If you add multiple tags, please make sure the first one is the most relevant one.

          1. If you THINK the underlying cause of this incident can be addressed by a certain team, select it from the dropdown ("Addressable <TEAMNAME>"). Add your idea about what could be done in the "technical / cause comments (free text) field."
          2. If you THINK the underlying cause of this incident cannot be addressed or is not worth the time to be addressed, apply the corresponding label ("Not addressable <TEAMNAME>"). Do not remove any of the existing addressability labels in this case to make it clear that this was looked at by the team but deemed not addressable.

          Fixed

          This can only be filled out by the domain owners: Youssef, Jonas, Michael, Gaetan, Andrea. It answers the question: "By what time do we think the underlying cause will be fixed such that the incident is unlikely to re-occur."

          1. If you KNOW that an incident was fixed or will be fixed by your team in a certain quarter, apply the corresponding label ("Fixed <TEAM> <QUARTER> <YEAR>")

          Reliability Loop Closure

          Every month, a meeting between Armin, HW, SW, P&I, and CS is taking place to update on the current situation of the tickets that are addressable by any team (CS, P&I, HW, SW). As a basis, the Addressability dashboard in Hubspot is used. The dashboard gives an overview of the distribution of tickets and addressability per team. The goal of every team is to minimize the number of tickets without a planned fix.

          Addressability Process of CS team

          The tickets that are addressable by CS are checked by Andrea every week. She thinks about possible fixes and documents them as tasks in clickup using the tag "customer fix (addressability)". The link to the clickup task is added to the hubspot property: Related Clickup Task(s). The open tasks and possible further ideas are discussed every two month with Jasna. This meeting ideally takes place before the reliability loop closure meeting. Jasna distributes the most relevant tasks to the CS team members.

           

          After the reliability loop closure meeting, the knowledge about future fixes is communicated to the support team by Andrea. Known issues and future solutions are documented in the internal knowledge base, this way future tickets can be resolved more efficiently.

           

          ---------------------

          Examples of "difficult to classify" cases and reasoning: see here