Self-service tools enable predictable delivery while still allowing for organizational oversight. Self-service tools allow customers to perform common actions themselves without relying on other teams. Self-service tools require shifting to a product focused mindset, but provide a number of benefits including: predictability in task execution time, speed and favorable customer to employee economics.
Self-service tools enable customers to perform the common actions themselves without requiring interaction from other teams. Self-service tools enable customer autonomy. The experience around self-service tools may vary greatly and could include:
- “Dashboard”: UI point and click: Create users, graphs, charts, alerts, etc.
- Pull Request: Consumer makes a Pull Request to achieve their desired functionality.
- Libraries: Consumer incorporates libraries at the programming level to achieve the desired functionality.
- Executable Frameworks & Components (CLIs): Terraform, modules etc. Consumers interact through tools and invoke commands to achieve the desired functionality.
Think about common SAAS’ like DataDog, or AWS or Google.Individual users can create resources, dashboards, users, and charts. The end user can fully control their experience, and only rarely need to consult with customer support.
Role based access control (RBAC) is an important component of self-service systems. RBAC allows different customers to have different levels of access. Access levels may be split by feature, operation, or any other dimension that makes sense.
There are 2 dimensions which help to inform the approach that should be taken when creating self-service systems:
- Distributed vs Centralized
- Oversight vs No-Oversight
The degree of distribution characterizes how much implementation decisions may differ throughout an organization. A fully centralized solution would have a single way of performing an action, whereas a fully distributed solution would have a different way of performing an action per customer, or team.
The amount of oversight determines what sorts of guardrails, access request, or operations are available. A product with complete oversight would include RBAC, audit logs, explicit approval for every task. A product with no oversight would allow teams to do whatever they want.
|Centralized||Web-based dashboard. i.e. SAAS’||Teams plug in to a platform. i.e. Jenkins.|
|Decentralized||Libraries & Frameworks. Teams compose their own services from building blocks. i.e. Terraform, REST client libraries.||Free For All. Every team unto themselves. i.e. Teams choose their own solutions independent of any other teams.|
Many companies go through phases where they find themselves in these different quadrants. Other companies may exist in highly regulated environments which mandate certain level of oversight.
Have you ever created a support ticket or issue ticket? What was the experience like? Would you be comfortable committing to a delivery date when you have many tasks depending on other teams?
The customer to employee ratio is a good way to understand the power of self-service. Consider a product without self-service. This model requires employees to directly service client requests. An example of this would be a checkout line at a store. A cashier can handle a finite number of customers per hour. Some customers may have small orders some large, but all are constrained by the available cashiers speed. Say it takes about 5 minutes to checkout the average customer. This means that a single cashier can service 12 customers per hour or a
12 customers to 1 employee
Self-service checkouts has a huge impact on this ratio. A single employee can service 15 self service checkout machines. Even though each checkout may take longer than 5 minutes (let’s assume double 10 minutes) the overall customer to employee ratio is much much larger. In the self-service checkout model:
90 customers to 1 employee = 6 checkouts / hour (10 minutes per checkout) * 15 self-service stations
Self-service offers the company much greater efficiency in terms of customers served per interval and costs.
The other side of this is the customer experience. It’s often more cost effective for a company to keep a pool of self-service resouces than it is to keep a pool of idle employees. My local Super-Walmart has ~15 employee ran checkouts, and ~20 self-service. The self-service queue is more predictable since it has more available registers. This makes it unlikely that a single large order holds up the entire line. This smooths out the amount of time it takes to checkout and provides a more predictable queueing latency.
Self-service customers scale with respect to the number of employees available, which is pre-internet and computer economics. Without self-service a single Customer Support would be able to serve a finite number of requests per day. Self-service completely changes this ratio.
Self-service as a feature provides internal customers with a number of benefits:
- Economics: More cost effective customer to employee ratio.
- Predictability: Once a customer learns how the product works, it takes a predictable amount of time to perform that task.
- Speed: Self-service is faster than waiting on other people.
- Oversight: RBAC, Audit-logs and guardrails on allowable actions enable organizational oversight.
Creating self-service tools isn’t easy. Self-service tools require teams to have a product focused mindset, which means discovering their customer’s problems.
For each feature think:
“Can a customer do this without interacting with us?”
When creating self-service interfaces consider:
- Which actions will users be executing? (What)
- Who will be executing these actions? (Who)
- How will they execute them? (How)
Return on investment calculations can go really far for informing if a service should be self-service. ROI calculates the amount of time individuals save vs the implementation time.
RBAC and tooling may add significant overhead to offerings, so it may not always be feasible to create self-service tools. There are a couple of alternatives when self-service isn’t an option:
- Strict SLAs: Teams still need to fulfill requests on behalf of their customers, but provide a guarantee on how long tasks will take. This allows customers to make commitments even when they need to interface with an owning team.
- No Oversight: Teams make their own decisions based on their needs. If interfaces with an owning team is consistently time consuming they are free to find a quicker solution. The same goes for features. If a team is constrained by self-server feature offering they can go someplace else for the features they need.
Self-service tools enable customers to perform the majority of actions on their own, without any dependence on the creating team. Self-service tools are essential for predictability. Without self-service tools teams are dependent on the owning teams to get work complete. This often results in an alignment issue where each teams priorities are different.