The Art of Building Self-Service Admin Areas
Software is regular and predictable, so it seems paradoxical that practically every web app needs a sizable administrative area. The explanation for this paradox lies in software’s interaction with humans. While you probably can’t build a fully automated system, there’s a lot you can do to save time and money.
In this post, Entrepreneur Jack Kinsella explains what you can do to streamline administration, thus saving valuable time and making your projects more profitable. Adminimisation is the word of the day!
Software is regular and predictable, so it seems paradoxical that practically every web app needs a sizable administrative area. The explanation for this paradox lies in software’s interaction with humans. While you probably can’t build a fully automated system, there’s a lot you can do to save time and money.
In this post, Entrepreneur Jack Kinsella explains what you can do to streamline administration, thus saving valuable time and making your projects more profitable. Adminimisation is the word of the day!
Jack has a background in law and is currently interested in probability, algorithmic education and blockchain.
Expertise
Once you’ve launched your passive income site, you should be celebrating, right?
Unfortunately, life isn’t always as it should be, and you’ll usually have to postpone celebrations to cater to your customers – unless you have the right systems in place.
I’ve managed a passive income site for more than six years. For me the emphasis has always been on “passive.” Therefore, it’s been a longstanding priority of mine to streamline my business as much as possible.
Effectively streamlining an online business comes down to having the right features and capabilities in your administrative panel.
In this article, I’ll detail common problems with admin dashboards and offer solutions to each. By the end of this post, you’ll walk away with a robust playbook of best practices for developing an efficient admin panel for your automated business.
Accounting For User Error
Users make mistakes, which means we need an admin panel that fixes these mistakes. Here’s a few examples.
Optimize your admin panel to account for user errors:
Accounting For User Inexperience
Don’t expect your users to be well-versed in your business. Here’s a few examples of what I mean by that.
For instance, your average user is a poor photographer, yet you desire spiffy photos of those same user’s holiday rental properties listed on your platform.
Perhaps the average user is a poor salesperson, yet you want tantalizing, SEO-optimized descriptions of the trinkets those users sell through your platform.
Or perhaps you run an eCommerce store selling shoes online, but your average site visitor doesn’t know how to measure their feet, leading to a preponderance of customers ordering the wrong size and then wanting to return their shoes later.
Admin areas that account for user inexperience:
Accounting For Pending Business Decisions
Unfortunately, everything can’t be automated. When it comes to judgment calls, a human is usually necessary.
For instance, what happens when you need to verify the identity of your latest babysitter applicant on your high-trust platform?
Or what happens when you’re the only one who can price the latest digital product submission from a platform author?
Examples of time-savers for admin arising out of pending business decisions:
Accounting For User Need To Communicate With The Website’s Management
When you’re running a business, questions are expected. By effectively planning ahead, you can dramatically cut the time it takes to respond to them and possibly reduce the number of customer requests you receive in the first place.
Admin areas that account for user communication needs:
Accounting For Users Changing Their Mind
A wise man once said, “Change is the only constant in life.” He was right. Things change.
Maybe a user gets married, and they no longer have the same last name.
Or perhaps a customer, who subscribed to your monthly delivery box service, moved and needs to update their address.
These are just two examples of inevitable changes, which you must plan for ahead of time.
Examples of time-savers for admin arising from user change in circumstances/mind:
Accounting for Action Attributable to User Worry
Unlike brick-and-mortar stores, online businesses lack the reassurance of buying from a real person, in-person.
Think about it. How do you feel when you purchase something at Best Buy? Probably confident because you know that tomorrow morning, Best Buy will still be there if and when you return with complaints or for a refund.
This feeling of certainty falls away online for obvious reasons. People can easily ignore online communication, which makes prospects wonder if anyone will ever get back to them. This feeling of suspicion only grows when the website is some unknown startup with no brand equity.
Example of time-savers for admin attributable to user worry:
Resolve Potential Ambiguities
It’s one year after launch and, thanks to good revenue, you now delegate your website’s administration to a dedicated team member.
One day, however, this administrator unexpectedly falls ill and now you need to resume their administrative work, without any briefing about what that administrator had been doing last week.
Based on the information inside the administrative panel, you need to know where your administrator left off– what tasks they processed and what ones they left undone.
This isn’t always possible, due to badly designed state-machines that do not reliably distinguish between unseen (or unprocessed) and considered (or processed). For example, imagine an admin state-machine as follows:
What Happens | State Changes |
---|---|
An artist applies to sell their art on your art-selling platform | The artist entry appears in the admin panel with the starting state “applied” |
Someone on your admin team accepts this artist, allowing them to sell their art | Admin changes state to “accepted” |
Your team rejects this artist because it knows, for sure, it will never want that artist | Admin changes state to “rejected” |
Your team is on the fence about this artist and wishes to defer the decision | Do nothing |
The problem with this admin flow, from the perspective of a systems’ administrator, is that the admin panel says “accepted” for both unseen new artists and for artists that had already been seen/considered but were postponed without being rejected outright.
The fact of having considered (or processed) that artist exists only inside the mind of the absent administrator, and without any way to mark a lead as “postponed,” this information is lost, so the person taking over the job must repeat the work already completed.
A good activity feed fixes this type of ambiguity.
Maximize Transparency
Many administrative panel actions carry out a series of steps behind the scenes.
After pressing the “accept applicant” button, for example, the applicant in question receives an acceptance email, their account gets credited with a $100 sign-up bonus, and their status in your database gets changed from “applied” to “accepted.” In software engineering terms, these are side effects.
Given that you – the programmer – developed these features, you’re likely aware of the consequences of hitting “accept applicant.”
At the very least, you can open-up a source code editor, or your favorite IDE, and refer to the code for the answer.
Your customer service reps don’t have this luxury though. So they’ll likely be unsure of what happens when they press the button. Also, they’ll likely wonder whether the applicant will be alerted that they were accepted, or if they should send a manual email, alerting the applicant, after they press the button.
This uncertainty slows down the entire process because now, the administrator needs to ask management and/or engineering questions and wait for their responses. Not to mention that this can easily lead to duplicate work and introduce errors into an otherwise smoothly run business.
Ideally, in this example, the admin page with the “accept applicant” button would have an inline, descriptive paragraph, explaining exactly what happens when they button press the button.
Alternatively or additionally, a message could appear after the button was pressed, explaining what happens next.
So far, we’ve looked at the happy case, i.e. background actions that occur when everything is running as it should. The trickier situation is dealing with opaqueness after something goes wrong. Which side-effects were completed and which ones were left undone? In a perfectly designed system, on failure the “accept applicant” button would inform the administrator (and the tech team doing clean-up) that the acceptance email was delivered but the $100 sign-up bonus was not sent to that user’s Paypal account. This information enables the company to remedy the partial transaction. As for implementation details, this feedback could be done either with detailed state machines that track every tiny step, or, alternatively, by wrapping administrative actions within service objects whose return values list both the commands which successfully run and those that failed to run.
In my experience, the gap between how information appears to the administrator and how it appears to end-users can be a frustratingly opaque.
Sometimes answering a customer email or bug report requires your administrative team to know how the customer’s login dashboard looks, what a specific automated email says, or what royalties the user-facing dashboard says it owes a user.
Having access to this information helps your team understand problems as your users experience them.
One way to implement this functionality is to build a “View as User” admin feature.
This would be in lieu of creating separate admin screens that reimplement features already present for regular users, thereby awarding you the extra bonus of re-using lots of existing code.
As for automated emails, consider building a lightweight admin area email renderer so that your staff can read the messages that will be, or have been, sent to users.
Events Outside Your System are a Liability
Manageable administration is self-contained.
It’s boxed within a single closed system instead of in scattered scraps.
For example, if information about what refunds you gave are dispersed across an Excel spreadsheet, some yellow post-its on your table, and in emails to your accountant, then you have a mess on your hands.
The proper solution is to have a comprehensive list of refunds in a database table within your admin dashboard. When you have a single oracle of truth, you can rest assured knowing that any reports produced by you are definitive and trustworthy.
While this seems obvious, it’s often neglected in the scramble of managing a business.
I would know because it happened to me.
When I initially designed my eCommerce ordering system admin panel, I only prepared it for recording sales and only sales.
A few months after launch, I realized all of the additional transactions I didn’t account for, such as refunds, chargebacks, freebies, discounts, and payment adjustments.
Because I didn’t foresee these transactions in my initial design, there was no code in my admin panel for fulfilling or reporting them.
Whenever I had to do a refund, I was usually so time-strapped that I carried it out in whatever way was easiest at the time – usually through Paypal’s web interface (skipping my website’s order database) – but sometimes through a third-party iPhone app that communicated with Paypal’s API.
Because of my scattered actions and therefore data, all my accounting was haphazardly reported in various external sources. Even worse, my production database records didn’t quite gel with my full order history.
Inevitably, problems emerged. Admin reports of revenue and commissions didn’t reflect the economic reality. Some of my authors were sent financial reports with incorrect financial reports. And worst of all, I overestimated my tax reports, which led to paying excess taxes.
All of this because I had not discounted all my refunds.
By storing order and accounting information partially inside and partially outside my main software system, I robbed myself of much of the advantages of software in the first place – its accuracy and precision. I could no longer trust it, which meant I could no longer automate it.
In response to these issues, I developed an aversion to keeping any company data outside my core software system.
Even if it’s initially expensive to integrate all necessary information into the core, in the long run, the benefits far exceed the costs of half-ass hacks.
That said, despite my best intentions to automate, sometimes it just can’t happen.
Many software companies have automated sales emails that ferry users inch-by-inch toward the point when they will activate their account or make a purchase – all ideally without any human assistance.
Complications arise when a lead sends special requests to your staff halfway through one of these drip campaigns.
Suppose that the lead responds, saying they will be on vacation for two weeks, but please get in touch with them afterward to seal the deal.
If our system was programmed to send an automated reminder email after only five days, then we’ve ignored the lead’s wishes and perhaps soured the relationship by coming across as pushy, inattentive, and robotic.
So what does one do in this situation?
One answer is semi-automate.
The admin interface could ask you which emails should be sent, and you can tick a box to unschedule them as needed.
Admittedly, this might be engineering overkill, so sometimes the only realistic option is to accept that automated emails will sometimes get things wrong.
Surface the Most Relevant Admin Information and Actions
When a customer contacts your business, it’s often in relation to an order, an account, or an offering.
By virtue of stored data, login cookies, and data hailing from your tracking layers, your application probably knows a lot about its customers and their interaction histories.
You can save significant time in answering customer service requests by algorithmically pulling these information sources and extracting relevant bits of data to facilitate your administrators’ responses.
For example, contact-form messages, before getting converted into emails sent to your inbox, could automatically have an information box appended that includes the order’s payment status, shipping status, line items, and more.
Additionally, these fortified emails could also contain convenient links to the most frequently used (and relevant) parts of the admin area, such as the refund dashboard or the shipping tracker.
Anticipating, Mitigating, and Recovering from Administrator Error
Like everyone else, administrators are human and occasionally make mistakes.
Given the control they have over your data, their mistakes can potentially cause irreparable damage.
Here are a few measures to put in place in order to prevent a disaster:
Expect the Unexpected
While I’ve offered a multitude of solutions to an array of problems above, these are by no means hard-and-fast rules, but rather a robust playbook to learn from and refer to.
Remember, the ultimate goal is to optimize your admin panel in order to streamline your business. Setting aside some time to tweak your admin areas should boost profitability in the long run, making it a worthwhile investment.
As with anything in life, there will always be exceptions to the rules, so make sure to use good judgment when optimizing your admin panels. And then you can finally celebrate.