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.

One of your suppliers accidentally ships the wrong product to a customer.
A customer orders the wrong product or orders the same product twice.
A musician on your music tablature listings website creates nearly identical taxonomies, which already exist in your database. For example, your website’s users, considered as a collective, disperse electric guitar tablature across three categories: "Electric-guitars,” "E-guitars,” and "Elec. Guitars.” These should really be one, otherwise your front-end navigation and usability is compromised.

Optimize your admin panel to account for user errors:

Allow end-users to fix their mistakes. For example, Amazon has forms in its users’ dashboards, which allow customers to change orders at any point in time before the order has been processed in their warehouse. This feature empowers Amazon customers to fix their mistakes without reaching out to customer support.
Promote a subset of users to moderator status. Forums, such as Reddit and StackOverflow, have a special user class, known as moderators. Moderators remove spam, edit typos, rid the site of offensive or self-promotional messages, and correctly categorize content. In many cases, moderators are volunteers, who simply feel loyal to the community.

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:

Create inline documentation. Advise users on how to get the most out of their experience with your site. For instance, you could write a post like, “5 Copywriting Tips That Will Increase Sales.” By providing users with robust reference material, you’ll drastically reduce their need for human help.
Semi-automate assistance. By connecting external software APIs, your website can do things, like autosuggest the best keywords for meta descriptions, and encourage users to incorporate certain keywords into their copy.
Do it yourself. Send your own photos or write your own product descriptions. This, of course, necessitates the end-user somehow signaling their readiness for this service to the right person in your organisation. Here, your admin system needs to streamline this communication and the later delivery of work by the expert.

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:

Leverage existing groups of users. Plenty Of Fish, a dating website, outsources moderation of potentially offensive profile photos to bands of volunteer users who spend countless hours checking these pics, without any pay to speak of. Unlike traditional forum moderators, they don’t moderate content after it’s published. Instead, they vet user-submitted photos prior to publication, thus making sure inappropriate profile pics never get published.
Connect to humans-as-a-service APIs. For example, Facebook connects its admin panels to cloud APIs, such as Amazon Turk (or in-house equivalents) and outsources moderation en-masse to cheaper workers. In Facebook’s case, professional moderators account for one-third of its workforce. Indeed, it’s the presence of moderation that helps ensure that Facebook comments are relatively benign compared to the monstrous remarks appearing on comparatively unmoderated websites.

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:

Plan ahead. By analyzing past customer service questions, you can spot common themes, and answer them ahead of time. A prime example of this would be designing a FAQ page with a list of these questions and answers.
Be quick to refund customers. Offering a quick refund in response to a customer complaint is a quite effective way to satisfy disappointed customers. Don’t worry -- this won’t result in less profits; in fact, it may even lead to more.
Create forums for confused visitors. Google is notorious for its practically non-existent customer service. In place of humans, Google has created product forums, where confused users can get help from other users. On the rare occasion when a Google employee answers a question on one of these forums, their answer is saved, readily indexed by Google, and made available to future users with the same problem. While this may seem cruel to end-users, it’s pretty justifiable, when you consider that the majority of Google’s unsupported offerings are free.
Utilize canned responses and virtual assistants (VAs). Review your customer service tickets from the past year, and extract consistently asked questions. By crafting templated responses for each one, you’ll save yourself a massive amount of time. Write your answers in an easily accessible Google Doc or better yet, use an email plugin, like Canned Responses. Then hire a VA to forward these templates to customers as questions arise.

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:

Your users need editing capabilities. If you don’t provide editing functionality within your user dashboards, sooner or later your customer support team -- and your database programmers -- will have to manually make changes, like the ones mentioned above.
Don’t freeze editing capabilities. In the case of a forum or a site with comments, you must consider your policy for freezing posts for deletion or instead place a button requesting an exception to the normal policy. This solution saves time by decreasing the number of back-and-forth messages between your support team and the end-user.

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:

Preemptively address concerns. Dispatch an email or two once someone buys from you in order to increase confidence. For example, Amazon, and just about every eCommerce business, dispatches an email as soon as an order is shipped. Others also provide a series of emails, which update the user until the product is delivered.

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:

Automatically schedule consistent backups: This is the crudest, most trivial, yet most vital of all conceivable due diligence measures. But, even if you have good backups, you are already in a world of hurt if you need to tinker with SQL dumps. Therefore, scheduled backups should not be your sole source of restoration.
Buttons designed to terrify users:For actions with potentially irreparable consequences, color them bright red, slap the radioactivity icon on them, and label them with titles, like "WARNING: HARD-DELETE IS THE NUCLEAR OPTION: DO NOT USE IF UNCERTAIN OF ITS CONSEQUENCES." (Obviously, you should display what those consequences are right next to this button.)
Employ JavaScript confirmation pop-ups: Sometimes administrators' fingers slip and instead of pressing the "back" button they accidentally press the "permanently delete everything" button placed two pixels below. The hapless administrator may be entirely without fault for this mishap, with the ultimate blame going to clumsy UI design or nasty browser quirks when rendering CSS. If you think this is an absurd and overly dramatic example, you’re wrong. The financial services industry has lost millions through what they call fat-finger errors. As a result, they design software to prevent these types of errors. One dead-simple fix is an "Are you sure you want to delete all order history?" Javascript pop-up. Notice how I included entity-specific data -- "all order history" -- within the Javascript confirmation? This is better than merely asking "Are you sure?" If the administrator intended to delete a single entry in the order history but accidentally hit the button for deleting all order history, having this clearly stated in the Javascript confirmation popup helps avoid an “OMG” moment, when the administrator realizes what [s]he has mistakenly done.
Take advantage of data versioning and revision control: In standard SQL database technologies, edits to data overwrite the old values. This is problematic when edits were wrongly made, doubly so when the original data is difficult to find or create again -- e.g. long description fields that take hours to write, or customer information that would be embarrassing to ask for again. Revision control libraries, like in Wikipedia, are the go-to fix for these situations. They let you easily store and restore old versions of data on an as needed basis. These libraries typically work by tracking the changes in your database and retaining timestamped versions of previous values. Unfortunately, revision control libraries usually cannot handle big binary files, such as photos and pdfs. So, for these data types, you can keep old versions around, using something like Amazon’s S3 versioning.
Consider implementing a No-Delete Policy: This is all about preventing records in some tables from ever being deleted. Here’s the reasoning behind this: Given modern data storage prices, there’s little to be gained by removing old records, and a lot to be lost in terms of compromised data integrity, incomplete reporting, or mismatched record-keeping. A no-delete policy is implemented by placing a "deleted_at" date column on every major table. Wherever you previously had code to delete a record, you replace with code that sets the “deleted_at” column for that record to the current time. Elsewhere throughout the code, you selectively display or hide the “deleted” record depending on business needs. For example, “deleted” digital downloads will continue to appear in the admin area, for past customers, who bought that specific thing before the “deleted_at” date, and within "all-time" sales reports. However, the front-end shop should no longer show this digital product as available to prospective customers.

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.

Hiring? Meet the Top 10 Freelance Front-End Developers for Hire in June 2017
Don't miss out.
Get the latest updates first.
No spam. Just great engineering posts.
Don't miss out.
Get the latest updates first.
Thank you for subscribing!
You can edit your subscription preferences here.

Comments

comments powered by Disqus