This article explains how to submit a support request (ticket) to Heirloom Computing, how to write a ticket that gets resolved quickly, how ticket visibility works across your organization, and what to expect after a ticket is submitted.
Heirloom uses Zendesk for its support and help desk, available at https://support.heirloom.cc. For the best experience, make sure you stay signed in whenever you use the support site.
Before You Begin
Check the knowledge base first. The support site hosts all of our product documentation, FAQs, samples, and the link to raise and view tickets. Use the search bar to find articles by keyword — for example, searching for compiler returns several relevant articles. If you have a product issue, the support articles and FAQs should always be your first stop before raising a ticket. If you can't find an answer, or you need to report a product bug (including production issues), continue with the steps below.
Training (recommended). We recommend completing the official Heirloom Computing training before submitting tickets, so you can describe issues accurately and resolve them faster. To request training, use our contact form: https://heirloomcomputing.com/contact/
Registration (recommended). Registering for an account is the best way to manage your support requests. You can register through the Heirloom Dashboard. With an account you can follow up on your tickets, see their current status, and review your full ticket history. All tickets are mapped to your email address, so registering with the same email keeps everything in one place.
Submitting without registration. You can also submit a request without first creating an account by using the request form directly (see Submitting a Ticket below). When you do this:
- You will be asked to confirm your email address.
- After you confirm, you will receive your ticket number by email.
Note: Even if you submit without an account, we strongly recommend registering in the Heirloom Portal afterward (using the same email address). Registration is required to follow up on tickets and track their progress.
Organizations and Ticket Visibility
Anyone can raise a ticket. By default, a ticket is visible to the person who raised it. Beyond that, there are two ways to share ticket visibility:
- Adding people to a single ticket. If additional email addresses are added to a ticket, those people can also view it.
- Grouping tickets under an organization. We can group your tickets so that multiple people share an organization tickets view, letting colleagues see each other's tickets. Organizations can be structured however suits you — one per company, one per project, and so on.
Domain-based access. Right now, anyone signing in with an email address from a domain that belongs to an organization can view any ticket within that same organization. Users on a different email domain do not gain access automatically — they must be added to the organization manually.
To set up an organization, adjust its membership, or add users from other domains, contact your account representative and let them know how you'd like your registered emails grouped.
Submitting a Ticket
You can raise a ticket in two ways:
Via the support website (recommended):
- Open the support request form: https://support.heirloom.cc/hc/en-us/requests/new (or click Submit a request on the support home page).
- Enter a clear, concise subject and a detailed description of your request (see Writing an Effective Ticket below).
- Select the type of request. For a suspected bug, crash, or production problem, choose Incident.
- If you are reporting a product problem, be as descriptive as possible. Include the exact product name and version, step-by-step instructions to reproduce the issue, and any relevant screenshots, code, data, and log files added as attachments.
- Set the priority of your issue (see Setting the Right Priority below).
- Click Submit.
Via email: You can also raise a ticket by sending an email to support@heirloom.cc.
Setting the Right Priority
Our support system uses a four-level priority scale. The person raising the ticket is expected to set the level appropriately; we may adjust it up or down after consulting with you.
- Urgent — Production-level issues that are impacting operations.
- High — Non-production issues that must be fixed before they affect operations.
- Normal — Everyday issues found in development.
- Low — "Nice to haves," enhancement requests, or issues that would be good to resolve over the long term.
The ticket queue is monitored by our entire support and development staff across all time zones and is worked on according to priority. Please note that an issue that is not affecting a production system is not considered urgent. The priority system helps us serve everyone fairly, so please set levels honestly.
Writing an Effective Ticket
Incomplete information or several unrelated issues bundled into one ticket will slow down resolution. Please raise one issue per ticket and provide as much detail as possible up front.
A clear, concise title. Aim for something descriptive enough to make the problem area obvious, for example:
- "Production issue — IDCAMS crashes when given a non-existent file"
- "Development issue — CREATE utility is converting my file incorrectly"
A clear, detailed description. Describe the expected behavior and what you are actually experiencing. For issues in areas such as EBP or batch, please include:
- The shortest possible JCL that runs the program and/or reproduces the issue.
- Sample program code, including any procs or control cards used.
- A sample input file or database dump in a usable format.
- Outputs from the failing job.
- The EBP log file, where appropriate.
- The expected output, either as a log file or a description.
Use attachments. Code, data, and logs should be added as attachments, not pasted inline — the only exception is a very short snippet of a few lines.
We ask for cut-down samples because our engineers don't always have access to your code or machines, and even when they do, they aren't necessarily subject-matter experts on your project. A small, self-contained reproduction is far faster to diagnose than a large working codebase, and it lets teams in different time zones make progress on your issue around the clock. If a problem genuinely can't be reproduced outside your environment, that's understood — but we do expect a best-effort attempt at a locally runnable cut-down, and resolution-time expectations should be set accordingly.
What Happens After You Submit
Once submitted, your ticket enters our queue, ranked by urgency and project status, with production issues always taking priority. When an engineer is assigned and begins work, the status changes to Open.
You'll be notified by email of any replies, and you can track status at any time via the My Activities link at the top of the support page. If you and your colleagues have been grouped into an organization, this is also where you'll see your organization's tickets, along with a last activity field and any status changes.
If an engineer needs more information, they'll reply and set the ticket to Pending — you'll see this flagged in My Activities. Please keep all correspondence within the ticket, either by replying to the Zendesk emails (your replies are added to the ticket automatically) or through the support website, so all relevant information stays in one place.
When a resolution is ready, the engineer marks the ticket Pending again and provides any instructions to follow, such as new build installs or configuration changes. If that resolves the problem, reply to confirm and choose Mark as solved rather than Submit when sending your reply. A ticket may also be marked Solved directly if there are no instructions to follow. You can always reply again if needed, which automatically resets the ticket to Open. After four days in a solved state, a ticket automatically moves to Closed.
Emergency Contact
For critical issues that require immediate Heirloom development attention and cannot wait for a support engineer, there is an emergency call facility:
+1 (724) 888-5055
Because this bypasses all other priority queues, it should be used only when absolutely necessary. The line rings developers across our time zones; if no one is available, it takes a voicemail and raises a ticket from that message, which is then treated as an urgent request.
0 Comments