Supporting services

The technology team supports some of our client services. We split our support into two units: GovPress and non-GovPress.

Support helpdesk #

For both units we use Zendesk to manage support requests. All incidents and requests for us to fix a problem or make a change to a site we support come to us via Zendesk as a ticket. We use tickets to manage requests in order to:

• keep track of all the things we need to do and what state they’re in, for us and our clients
• have a record of the changes we’re asked to make
• ensure that we only accept change requests from people who are authorised

If a client asks us to do something via any other channel, we ask them to email the request to support@dxw.com, which opens a ticket in Zendesk, or open a ticket directly.

It’s important that we do not do any work on a client website or service unless we are working during scheduled development time or on a relevant ticket.

Support rota #

We work on tickets by having a developer from the delivery team and another developer from the GovPress team on support according to a rota, supported by an operations engineer.

Delivery team developers are assigned to support for one week at a time and work on tickets for the whole week. They are responsible for the non-GovPress support requests.

If you’re on support, take a look at the guide on how we handle support.

Support principles #

Be responsive #

Clients expect us to deal with their issues promptly. But they understand that this isn’t always possible. They are generally forgiving of the fact that we’re sometimes busy, and they understand that some issues are complex and require long investigations.

The thing most clients value above all else is being kept informed of what is going on. The first quality of a good ticket experience is responsiveness. We keep clients informed of what we’re doing, even if there hasn’t been much progress.

Stick to your commitments #

It’s important that we do what we say we’ll do, and don’t promise things we can’t deliver. If we’re unable to deal with a ticket in good time and leave an update saying we’ll work on it tomorrow, we must meet that commitment.

It is doubly bad to fail to meet a commitment and not say anything about it. Responsiveness is always the priority. So if for some reason we couldn’t do what we said we’d do, we always respond to say so.

Make a good impression #

In tickets as in all things, we are mindful of dxw’s values.

Many clients’ only routine contact with us is via support tickets, so it’s vital that their experience of the support system is a good one, and that they have a positive experience with us personally.

In general:

• we are personable, friendly, and helpful
• if things look like they’re going to get difficult or the client seems unhappy, we are honest and assume good faith
• if we make a mistake, we take responsibility and apologise, and if the client seems very upset, we let the account manager know
• if we do become annoyed or frustrated by a ticket, we come back to it later

Don’t over-deliver #

Of course, every client would like us to go the extra mile to solve their problem. But they also understand that to do that for them would mean bad service for another client - or that we never get to their issue, because we’re too busy gold-plating the solution to someone else’s.

While we do everything we can to make sure the client is happy with our solution, we are also mindful of what’s practical. We don’t do extensive development work on tickets, or trial new approaches. We don’t play with new tools or sink hours into interesting bugs. We set those things aside, and schedule time to do them later.

The main purpose of a ticket is to take some action that solves the problem, as quickly as possible. Generally speaking, we do the most time-efficient thing that we can. Of several potential, acceptable solutions that solve the problem, we do the one which can be implemented the most quickly.

Last updated: 30 August 2023 (history)