Support & Escalation

Overview

Documentation works best when it answers common and repeatable questions clearly. Support works best when a question depends on your specific context.

This page is designed to help readers decide which route is appropriate, avoid unnecessary delay, and send questions to the right channel the first time.

When to Use Support

Support is usually the right choice when your question depends on:

• Your actual environment or deployment context
• Your account state, access level, or permissions
• A real workflow that is not behaving as expected
• An integration scenario with implementation-specific detail
• A time-sensitive operational concern
• A situation where the docs do not clearly answer the question

When to Use Docs First

Documentation is usually the fastest first step when you need:

• Platform orientation
• High-level API posture and conventions
• Accounts and access guidance
• Security and privacy reference context
• Release visibility and public change tracking
• Quick answers to common questions

If the docs answer your question completely, self-service is usually the fastest path.

Routing Model

The public documentation site uses a simple routing model so readers can separate documentation issues from operational support needs.

Escalation Principles

Escalation should generally happen when a request cannot be resolved through documentation alone or when the issue involves higher sensitivity, urgency, or environment-specific operational context.

Readers should assume that escalation may involve:

• Clarification of account or environment context
• Routing to a more appropriate operator or function
• Additional review for trust, security, or operational sensitivity
• Structured follow-up where documentation alone is insufficient

How to Make Good Requests

Support outcomes are usually better when requests are clear, specific, and contextual.

Helpful requests often include:

• The page or documentation area you already checked
• A short description of the question or problem
• The environment or workflow involved, if relevant
• What you expected to happen
• What actually happened instead
• Any urgency or operational impact you believe applies

Documentation Feedback

Not every issue is a support issue. If the content is unclear, outdated, incomplete, or hard to navigate, that should usually be treated as documentation feedback.

Documentation feedback may include:

• Broken links or navigation problems
• Missing examples or missing context
• Inaccurate wording or unclear explanations
• Requests for better structure or additional reference pages

Operational Boundaries

Public documentation and public support routes may not be the right place for every request.

Readers should avoid assuming that public support channels can immediately handle:

• Confidential contractual questions
• Privileged security disclosures
• Sensitive data submissions
• Requests requiring private customer-specific context not yet shared appropriately

In those situations, support may still be the first route, but the issue may need controlled internal routing.

Next Steps

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

• Return to the relevant documentation page if the issue is already answered there
• Email docs@psydata.net for documentation quality or reference issues
• Email support@psydata.net for operational or context-specific questions
• Review the FAQ if you need a quicker clarification first