Support for product, platform, and technical issues

Overview

Technical support exists to help when a product, service, workflow, or environment is not behaving as expected and public guidance alone is not enough.

Good technical support requests do more than say that something is broken. They explain what happened, where it happened, what was expected, and how serious the impact is.

Technical Issue Types

Many technical issues fit into a few broad categories that affect how they should be routed.

Troubleshooting Context

Technical troubleshooting is easier when the issue is described with enough operational context.

Helpful context often includes:

• What action or workflow you were attempting
• What you expected to happen
• What happened instead
• Whether the issue is consistent, intermittent, or newly introduced
• Whether the issue affects one user, one environment, or multiple parties

What to Include

Strong technical support requests are usually specific, reproducible, and impact-aware.

Useful details may include:

• Relevant error wording or observed behavior
• Timeframe of the issue
• The product area, feature, or workflow involved
• The account or environment context, where appropriate
• Whether the issue is blocking, degraded, or informational

Provide only what is necessary to understand the issue clearly, and avoid sending unsafe secrets.

Environment and Scope

Some technical issues are local to one environment or one configuration, while others may suggest a broader platform concern.

It helps to explain whether the issue appears to affect:

• Only one account or user
• Only one environment or workflow
• Multiple features or related workflows
• A wider set of users, systems, or operational processes

Severity and Impact

Technical issues should be described in terms of real impact, not just frustration level.

Impact may be higher when:

• A production workflow is blocked
• A major customer or operational process is affected
• The issue is widespread or multi-user
• There is evidence of degraded service quality or broader instability

Before Escalating

Before escalating a technical issue, it usually helps to confirm a few basics first.

• Check whether the issue may already be explained by a status or support page
• Make sure the issue is described clearly and specifically
• Identify whether the problem is local, environment-specific, or broader in scope
• Use escalation when the impact or unresolved nature of the issue genuinely warrants it

Next Steps

After reading this page, most visitors should do one of the following:

• Email support@psydata.net or help@psydata.net with technical context
• Use Escalation Paths for unresolved or high-severity technical issues
• Use Support Hours if timing and response expectations matter to your issue