Link Search Menu Expand Document

Admins need fudgability

This ranges from being able to edit individual order values to being able to perform tasks on users' behalf.

The job of your operations team is to get the job done

They will have to fix things, skip steps to speed things along and help customers more directly. This can range from correcting a typo in a product title to approving quotations on their behalf.

This will require changing data more directly

To accomplish “getting the job done” they will have to have changes made to individual entries.

And someone from the technical team will end up doing the editing directly.

But that’s dangerous

The most obvious danger is that it might cause errors and inconsistencies.

The change needed will have to be communicated very clearly. The relevant people will need to be informed once it’s done.

The admins’ work becomes more difficult because they have to request and then wait for the changes.

It is also nearly impossible to track and understand when and why someone made a change.

And besides all of that, it is also a poor use of developer time.

Start by rolling frequent changes into methods

In Supplybunny, this first showed up as the need to roll back order statuses. If the customer accidentally marked the order as delivered, for instance. To bring the process and data back into sync, I would have to edit the status and other related fields. Needless to say that this is tedious and “dangerous” work.

I started by making methods that make these changes and create a log. At first, there was no interface to call these methods, so I would still do them.

Because they were breaks in the process, we didn’t want them to be too easy to do. We didn’t want them to become a part of the process, yet. Instead, we wanted to control them more strictly and do them only rarely.

Over time, however, it became clear that while they are exceptions, they are legitimate parts of the process. That’s when we built user-facing functionality for them.

And then create the interface for those methods

We added the interface for the admins to move orders through the statuses.

For instance, while orders would get marked as completed automatically after three days, admins could do so at any time.

Similarly, we also added the ability for the admin to perform actions on behalf of users. For instance, if the supplier didn’t approve a quotation quickly enough, we would give them a call and get approval to send it on their behalf.

It removes work from tech, makes the system more robust and gives you more data

Giving admins more control has several benefits.

First of all, it removes the work from the tech team.

It makes the system more robust and flexible.

It improves customer satisfaction since you can directly resolve issues when you see a bottleneck.

It also improves operational efficiency since the people in charge of the process could directly influence it without assistance.

But it also gives you a more direct insight when something goes outside of the current process.

We gated most actions behind permissions so that there was a single person in charge of the break in the process.

Consider whether everyone needs access to the action. Typically, only a couple of admins should have access. Primarily this is to reduce mistakes.

But critically, it also creates a point at which you can ask why something happened. Then you can figure out if it’s a systemic problem and any potential alternatives.

Secondly, it’s vital to ensure that there are consistency checks at every change. For instance, you cannot allow an order total to be changed independently. It might mean that the sum of items would not equal the edited total.

Similarly, you cannot allow breaks in the set business logic. For instance, it shouldn’t be possible to mark an order as refunded if it hasn’t been paid in the first place.

You must also consider consent and what may and what must not be done on the customer’s behalf. For instance, you should get their permission in writing when doing something that involves money.

Pitfalls

There are two potential dangers to having these features.

Customers getting used to you doing work on their behalf

You might create an expectation that you will always do things on the customers’ behalf. Businesses, particularly ones bigger than you, are particularly fond of using you as free labor. They know that their value to you is much greater than your value to them. They might attempt to get you to do everything on their behalf.

It’s crucial to be diplomatic, get the buy-in of the right people and have the correct contact person.

It might hide deeper issues

The admins silently doing things on behalf of your customers can also mask issues with your processes. To fix that, first, not everyone should have access to all features. And secondly, every exception should be noted and investigated. Exceptions that keep recurring are potential changes to the process.

In the previous example, customers kept marking orders as delivered accidentally. We noticed the exception kept recurring, so we looked into how we could improve that step. We added a confirmation popup and required proof of delivery.

Related Lessons


Suggest an improvement to this page (me@ognjen.io)