✅ Support Process — Complete Explanation

“Why support tickets close, how bugs are verified, and how your report becomes a fix.”

At Ham Radio Deluxe, we work hard to make our support and development processes transparent. Customers sometimes wonder why a support ticket is closed even though the issue hasn’t been fixed yet. Others wonder why some bugs take longer than expected to resolve.

Below is the complete explanation of how the HRD support workflow works—written to help customers understand why the process works the way it does, and how it ensures quality, efficiency, and accurate bug resolution.

⭐ Step 1: You Submit a Support Ticket

This is where every support interaction begins.

✔ Most reported “bugs” are not bugs

The vast majority of submissions from customers who believe they are reporting a bug turn out to be:

• configuration issues

• audio/input/output settings

• CAT configuration problems

• misunderstandings of a feature

• environment-related issues

• general “how do I…” questions

Users have been conditioned by other software to assume that everything they don’t understand is a bug. But in HRD, most issues are not software defects at all.

✔ Most real bugs affect only the reporting user

Customers often assume:

“Whatever is happening to me must be happening to everyone else.”

In reality, many true bugs are:

• tied to unique operating environments

• dependent on specific radio models or firmware revs

• related to Windows patches or driver releases

• triggered by unusual combinations of settings

• caused by one-of-a-kind user workflows

Most real bugs affect one user—not everyone.

This is important, because the more unique a bug is, the harder it is to reproduce and fix.

⭐ Step 2: Support Verifies Whether the Issue Is a Bug

If support suspects the issue might be a real bug, they gather:

• screenshots

• logs

• reproduction steps

• radio model information

• Windows version information

✔ The support team works closely with HRD beta testers

Our beta testers are a valuable resource.

If needed, support may involve them to see whether the issue can be duplicated on their systems. This collaborative process helps confirm whether the problem is:

• a real bug

• a local environment issue

• configuration-related

• or user-specific behavior

If support and/or beta testers confirm it’s a true software defect, the issue moves to the next step.

⭐ Step 3: A Single Bug Record Is Created in Mantis

Once a real bug is confirmed, support creates one master bug record in the development system (Mantis).

✔ Why only one record?

Because more than one customer may report the same issue.

If every customer report created a new Mantis record, developers would have to:

• merge duplicates

• reconcile conflicting information

• track down redundant reports

• waste time organizing rather than fixing

✔ Support links all related tickets to that one master bug

This saves enormous time for developers and accelerates the fixes.

⭐ Step 4: Your Support Ticket Is Closed

This is the step that confuses many customers.

Support tickets are closed because:

• Support has completed their part

• The issue is no longer in the support pipeline

• Support cannot fix bugs

• Development needs a clean, dedicated tracking system

• Leaving hundreds of “pending” bug tickets open would break the support queue

“Closed” does NOT mean “ignored.”

It means the issue has moved from support → development.

You receive an email containing the Mantis tracking ID, confirming your bug is now in engineering’s hands.

⭐ Step 5: Development Works on the Bug

The developer assigned to the bug reviews:

• the master bug report

• logs and screenshots

• any related user tickets

• reports from beta testers

Many bugs—especially the unique ones—cannot be reproduced on:

• developer machines

• support systems

• beta tester systems

✔ Some bugs only happen on a specific user’s machine

This makes those bugs:

• harder to diagnose

• harder to reproduce

• more time-consuming to fix

This is why certain issues take longer than others.

⭐ Step 6: Developer Attempts a Fix → Customer Validates the Fix

For issues that only one customer can reproduce—
the user becomes part of the verification process.

Here’s how that works:

1. The developer creates a beta build containing the attempted fix.

2. Support sends the beta build to the original customer through their support ticket.

3. The customer installs the build and confirms whether the issue is resolved.

4. Support updates the bug and the ticket status based on the customer’s feedback.

✔ If the fix works

• The Mantis record is marked as resolved

• It is included in the next maintenance release

• It is documented in the public release notes

✔ If the fix does not work

• The customer reports the failure through the same ticket

• The bug is reopened in Mantis

• The developer adjusts the fix and tries again

This cycle continues until the customer verifies the fix.

This customer-in-the-loop method is critical for unique bugs that no one else can reproduce.

⭐ Step 7: Fix Is Released & Documented

Once the fix is verified, it becomes part of the next release.

It is:

• added to the build

• tested internally and by beta testers

• listed in the published release notes

• announced in update communications

Your original report directly helps the entire HRD community.