Providing technical support
The technology team supports some of our client services. These are live services, usually (but not always) built by dxw, for which we provide ongoing support with hosting, maintenance, or bug fixes. We split our support into 2 units: GovPress and Delivery+.
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 to make them
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 opens a ticket directly.
Who delivers client support? #
Support tickets are handled by dedicated support developers from GovPress and Delivery+, or by nominated substitute developers in their absence. These support developers respond to, organise, and prioritise tickets. They will also deal with the bulk of the implementation work, pulling in other developers as needed. Some tickets are also handled by members of the Ops team.
Out of hours support for projects is handled on a rota basis, please see the support and on call guide for more information.
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’s 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’s 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.
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’re 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: 20 March 2024 (history)