Skip to content

Types of support

Support time falls under one of four categories:

  1. Critical support which covers responding to high impact issues which affects all users and where no workaround exists.
  2. Consulting which covers most phone calls, emails, research and meetings to discuss the project with the client. It also covers non-critical but important bug fixes.
  3. Development which covers smaller pieces of ad-hoc development outside of sprints.
  4. Consultancy (pro-bono) which includes any non-critical internal work done under our own steam.

Additionally, there are a couple of categories of support work that we pull out more specifically than just Consulting:

  1. Planning and project management which specifically covers when we use support time to work with the client on scoping out another piece of work.
  2. Client management which covers higher-level strategic work typically undertaken by the MD.

Some examples of situations that would be classified as critical support are:

  • The site is down
  • The site is really slow
  • No one can log in
  • No emails are being sent
  • Payments aren’t being processed

Support time is considered consulting if the time spent provides value to the client. That might be a phone call, or responding to and investigating queries like:

  • My customer can’t redeem a gift code.
  • Does this page look wrong to you?
  • I can’t use feature x
  • One of my customers can’t submit a job form.

Where consulting is more focused on Planning and project management, it should come under that category instead. When consulting is more about higher-level strategic work, it should come under Client management instead.

This is smaller pieces of ad-hoc development on the project completed outside of sprints. Usually these are small changes and tweaks to functionality and not bug fixes.

We work in half-day chunks and aim to schedule the development within two weeks of confirming the requirements with the client.

Sometimes we will do some work internally on a client project under our own initiative. Things like:

  • Refactoring code, and
  • fixing minor bugs that are not affecting customers currently.

We do this typically because we have some value to be gained from doing it. Sometimes we have some downtime we want to put to good use. Or maybe one of us wants to keep our code skills limber in a time of heavy business development or consulting. Sometimes it’s just a goodwill gesture.