Email Communication and Templates

Every withdrawal triggers legally relevant email communication with the customer. returns.cloud sends these emails automatically based on three templates that you can configure per widget, with your own branding and your own sender setup. This article explains what each template does, which legal requirements are covered for you, and what you can customise.
Please note: This article summarises legal requirements for orientation purposes only. It is not legal advice. If you need advice on your individual obligations, we recommend consulting a lawyer.

Why these emails matter legally

Section 356a paragraph 4 BGB obliges you to confirm receipt of a withdrawal without delay on a durable medium, for example by email. The confirmation must contain the content of the withdrawal declaration as well as the date and time of receipt.

returns.cloud covers this obligation automatically: the receipt confirmation is generated and sent for every submitted withdrawal, without any manual action by your team. In addition, the status emails keep the customer informed about the outcome of the case, which reduces inquiries to your customer service.

The three templates

Each withdrawal widget has its own set of three email templates.

1. Receipt confirmation

  • Sent automatically and immediately after the customer confirms the withdrawal in step 2 of the widget.
  • Contains the content of the withdrawal declaration (name, contract reference, email, and the reason if the customer provided one) plus the date and time of receipt, as required by law.
  • Is sent for every submission, regardless of whether the case could be matched to an order automatically or goes into the manual queue.

2. Successful assignment

  • Sent when a withdrawal case has been assigned to an order, informing the customer that the withdrawal has been accepted and the case is being processed.
  • Relevant in particular for cases from the manual queue: after your team matches the case to an order, the customer receives this confirmation.

3. Rejection

  • Sent when a withdrawal case is rejected, either automatically (duplicate submission, withdrawal period expired) or manually by your team.
  • The email text adapts dynamically to the rejection reason, so the customer always understands why the withdrawal was not accepted. For example, a rejection due to an expired period states the date on which the statutory withdrawal period ended.

Branding and theming

The withdrawal emails use the same branding and theming approach as your returns portal emails: logo, colors and layout follow your existing email design, so the customer experiences one consistent brand across the whole post purchase communication. Important: The E-Mail Layout has to be posted under "E-mail Layout" in E-Mail Templates for every supported langauge.

Sender and SMTP configuration

Each widget has its own sender and SMTP configuration, analogous to the returns portal:

  • Configure the sender name and sender address that the customer sees.
  • Optionally use your own SMTP server so the emails are sent through your infrastructure and pass your SPF/DKIM setup.

Tip: Use a sender address the customer recognises (for example the same domain as your shop). Withdrawal emails have legal relevance, and emails from unknown senders are more likely to end up in spam folders.

Good to know

Next steps

  1. Processing Withdrawal Cases
  2. Self-Service Portal Handover
  3. Activity Log and Data Retention
  4. Reference: Configuration Parameters, Statuses and Rejection Reasons