Service Level Agreement (SLA)
This is a courtesy translation. The German original is the legally binding version: Service-Level-Vereinbarung.
Here you'll find what we commit to regarding support and the availability of DolmiDesk – and what happens if we do not keep a commitment.
Last updated: 2 October 2026
Scope and relationship to the T&Cs
1.1 This Service Level Agreement (SLA) supplements the Terms and Conditions (T&Cs) of DolmiDesk. It forms part of the contract for the Standard and Pro plans and applies from the conclusion of the contract, i.e. also during the free trial period (Clause 3.3 of the T&Cs).
1.2 Anyone who books the Pro plan by personal invitation at the beta price under Clause 6 of the T&Cs (Clause 3.4 of the T&Cs; contract at the beta price) receives the commitments for Pro. The Beta Terms apply in addition. Clause 10.1 applies to preview features.
1.3 This SLA does not apply to the Start plan. In the Start plan, we commit to no availability and no response time, and no credits arise. We are nevertheless glad to receive bug reports via the contact form. We handle security incidents and data protection matters without undue delay in every plan under Clause 2.2 of the T&Cs, including Start and independently of this SLA; Clause 7 describes how we proceed.
1.4 Anything this SLA does not govern is governed by the T&Cs. Your statutory rights remain unaffected; Clause 8.8 governs how credits are offset against statutory claims.
Definitions
2.1 Service hours are Monday to Friday from 9:00 to 17:00 (Europe/Berlin time zone). Excluded are the public holidays in Hesse – we are based in Frankfurt am Main – as well as 24 and 31 December. Public holidays in Hesse are currently: New Year's Day, Good Friday, Easter Monday, 1 May, Ascension Day, Whit Monday, Corpus Christi, 3 October, and Christmas Day and Boxing Day.
2.2 A business day in this SLA is any day with service hours, i.e. Monday to Friday excluding the days under Clause 2.1. Unlike the German everyday term "Werktag", Saturday is not a business day.
2.3 A ticket is a request to our support via one of the two channels under Clause 3.1.
2.4 The first response is the first substantive reply from a person on our support team to your ticket – for example a solution, a targeted follow-up question, or an assessment with the next step. The automatic acknowledgement of receipt is not a first response.
2.5 Availability is the share of a calendar month during which the application at app.dolmidesk.com can be reached. Announced maintenance windows are excluded from the calculation (Clause 6).
2.6 A maintenance window is a period during which we carry out scheduled maintenance of the application and which we have announced in advance under Clause 6.5.
How support and tickets work
3.1 Channels. You can reach our support in two ways:
- Contact form in the app (preferred): profile at the bottom left → Contact. Your name, email address, and account ID are sent along automatically, so we can match your account right away.
- Email to support@dolmidesk.com. Please write from the email address you use to sign in to DolmiDesk.
Only requests via these two channels are tickets within the meaning of this SLA and trigger the deadlines under Clause 5.
3.2 Acknowledgement of receipt. If you send us a request via the contact form, you receive an automatic acknowledgement of receipt by email. If it does not arrive, your request may not have reached us. Please check your spam folder and, if in doubt, write to us again by email. For requests by email, we currently do not send an automatic acknowledgement of receipt. In both cases, the deadline under Clause 5 runs from the moment the request reaches us (Clause 5.2).
3.3 A good ticket saves a round of follow-up questions. Helpful are:
- what you did (which area, which button),
- what you expected and what happened instead,
- when it happened – an approximate time is enough,
- the number of the affected assignment, invoice, or cost estimate,
- a screenshot of the spot. Please black out names, addresses, and amounts we do not need for the analysis.
Please send us only as much personal data of your clients as is necessary to resolve the matter.
3.4 Priority. We set the priority of each ticket according to the criteria in Clause 4. You can suggest a priority in your ticket, for example "P1" in the subject line. We tell you the priority we have set with the first response. If the situation changes – for example because a problem gets worse – we adjust the priority. If you disagree with the classification, tell us in the ticket.
3.5 After the first response.
- Status updates: For P1, we get in touch at least on every business day until the problem is solved or a workaround exists. For P2 and P3, we get in touch as soon as there is news.
- Collective message: If a disruption affects all or many accounts, the first response may also be given as a joint message to everyone affected, by email or within the app.
- Closing: We close a ticket when your question has been answered, the problem has been solved, or a permanent workaround has been agreed, and we tell you so. If a follow-up question from us remains unanswered for 14 days, we also close the ticket.
- Reopening: If the problem occurs again, simply reply to our last email about the ticket. We then continue the ticket with its previous history. The deadline under Clause 5 applies again to the response to your new message.
3.6 Language. Support works in German. On request, we also reply in English. The language of the contract remains German (Clause 14.4 of the T&Cs).
Priorities
4.1 Every ticket receives one of four priorities:
| Priority | When | Examples |
|---|---|---|
| P1 Critical | The application cannot be reached, signing in is impossible, invoices cannot be created or sent, or there is a suspicion of data loss or a security incident. | You cannot sign in although your password and second factor are correct. You cannot create or send an invoice. An invoice has suddenly disappeared. You see data that does not belong to your account. |
| P2 High | An important feature is disrupted, but a workaround exists. | The calendar import fails, but assignments can be created by hand. The route calculation returns no travel time, but you can enter it by hand. The automatic dunning run sends nothing, but the reminder can be sent by hand. |
| P3 Normal | Questions and minor bugs. | A question about the template, such as how to change the closing text of your invoice. A question about setting up a billing model. A list sorts incorrectly, or a text is translated incorrectly. |
| P4 Request | Requests for new or changed features. | A request for a new feature, such as connecting another calendar. |
4.2 A suspected security incident is always P1. Clause 7 applies in addition.
4.3 There is no response deadline for P4. We collect and evaluate requests for the further development of DolmiDesk; they do not establish any entitlement to implementation.
Response times
5.1 The commitments per plan at a glance:
| Start | Standard | Pro | |
|---|---|---|---|
| Channels | Handbook and FAQ; bug reports via the contact form | Contact form and email | Contact form and email |
| First response for P1 to P3 | no commitment | within 3 business days | within 24 hours, counted on business days only |
| First response for P4 | no commitment | no commitment | no commitment |
| Order of handling | no commitment | by priority and receipt | ahead of Standard tickets of the same priority |
| Personal onboarding | – | yes | yes |
| One-time data migration | – | yes | yes |
| Credit per missed first response | – | 5% | 10% |
5.2 How we count the deadline. The deadline starts when the ticket reaches us. What counts is the timestamp at which the contact form or the email reached us – regardless of whether the acknowledgement of receipt was sent. Only hours that fall on a business day count. Weekends, public holidays, and 24 and 31 December are skipped. If a ticket arrives on a day that is not a business day, the deadline starts on the next business day at 0:00.
- Pro: 24 such hours. In practice, this means: at the latest on the next business day at the same time.
- Standard: 3 business days, i.e. 72 such hours. In practice, this means: at the latest on the third following business day at the same time.
| Ticket arrives | Pro: first response at the latest | Standard: first response at the latest |
|---|---|---|
| Friday, 16:00 | Monday, 16:00 | Wednesday, 16:00 |
| Tuesday, 10:30 | Wednesday, 10:30 | Friday, 10:30 |
| Saturday, 11:00 | Monday, 24:00 | Wednesday, 24:00 |
| Maundy Thursday, 14:00 | Tuesday after Easter, 14:00 | Thursday after Easter, 14:00 |
5.3 No resolution time. We commit to a time for the first response, but not to a time until resolution – some bugs can be fixed in minutes, others take days. Instead, the following targets apply; missing them does not trigger a credit:
- P1: We start work immediately within service hours and report the status at least on every business day.
- P2 and P3: We handle tickets by priority and receipt; in the Pro plan, ahead of Standard tickets of the same priority.
5.4 There is no on-call service outside service hours. If the application has failed completely, our monitoring notices this even without a ticket; such an outage always counts against availability under Clause 6, including at night and at weekends.
Availability
6.1 Targets. We commit to the following availability per calendar month (Europe/Berlin time zone):
| Plan | Availability per calendar month | In a month with 30 days, this corresponds to at most about |
|---|---|---|
| Start | no commitment | – |
| Standard | 99.0% | 7 h 12 min of outage |
| Pro | 99.5% | 3 h 36 min of outage |
6.2 Measurement. An external monitoring service checks a status endpoint of the application at app.dolmidesk.com every 60 seconds. This endpoint reports success only if the application and its database respond. A check fails if no successful response arrives – for example in the case of an error message or a timeout.
6.3 Outage. An outage exists only if two consecutive checks fail. It begins with the first of these failed checks and ends with the next successful one. A single failed check does not count.
We calculate the availability of a month as follows:
Availability in % = (minutes of the month − minutes of announced maintenance − outage minutes) ÷ (minutes of the month − minutes of announced maintenance) × 100
On request, we tell you the measured availability of a month and the individual outages with their start and end.
6.4 What counts – and what does not.
The following in particular count as an outage:
- bugs in our application, faulty updates, and outages of our own infrastructure,
- outages of our hosting provider (Scaleway) – we chose this provider, so we answer for it,
- maintenance that exceeds the limits under Clause 6.5 or was not announced in time,
- emergency security updates that take longer than 30 minutes (Clause 6.6).
The following do not count as an outage:
- announced maintenance windows within the scope of Clause 6.5,
- disruptions of third-party services that you connect or that we merely integrate: Google Calendar, Google Maps (route and travel time calculation), the email delivery service, Stripe (payment processing),
- disruptions of your own internet connection, your devices, or your browser,
- force majeure.
If the application works but a connected third-party service does not, this does not reduce availability. Please report it to us anyway – we treat it as a ticket under Clause 4 and help you with a workaround.
6.5 Maintenance windows. We announce scheduled maintenance at least 48 hours in advance by email or within the app. It comprises at most 4 hours per calendar month and, where possible, takes place on Sundays between 20:00 and 24:00. Maintenance beyond 4 hours per month or without timely announcement counts as an outage.
6.6 Emergency security updates. If an urgent security update closes an acute vulnerability, we install it even without an announcement. If it takes longer than 30 minutes, its entire duration counts as an outage. We inform you of the reason afterwards.
Security incidents and data protection (all plans)
7.1 We handle security incidents and matters concerning our obligations under the DSGVO (GDPR) without undue delay in all plans, including Start, under Clause 2.2 of the T&Cs and independently of the other commitments of this SLA. This clause describes how we proceed.
7.2 Reporting a suspicion. If you suspect a security incident – for example a sign-in that was not yours, or data that does not belong to your account – please report it immediately via the contact form or to support@dolmidesk.com with the word "Sicherheitsvorfall" (security incident) in the subject line. We treat it as P1 and handle it without undue delay, without using up the deadlines under Clause 5.
7.3 As a processor. To the extent that we process personal data on your behalf, we inform you without undue delay after becoming aware of a breach of the security of this data (Art. 33(2) DSGVO). This enables you to meet your own obligation to notify the supervisory authority within 72 hours (Art. 33(1) DSGVO). We also support you with your obligations under Art. 32 to 36 DSGVO and with requests from data subjects (Art. 28(3)(e) and (f) DSGVO). The details are governed by the data processing agreement (Clause 12.2 of the T&Cs).
7.4 As a controller. To the extent that we are the controller ourselves – for example for the data of your user account – we fulfil our obligations under Art. 33 and 34 DSGVO and inform you if you are affected.
Credits
8.1 Principle. If we miss the availability target or the deadline for the first response, you receive a credit. It amounts to a percentage of the monthly fee for the calendar month concerned.
8.2 The monthly fee is the net fee of your plan for one month:
- with monthly billing, the monthly fee,
- with annual billing, one twelfth of the annual fee,
- for contracts at the beta price, the beta price actually paid (currently €59 per month or one twelfth of €590 per year).
No fee is charged for the free trial period (Clause 3.3 of the T&Cs); therefore no credits arise from it. If only part of a calendar month falls within the trial period, the monthly fee is reduced pro rata by the days of the trial period.
8.3 Credit for missed availability. What counts is the tier into which the measured availability of the month falls; the tiers are not added together. The hour values are for illustration only – the percentage under Clause 6.3 is decisive.
Standard
| Availability in the month | Outage at 30 days, about | Credit |
|---|---|---|
| 99.0% or more | up to 7 h 12 min | none – target met |
| 98.0% to below 99.0% | more than 7 h 12 min up to 14 h 24 min | 10% |
| 95.0% to below 98.0% | more than 14 h 24 min up to 36 h | 25% |
| below 95.0% | more than 36 h | 50% |
Pro (including at the beta price)
| Availability in the month | Outage at 30 days, about | Credit |
|---|---|---|
| 99.5% or more | up to 3 h 36 min | none – target met |
| 99.0% to below 99.5% | more than 3 h 36 min up to 7 h 12 min | 10% |
| 97.0% to below 99.0% | more than 7 h 12 min up to 21 h 36 min | 25% |
| below 97.0% | more than 21 h 36 min | 50% |
8.4 Credit for a missed first response. For every ticket of priority P1 to P3 that does not receive a first response within the deadline under Clause 5, you receive:
| Plan | per missed first response | maximum per month from missed responses |
|---|---|---|
| Standard | 5% | 25% |
| Pro | 10% | 25% |
Several tickets on the same matter count as one ticket.
8.5 Cap. All credits of a calendar month together amount to at most 50% of the monthly fee.
8.6 How to request a credit.
- Open a ticket (contact form or email) within 30 days after the end of the month concerned. State the month and, if known, the tickets or periods concerned.
- We review your request using the data from the monitoring and from the tickets and inform you of the result.
- We offset the credit against your next invoice. A payout is excluded – with one exception: if the contract ends, we refund any credit still outstanding.
8.7 Worked examples.
| Case | Monthly fee | What happened | Credit |
|---|---|---|---|
| Pro, monthly | €99.00 | Availability 98.7% | 25% = €24.75 |
| Standard, monthly | €59.00 | Availability 98.5% (10%) and one missed first response (5%) | 15% = €8.85 |
| Pro, annual (€990) | €82.50 | Three missed first responses: 30%, capped at 25% | 25% = €20.63 |
| Beta (Pro at €59) | €59.00 | Availability 96.0% (50%) and two missed first responses (20%): 70%, capped at 50% | 50% = €29.50 |
8.8 Relationship to statutory claims. Credits are offset against statutory claims arising from the same event, in particular against price reduction (Minderung) and damages. Further-reaching statutory rights remain unaffected.
Extraordinary right of termination
9.1 If we miss the availability target of your plan in three consecutive calendar months, you can terminate the contract with immediate effect. You declare the termination in text form (e.g. by email to support@dolmidesk.com).
9.2 We refund fees paid in advance for the period after the end of the contract on a pro-rata basis. Credits already accrued are retained and are refunded as well.
9.3 The right to extraordinary termination for good cause (Clause 4.3 of the T&Cs) remains unaffected.
Exclusions
10.1 This SLA does not cover:
- tax or legal advice – for example whether a service is exempt from VAT or how the JVEG applies in a particular case (see Clause 2.4 of the T&Cs),
- individual developments or customizations only for your account,
- problems that lie in your own systems or input – for example in your device, browser, network, or email inbox, in the setup of your calendar, or in incorrectly entered addresses or rates in the billing model,
- training that goes beyond personal onboarding,
- preview features (Clause 8.5 of the T&Cs) – features that we mark in the application as "Preview" (in the German interface: "Vorab"). We are glad to receive reports about them; the deadline for the first response does not apply to them, and no credit arises for a missed first response. We handle security incidents (Clauses 4.2 and 7), a suspicion of data loss, and disruptions of a feature under Clauses 2.1 to 2.3 of the T&Cs as we otherwise would – even if a preview feature is the cause. If the application as a whole cannot be reached, this counts under Clause 6 like any other outage. In these cases, the commitments and credits of this SLA continue to apply; Clause 10.2 does not apply in that respect.
10.2 Even in these cases, we help you if we can – just without commitments and without credits under this SLA.
Changes to this SLA
11.1 Changes to this SLA are governed by Clause 13 of the T&Cs: we announce them in text form at least one month before they take effect, and you can object.
11.2 We can make improvements in your favour – such as shorter response deadlines or higher availability targets – at any time.