Return / Service Reasons

Configuring Return Reasons in returns.cloud

Return Reasons define why a customer wants to return an item or report an issue with it. In the returns.cloud data model, these reasons are represented as Service Reasons.

A well-structured Return Reason configuration helps customers select the correct reason, provides Customer Service with useful information, and creates consistent data for reporting and integrations.

How Return Reasons are structured

Return Reasons are configured through an inheritance model:

Global configuration → Your instance → Service Portal

Configuration is inherited from one level to the next. This makes it possible to maintain common settings centrally while still adapting individual reasons where required.

Global configuration

The global configuration is maintained by Trusted Returns.

It contains the default Return Reasons provided with returns.cloud, including their standard names, translations, and general configuration.

These defaults provide a common starting point. You do not need to create every common reason yourself and can use or adapt the predefined reasons in your instance.

Your instance

Your instance inherits the Return Reasons defined globally.

This is the recommended level for maintaining your general Return Reason setup. Here, you can:

• enable or disable inherited reasons
• change names and translations
• configure one-line text input
• configure multi-line text input
• configure media uploads
• define whether additional input is optional or required
• create Custom Return Reasons

Only reasons that are enabled in your instance can subsequently be used in your Service Portals.

The configuration maintained here is inherited by your Service Portals.

Service Portal

Each Service Portal inherits the active Return Reasons and their configuration from your instance.

Portal-level configuration applies only to the respective Service Portal and its Sales Channel. A Sales Channel is the platform context used to separate portals, brands, integrations, and data.

On the Service Portal level, you can configure portal-specific behavior, including:

• when a reason is available
• whether it is available to customers
• whether it is available internally in the Management Portal
• which Service Actions it applies to
• deviations from inherited settings

This allows the same general Return Reason configuration to be used across several portals while still supporting different requirements for individual brands, countries, or Sales Channels.

How inheritance works

As long as a setting is inherited, changes made on the preceding level are passed down automatically.

For example:

1. Trusted Returns provides a default Return Reason globally.
2. Your instance inherits its name, translations, and input settings.
3. Your Service Portal inherits the active configuration from your instance.

You can override inherited values where necessary. Once a setting is changed locally, that particular value no longer follows the inherited configuration.

The configuration interface shows the inherited original value alongside locally configured values. The Reset function can be used to restore the inherited configuration.

This makes it possible to keep the standard configuration wherever it fits your requirements and introduce deviations only where they are actually needed.

Why does returns.cloud provide default Return Reasons?

returns.cloud includes a predefined set of Return Reasons on the global level.

These reasons provide a consistent basis for common return and service scenarios and reduce the amount of configuration required when setting up your instance.

Default reasons help to:

• provide commonly required Return Reasons out of the box
• reduce initial configuration effort
• provide standard translations
• maintain consistent meanings
• establish a stable basis for integrations

You can decide which of these reasons are relevant for your processes by enabling or disabling them in your instance.

You can also adapt inherited settings without changing the original global definition.

What are Custom Return Reasons?

Custom Return Reasons are additional reasons that you create in your instance when the predefined reasons do not adequately represent your business requirements.

Examples might include:

• Assembly was not possible
• Product is not compatible with the intended device
• Packaging does not meet expectations
• Color differs from the product presentation
• A component is missing

Custom Return Reasons should normally be created and generally configured in your instance. They can then be inherited by all relevant Service Portals.

This avoids maintaining the same reason separately for multiple portals.

Before creating a Custom Return Reason, check whether an existing reason already represents the same business meaning. Several very similar reasons make the selection more difficult for customers and can reduce the quality of your reporting.

For example, avoid maintaining all of the following if they represent the same issue in your process:

• Product broken
• Product defective
• Product does not work

Using hierarchical and fourth-level Return Reasons

Return Reasons can be structured hierarchically. A general Return Reason can contain more specific child reasons.

For example:

Technical defect

• Does not start
• Does not heat
• Does not cool
• Display does not work
• Makes unusual noises

This additional level is referred to as a fourth-level Return Reason.

The parent reason can hold the common configuration for the entire group. Its child reasons inherit these settings, so you do not need to maintain the same configuration separately for every individual reason.

For example, the parent reason can define whether additional text or media is required and its children can inherit this behavior.

This structure is useful when you want both:

• a general classification for reporting or processing
• a more precise description of the customer's actual issue

Instead of creating several unrelated technical reasons, you can group them under one common parent reason.

If a particular child reason requires different behavior, its inherited settings can be overridden individually.

Requesting additional information

A Return Reason can request additional information when it is selected.

You can configure:

• one-line text
• multi-line text
• media uploads

These inputs can be optional or required.

One-line text

Use a one-line text field for short additional information, for example:

• affected component
• missing part
• short description of the issue

A placeholder can be used to tell customers or Customer Service what information should be entered.

The input can be enabled and configured as required separately for the Management Portal and Self-Service Portal.

Multi-line text

Use a multi-line text field when a more detailed description is useful.

Examples include:

• description of a defect
• explanation of how the issue occurred
• additional information needed by Customer Service

The field can also be optional or required depending on where the Return Reason is used.

Media upload

Media uploads can be requested when visual information is useful for processing the case.
There is a maximum upload file size of 128 MB.

Examples include:

• a photo of a damaged product
• a photo of damaged packaging
• an image showing a serial number
• visual evidence of a defect

You can configure:

• whether media upload is enabled
• whether an upload is required
• the minimum number of uploads
• the maximum number of uploads

Requirements can differ between the Management Portal and Self-Service Portal.

Only make additional inputs mandatory if the information is actually needed. Every required field adds another step to the process for the customer.

Controlling when a Return Reason is available

The time period in which a Return Reason is available is configured on the Service Portal level.

A reason can be made available:

• within the withdrawal period
• after the withdrawal period but within the warranty period
• after the withdrawal period and after the warranty period
• for bounced shipments

These settings must be configured for each Return Reason on the respective Service Portal.

For example, a reason such as Product was imagined differently may only be relevant within the withdrawal period, while Technical defect may also be relevant within the warranty period.

This portal-level configuration allows the same reason structure to support different business processes.

Controlling who can select a Return Reason

On the Service Portal level, you also define where a Return Reason is available.

A reason can be:

• available to customers in the Self-Service Portal
• available internally in the Management Portal
• available in both contexts

This makes it possible to maintain internal reasons that Customer Service can use without displaying them to customers.

Conversely, every reason that customers need during self-service must be enabled for the customer-facing context in the respective Service Portal.

Assigning Return Reasons to Service Actions

Return Reasons can also be assigned to specific Service Actions.

Service Actions represent the action performed within a Service Order, for example Return, Refund, Partial Refund, or Exchange.

This allows you to make a reason available only where it makes sense for the selected process.

For example, a particular Return Reason can be configured specifically for the Return action.

The available assignments depend on the Service Actions configured for your setup.

Showing reasons only for relevant products

Business logic can be used to control which Return Reasons are shown for particular items or product categories. Request that via [email protected].

This is especially useful when using detailed child reasons.

For example:

Technical defect

• Does not heat
• Does not cool

Both reasons belong to the same general category, but they are not meaningful for every product:

• Does not heat may be relevant for a grill but not for an ice-cream maker.
• Does not cool may be relevant for an ice-cream maker but not for a grill.

Business logic can map the appropriate reasons to the relevant product categories so that customers only see choices that make sense for the selected item.

This keeps the selection concise and improves the quality of the information collected.

When using this logic, consider:

• which reasons are relevant for each product category
• which reasons must be excluded
• whether new product categories require an updated mapping
• whether child reasons need more specific rules than their parent reason

The Return Reason hierarchy and its general configuration remain separate from this product-specific business logic.

Randomizing the display order

The order in which Return Reasons are displayed to customers can be randomized.

This is configured on the relevant Reason Category.

Randomization helps prevent a common selection bias: if the same reason is always displayed first, customers may select it more frequently simply because of its position rather than because it accurately describes their situation.

Randomizing the order can therefore:

• reduce position-based selection bias
• improve the quality of Return Reason data
• provide more reliable reporting
• prevent one reason from being selected disproportionately because it is always shown first

A randomized order is particularly useful when the reasons within a category have equal importance.

A fixed order may be more appropriate when the sequence itself is relevant to the process.

Return Reasons and integrations

Connected shops, marketplaces, ERP systems, and other platforms may use their own Return Reasons.

These systems often use different codes or terminology for the same business meaning.

For example:

The external value therefore needs to be mapped to the corresponding Return Reason in returns.cloud.

This mapping is maintained in the relevant integration and is separate from the configuration of the Return Reason itself.

Plan Return Reasons with future integrations in mind

Consider future integrations when creating Custom Return Reasons.

A Return Reason should describe a general business meaning rather than the terminology or code of a particular external system.

Avoid reasons such as:

• Amazon reason 12
• Shopware damaged
• ERP return code B

Prefer reasons such as:

• Product arrived damaged
• Wrong product delivered
• Product not compatible

The integration can then map its own external codes to these reasons.

This allows several connected systems to use the same central Return Reason without creating duplicate reasons for every integration.

Stable identification is also important across separate environments. returns.cloud uses Technical Names to identify equivalent configurations such as Service Reasons across environments where their internal IDs may differ.

Recommended configuration approach

A maintainable setup starts with the general configuration in your instance and uses the Service Portal level for portal-specific requirements.

1. Review the default Return Reasons provided by Trusted Returns.
2. Enable the reasons that are relevant to your processes.
3. Disable reasons that you do not need.
4. Adapt names and translations where required.
5. Configure one-line text, multi-line text, and media requirements.
6. Create Custom Return Reasons only where the defaults do not cover your requirements.
7. Use fourth-level child reasons where a more detailed classification provides additional value.
8. Configure shared settings on the parent reason so that its children can inherit them.
9. Open each relevant Service Portal and review the inherited active reasons.
10. Configure when each reason is available.
11. Define whether each reason is available to customers, internally, or both.
12. Assign the relevant Service Actions.
13. Add product-specific business logic where reasons should only apply to particular items or categories.
14. Decide whether the Reason Category should use a fixed or randomized display order.
15. Override inherited settings only where a portal-specific deviation is required.
16. Configure mappings for Return Reasons received from connected systems.

This keeps general configuration centralized while still allowing each Service Portal and Sales Channel to implement the rules required for its specific process.

Best practices

Keep your general Return Reason configuration in your instance and use portal-level overrides only when they are needed.

Return Reasons should:

• use clear, customer-facing wording
• represent one distinct issue
• avoid overlapping meanings
• remain stable over time
• provide useful reporting data
• be suitable for mapping values from external systems
• request only information that is actually required

For hierarchical reasons, keep common settings on the parent reason and use child reasons only when the additional detail provides operational or analytical value.

For product-specific configuration, make sure that customers only see reasons that are relevant to the selected product. Review this logic when your product categories or Return Reason structure change.

For display order, consider randomization when all reasons have equal relevance and a fixed order could bias customer selections.

The goal is not to provide as many Return Reasons as possible. The goal is to provide the smallest useful set of clear choices that gives your customers an intuitive process and provides your teams with reliable, actionable data.

The terminology and structure also follow the current project documentation: Knowledge Base content should be user-oriented and actionable, and returns.cloud uses Service Reason as the data-model term for a reason associated with a return, complaint, or other service case.