Software Feature and Functionality Support Ticket Guidelines

When opening a support ticket regarding a software feature, functionality, workflow, or application behavior, please provide as much relevant information as possible about the issue.

A ticket should contain enough information for a member of the support or technical team to understand:

• What you are trying to accomplish.

• Which software feature or functionality you are using.

• What steps you performed.

• What you expected to happen.

• What actually happened.

• Why you believe the behavior is incorrect or different from what was expected.

• How you determined what the expected behavior should be.

• What troubleshooting or testing you have already performed.

• Which specific example demonstrates the issue.

• Whether the behavior was previously discussed or confirmed.

Providing this information when the ticket is initially opened helps us investigate the issue more efficiently and reduces the need for multiple rounds of questions before we can begin troubleshooting.

1. Clearly identify the feature or functionality

Please specify exactly which part of the software you are referring to.

For example:

We are having an issue with the user management functionality when attempting to deactivate a user.

is much more useful than:

User management isn't working.

Where possible, include the name of the feature, module, page, screen, workflow, or functionality involved.

Examples could include:

• User management

• Reporting

• Notifications

• Search

• Import/export

• Permissions

• Dashboard functionality

• Workflow configuration

• Data entry

• Filtering

• Document management

• Billing functionality

• Account configuration

• Automated processes

If the functionality has a specific name in the application, please use the exact name displayed in the software.

2. Explain exactly what you were trying to accomplish

Please describe the goal you were trying to achieve when the issue occurred.

For example:

We are trying to create a new user and assign them the "Manager" role so that they can access the reporting section.

This gives context to the issue.

A ticket that only states:

The Manager role doesn't work.

does not tell us what the user was trying to accomplish or where in the process the problem occurred.

3. Explain the steps you took

Please provide the steps that led to the reported behavior.

For example:

1. Logged into the application.

2. Opened the User Management section.

3. Selected an existing user.

4. Clicked Edit.

5. Changed the user's role to Manager.

6. Clicked Save.

7. The application displayed a confirmation that the change was saved.

8. Logged in as the user.

9. The Reporting section was not available.

This allows us to follow the same workflow and determine where the behavior differs from what is expected.

If the issue can be reproduced, please provide the exact sequence of actions that consistently produces the result.

4. Clearly explain the expected result

Please explain what you believe should happen.

This is one of the most important parts of a feature-related support ticket.

For example:

After assigning the Manager role and saving the user, we expect the user to have access to the Reporting section.

If the expected behavior is based on documentation, requirements, a previous agreement, or something previously demonstrated by our team, please explain that as well.

5. Clearly explain the actual result

Please explain what actually happened instead.

For example:

The user was successfully saved as a Manager, but after logging in, the Reporting section is not available.

The combination of Expected Result and Actual Result makes the issue much easier to understand.

Example

Expected Result:
The user should be able to access the Reporting section after being assigned the Manager role.

Actual Result:
The user cannot see or access the Reporting section after the role has been assigned.

This provides a clear comparison that can be investigated.

6. Explain why you believe the behavior is incorrect

Please explain the reasoning behind your conclusion.

It is important to distinguish between:

"This isn't what we expected."

and:

"We believe this is incorrect because..."

For example:

We believe the user should have access to Reporting because the Manager role is described in the system documentation as having access to reporting functionality.

Or:

This behavior appears different from what was demonstrated during our previous implementation meeting, where we were shown that users assigned to the Manager role could access this section.

Or:

This functionality previously worked for the same user, and the behavior changed after the latest configuration change.

The more clearly the reasoning is explained, the easier it is for us to determine whether we are dealing with a defect, configuration issue, misunderstanding of the functionality, permissions issue, or expected system behavior.

7. Provide screenshots

Screenshots are extremely valuable when reporting issues with software functionality.

Please include screenshots that show the relevant parts of the application, such as:

• The page where the issue occurs.

• The feature being used.

• The settings or configuration.

• The information entered.

• The options selected.

• The results displayed.

• Error messages.

• Warning messages.

• Confirmation messages.

• The relevant user or record.

• The expected result, if it is visible somewhere else in the application.

• Any other information that helps demonstrate the difference between the expected and actual behavior.

For example, if you are reporting that a particular field is missing, please provide a screenshot showing where you expected the field to appear and, if applicable, another screenshot showing the same feature working differently elsewhere.

Screenshots should be clear and should contain enough information for us to understand the context.

Please ensure that sensitive information is removed or masked before screenshots are shared.

8. Provide a specific example

Whenever possible, please provide a specific example that demonstrates the issue.

For example:

User: John Smith
User ID: 12345
Role: Manager
Feature: Reporting
Issue: Reporting section is not available after assigning the Manager role.

Or:

Customer: ABC Company
Record ID: 56789
Feature: Document Upload
Issue: The document uploads successfully but does not appear in the document list.

A specific example gives the support team something concrete to investigate.

Statements such as:

"This happens for some users."

or:

"The system sometimes does not save things."

are difficult to investigate without specific examples.

If multiple records are affected, please provide several representative examples and indicate whether they all behave in the same way.

9. Explain whether the issue is consistent or intermittent

Please indicate whether the behavior:

• Happens every time.

• Happens only sometimes.

• Happens for specific users.

• Happens for specific records.

• Happens only under certain conditions.

• Recently started happening.

• Has always behaved this way.

• Previously worked and stopped working.

• Cannot currently be reproduced.

For example:

The issue occurs every time we attempt to export a report containing more than 10,000 records.

is much more useful than:

Export sometimes doesn't work.

If the issue is intermittent, please provide as much information as possible about when it occurs and when it does not occur.

10. Explain what you have already tried

Please describe any troubleshooting or testing you have already performed.

For example:

• Tried the same action with another user.

• Tried a different browser.

• Tried a different record.

• Logged out and back in.

• Cleared the browser cache.

• Repeated the process.

• Tested with different settings.

• Tested with different permissions.

• Tested in another environment.

• Compared the behavior with another user.

• Compared the behavior with another record.

• Repeated the process on multiple occasions.

Please also explain the result of each test.

For example:

We tested the same process with three different users. Users A and B can access the feature, but User C cannot. All three users have the same role.

This provides significantly more useful information than:

We tried it with other users and it still doesn't work.

11. Explain whether the functionality worked previously

If the feature worked previously, please tell us that.

For example:

This functionality was working correctly until approximately August 15. We have not intentionally changed the configuration since then.

Or:

The feature has never worked for us since implementation.

This distinction is important because a newly introduced issue may require a different investigation than functionality that has never behaved as expected.

If you know what changed before the issue appeared, please include that information as well.

12. Include relevant documentation or requirements

If your expectation is based on documentation, requirements, specifications, training materials, or another source, please provide the relevant reference.

For example:

According to the user guide, users with the Manager role should have access to Reporting.

Or:

During implementation, we were advised that this workflow would automatically send an email notification.

If possible, include the relevant documentation or screenshot.

This helps us understand the basis for the expected behavior.

13. Include previous communication

If the functionality or expected behavior was previously discussed with our team, please include the relevant communication.

This could include:

• Previous support tickets.

• Emails.

• Meeting notes.

• Implementation discussions.

• Training sessions.

• Chat messages.

• Screenshots previously provided.

• Written requirements.

• Previously confirmed functionality.

• Previous examples provided by our team.

For example:

This behavior was discussed in ticket #12345, where it was confirmed that users with the Manager role should have access to the Reporting module.

If a previous ticket already covers the same subject, please reference that ticket rather than providing the information without any context.

This is particularly important when the current ticket is based on a previous statement or confirmation.

14. Explain what you believe the software should do

When reporting a potential software defect, please clearly explain the desired behavior.

For example:

When a user selects "Save," we expect the changes to be saved and displayed the next time the record is opened.

Then explain what is happening instead:

The application displays a successful save message, but when the record is reopened, the changes are not present.

This allows us to compare the expected functionality against the actual functionality.

15. Avoid assumptions without providing the basis

Please try to distinguish between an observed fact and an assumption.

For example:

Observed:

The button is not visible for User A.

Assumption:

Therefore, the software is broken.

The first statement is something that can be investigated.

The second statement is a conclusion that requires additional context.

Instead, please explain why you believe the behavior indicates a problem:

The button is not visible for User A. User A has the same role and permissions as User B, who can see the button. The button is therefore expected to be available to User A as well.

This gives the support team the information necessary to investigate the conclusion.

16. Tell us whether other users or records are affected

If possible, please identify the scope of the issue.

For example:

The issue affects only one user.

or:

The issue affects all users with the Manager role.

or:

The issue occurs only with records created before January 1.

or:

The issue occurs for all customers in the production environment but not in the test environment.

This information can be extremely important when determining the cause of a problem.

17. Provide the environment and relevant context

Please indicate where the issue is occurring.

For example:

• Production.

• Testing.

• Staging.

• Development.

• Specific application instance.

• Specific browser, where relevant.

• Specific device, where relevant.

If the behavior only occurs under specific circumstances, please describe those circumstances.

18. What a complete feature-related ticket should contain

A good ticket should ideally answer the following questions:

Feature:
Which feature or functionality is involved?

Objective:
What were you trying to accomplish?

Steps Taken:
What did you do, step by step?

Expected Result:
What did you expect the software to do?

Actual Result:
What did the software actually do?

Reasoning:
Why do you believe the actual result is incorrect?

Evidence:
What documentation, screenshots, requirements, previous examples, or communications support your expectation?

Example:
Which specific user, customer, record, transaction, or scenario demonstrates the problem?

Scope:
Who or what is affected?

Frequency:
Does it happen every time or intermittently?

Troubleshooting:
What have you already tried?

History:
Did this functionality previously work? If so, when did it stop?

Previous Communication:
Has this functionality or expected behavior been previously discussed or confirmed?

Attachments:
Have you included the relevant screenshots and supporting information?

Example of a Well-Structured Ticket

Subject: Manager users cannot access Reporting functionality

Feature:
User Management / Roles and Permissions / Reporting

Issue:
Users assigned the Manager role are unable to access the Reporting section.

What We Are Trying to Do:
We are assigning users the Manager role so they can access reporting functionality.

Steps Taken:

1. Opened User Management.

2. Selected the user.

3. Assigned the Manager role.

4. Saved the user.

5. Logged in using the user's account.

6. Navigated to the main application menu.

7. The Reporting section was not available.

Expected Result:
The Reporting section should be available to users assigned the Manager role.

Actual Result:
The Reporting section is not displayed.

Why We Believe This Is Incorrect:
The Manager role was previously confirmed as having access to Reporting. We have also attached the relevant documentation and previous communication confirming this behavior.

Example:
User: John Smith
User ID: 12345
Role: Manager

Testing Performed:
We tested the same functionality with two other users assigned the Manager role. The same behavior occurs for all three users.

We also tested with an Administrator account, and the Reporting section is available to the Administrator.

Screenshots:
Attached screenshots show the user's assigned role, the available application menu, and the previous communication confirming the expected behavior.

Previous Communication:
This functionality was previously discussed in ticket #12345.

Additional Information:
The issue occurs consistently in the production environment.

Why This Information Is Required

These requirements are intended to make the support process faster and more efficient for everyone.

When a ticket contains only a statement such as:

"This feature isn't working."

the support team has no way of knowing exactly what was attempted, what the expected result was, what actually happened, or why the behavior is considered incorrect.

This often results in several rounds of questions before an investigation can even begin.

For example, we may need to ask:

Which feature are you using?
Which user or record is affected?
What steps did you perform?
What did you expect to happen?
What actually happened?
Can you provide an example?
Can you provide screenshots?
Is the issue reproducible?
Does it affect other users?
Did this work previously?
Why do you believe the behavior should be different?
Is there documentation supporting the expected behavior?
Was this previously discussed or confirmed?

Providing these details in the original ticket allows the support team to move directly into investigation and troubleshooting.

The basic principle

When reporting a software feature or functionality issue, please provide enough information for someone who was not present when the issue occurred to understand the entire situation.

A strong ticket should tell the complete story:

What were you trying to accomplish → Which feature did you use → What steps did you take → What did you expect → What actually happened → Why do you believe it is incorrect → What evidence supports your expectation → What specific example demonstrates the issue → What have you already tried → Has it worked previously → Was the expected behavior previously documented or confirmed?

The more complete the information provided at the time the ticket is opened, the faster we can understand, reproduce, investigate, and resolve the issue.