---
icon: clock
---

# Response Times

What to expect by channel and by request type, plus how
the formal Service Level Agreement fits in.

## The default

**One business day.** Email us, fill out a form, or leave
a voicemail, and you'll have a reply by the next business
day at the latest. Most replies come back well inside
that window — usually within hours.

If you've gone over one business day without hearing back,
something's gone wrong (email landed in spam on one side
or the other, ticket got mis-routed). A nudge by phone is
the fastest way to get unstuck.

## By channel

| Channel                                       | Typical response       |
|-----------------------------------------------|------------------------|
| Phone (in-hours, Mon-Fri 09:00-18:00)         | Same call, or callback the same day if we're busy |
| Phone (out-of-hours)                          | Goes to voicemail; we call back the next business day |
| Email — any shared address (`customers@`, `development@`, `business@`, `privacy@`, `hr@`, `info@`) | Within 1 business day |
| Email — a team member's personal `@dmu.gr`    | Slower in practice — depends on that person's availability. Shared addresses are usually faster. |
| Contact page form                             | Within 1 business day  |
| Request information form                      | Within 1 business day  |
| Request a proposal form                       | 2-5 business days      |
| Reply on an existing thread                   | Within 1 business day  |

The proposal flow takes a bit longer because we put real
work into the scoping. See
[Brief & proposal](../brief-and-proposal) for how that
unfolds.

## Incidents — defined by your SLA

For incidents on active services — a site down, a service
unreachable, a degraded mailbox — **response time depends
on the maintenance plan that service is on**, and the
specifics are defined in our
[Service Level Agreement](../legal-and-policies).

In broad terms:

- The higher the maintenance tier on a service, the faster
  the binding response time on its incidents. A Premium-
  tier site is prioritised ahead of a Basic-tier site.
- The SLA spells out the exact response and resolution
  targets for each tier, plus the service credits that
  apply if we miss them.
- Monitoring still alerts us automatically regardless of
  tier — the difference is how fast we're committed to
  acting on the alert.
- Out-of-hours response is opportunistic for all standard
  tiers (see below). Round-the-clock response is available
  via a custom SLA — quote on request.

The SLA is the source of truth for incident timing. If
you're not sure which tier your service is on, the
**Maintenance Support** line on each website's detail page
shows it — see [Maintenance](../../services-and-monitoring/websites/maintenance).

## Non-incident requests

- **Quick fixes** (under your maintenance plan
  allowance) — within a business day or two of the
  request, depending on queue.
- **Larger asks** that need scoping or a Support Hours
  quote — within a business day to acknowledge, then a
  detailed reply once we've looked at it.

## Outside business hours

- **Email** is always open; we read it as the working
  day starts.
- **Phone** goes to voicemail outside Mon-Fri 09:00-18:00.
  We pick it up the next working day.
- **Monitoring** still alerts us automatically when
  something breaks, but we don't run a 24-hour on-call
  rotation. Outside hours we triage opportunistically —
  someone may be online and respond, but it's not
  guaranteed until the next working day.

We don't promise a response on weekends or public
holidays for non-incident work.

If you need round-the-clock incident response, that's
something we can quote separately as part of a custom SLA.
Reach out via [business@dmu.gr](mailto:business@dmu.gr).

## The formal SLA

The **[Service Level Agreement](../legal-and-policies)** is
the binding version of everything on this page — and the
only place that gives you exact numbers for incident
response and resolution by maintenance tier.

- The response figures earlier on this page describe how
  we work *in practice* for non-incident requests.
- The SLA is what governs **incidents** — it states the
  response and resolution target for each maintenance
  tier, plus the service credits that apply if we miss
  them.
- If your engagement includes a custom SLA, that
  countersigned document overrides the standard one.

The current published SLA is at
**[dmu.gr/legal/service-level-agreement](https://dmu.gr/legal/service-level-agreement/)**.