Skip to content
Writing
How we build

What happens after go-live

Most software problems a customer experiences are not bugs. They are a process that changed, a person who left, a report nobody knew existed, or a workflow that was configured for a situation that no longer applies. None of those are fixed by a ticketing system.

1 min readOadbox

No handoff to a support layer that cannot fix anything

The conventional model separates the people who build from the people who answer the phone, which is efficient until the answer requires changing the software. Then it becomes a queue between two teams with different incentives.

We keep the engineers who built a product close to the people running it. It is more expensive, it interrupts development, and it is the reason issues get closed rather than categorised.

The cadence

  • A named contact who knows the customer's configuration, not a rotating queue.
  • A check-in at week two and month one, before anyone has to complain.
  • Release notes written for the user, naming what changed and why.
  • A quarterly review of what the customer is not using, and whether that is our fault.

Support tickets are product feedback

A recurring question is a design defect with a workaround attached. If four schools ask the same thing in a month, the answer is not a better help article.

We review ticket themes at the same table as the roadmap, which occasionally means displacing a planned feature for something nobody asked for as a feature — because they asked for it as a question, forty times.

Staying is a constraint on what we build

Running what you build changes design decisions. You stop shipping features that require you to explain them, because you will be the one explaining. You take backwards compatibility seriously, because you will be the one migrating.

It is a slower way to build and it produces software that ages better. That is the whole argument, and it only works if nobody is allowed to hand the consequences to someone else.

Product teamSupportOperations

Written by the Oadbox team. Something here not match how it works in your business? We would genuinely like to hear it — connect@oadbox.com.

Eleven products, already running. One of them probably fits how you work.

See it on your own data rather than in a slide deck — thirty minutes with someone from the product team.