Support

This page explains how support for Minyu works, who may contact support, what is covered, what is out of scope, and how issues should be reported so that we can help you as efficiently and fairly as possible.

Our goal is to provide high-quality, predictable support for everyone, while keeping response times short and investigations focused.

1. Designated Support Contact (Mandatory)

Each customer organization must designate one system administrator as their official support contact.

Only this administrator may:

Submit support tickets
Communicate with Minyu support
Receive technical responses
Follow up on investigations and fixes

All internal support within your organization is handled by your own administrator. Minyu does not provide direct end-user support.

This structure ensures:

Clear and consistent communication
Technically precise questions
Faster handling
Less noise and duplication

2. Support Scope

Support covers Minyu functionality and product defects only, including:

How to use the Minyu product
How existing Minyu functionality behaves
User interface behavior
Errors, crashes, and system malfunctions
Verifiable platform defects

Anything outside of this scope is not covered by support. This includes best practices, design advice, and domain-specific guidance.

Examples of requests that are not covered include:

“What is the best way to structure our database?”
“How should we design our domain model?”
“Is this a good table structure for our business?”
“How should we model our classifications and rules?”
“How should we design our workflows?”
“How should we organize permissions in our organization?”
“Can you review our setup and suggest improvements?”
“How should Minyu be used in our specific industry?”
“How do we integrate Minyu with system X or service Y?”
“Can you explain database design, system architecture, or general IT concepts?”

These types of questions involve design responsibility, business decisions, or external systems, and therefore fall outside standard product support.

3. Reporting Issues and Bugs

Some problems are immediately clear to us — for example when the system visibly fails, returns explicit errors, or a function clearly does not complete as expected. These cases can often be investigated directly.

Other reports describe behavior that appears incorrect or unexpected without producing a clear fault. In these situations, the initial description alone may not be sufficient for us to determine what is occurring.

Since we cannot inspect customer data for privacy and GDPR reasons, we may need you to reproduce the problem using test data in a controlled environment.

When required, we may ask you to provide:

A simplified example in a clean test environment
Clear, step-by-step instructions showing how the issue occurs
A description of what you expected to happen and what actually happened
Only test data, never real or sensitive data

If, after reasonable clarification, the issue still cannot be reproduced:

It is treated as a configuration-specific issue
And is considered outside the scope of standard support

These guidelines allow us to respect data protection requirements while still investigating real product defects efficiently and fairly.

Customer data is always treated as restricted:

Support does not access real tenant data by default
Any access requires a lawful basis
Only the minimum necessary data may be processed

This protects both customer privacy and support quality.

5. Support Process

All support is handled via tickets only
All support communication is handled in English only
Each ticket must concern one clearly defined issue
If a ticket contains multiple unrelated topics, we may ask that it be split

This structure allows us to keep support predictable and fair for all customers.

6. Support Contact Emails

Minyu uses two separate support channels to ensure that issues are handled by the right team as quickly as possible.

General Support

For questions about product usage, functionality, and UI behavior:

Use this address for:

How Minyu features work
UI behavior questions
Clarification of documented functionality

Malfunctions & Bugs

For technical failures, crashes, and suspected defects:

Use this address for:

System crashes
Errors and malfunctions
Suspected platform defects
Failed operations with error output

Using the correct address helps us prioritize and route your issue correctly from the start.

7. Response Handling & Time Expectations

All valid tickets will receive a response
Responses are normally provided within a few hours up to one business day
Critical system defects are prioritized ahead of general questions

An initial response does not always mean that the issue is resolved. Some cases require deeper investigation.

No fixed resolution time is guaranteed, but:

Reproducible defects will always be investigated
Verified defects will be scheduled for correction

8. Ticket Closure Policy

If we request clarification or additional information and no response is received:

The ticket may be closed after a reasonable period of inactivity
Closed tickets may be reopened by submitting the requested information

This ensures that unresolved cases do not remain open indefinitely.

9. Planned vs Unplanned Work

Not all verified issues result in immediate fixes.

Critical defects may be corrected with priority
Other confirmed issues may be scheduled into a future planned release

Verification of a defect does not automatically imply an immediate correction.

10. Severity Levels

Reported issues may be categorized internally based on impact, for example:

Critical – System unavailable or data at risk
Major – Core functionality unusable
Minor – Limited impact or workaround exists

Severity influences investigation and correction priority.

11. Change Requests vs Bugs

Functionality that behaves according to current design is not considered a defect.

Requests for new behavior
Improvements
Enhancements

Are treated as change requests, not bugs, and are therefore outside standard product support.

12. Maximum Number of Open Issues

To ensure fast and high-quality support for everyone, each organization may have a limited number of open support tickets at the same time.

A maximum of three (3) open tickets is allowed per organization
Once a ticket is closed, a new one may be submitted
This encourages:
Clear prioritization
Faster handling of the most important issues
Fair access to support for all customers

If the maximum is reached, additional tickets may be queued until an existing ticket is resolved.

13. Fair Use & Support Load Control

To ensure good support quality for everyone:

Repeated out-of-scope requests may lead to reduced support priority
Misuse of the support channel may result in:
Temporary throttling, or
Suspension of support access

These measures exist solely to protect overall support quality and system stability.

14. Feature Requests

We are always interested in understanding which improvements and new capabilities would be most valuable in real use.

Feature requests are not handled through the support channels and are not part of standard support, but you are very welcome to share ideas, suggestions, and wishes for future versions of Minyu.

Please send feature requests to:

We review these messages regularly to help guide long-term product development, but cannot promise individual timelines or outcomes for specific requests.

If you ever have questions about how to use the support channel correctly, your designated system administrator is the right place to start.