My Plan to Eliminate Communications in My Services-Based Business (28/30)

I'm writing 30 posts in 30 days. This is number 28.

In my last post, I was talking about how eliminating communications is the natural next step in the evolution of work. In particular, I cited Amazon as an example that pursued this policy aggressively, culminating into their famed service oriented architecture (SOA). In this post, I will outline the steps I intend to take in my own business to also pursue such policy and the reasoning behind them.

Right now, I’m fighting on two fronts in my work: services and products.

I have a revenue-generating business that mainly maintains and improves two quote-to-cash customized systems for my customers. That business is heavily services-oriented. The systems are customized and most new features are driven by the customers rather than me. Most of my time is taken up in that business. At the same time, I’m building micro-SaaS to see if I can break into the products-based business.

Essentially, I need to free up more time and generate more revenue from the services arm in order to make a success out of the products arm. And one strategy I’m looking at to use to achieve this is the thesis from the last post: eliminate communications.

Current Communications

Current communications in the services arm is between me and the customers. Basically, the requests exchanged via emails or meetings are of the following types:

1. requests to correct data they entered wrongly but cannot self-remedy

2. request to mass upload data (at least hundreds of data records) which takes too long for them to data entry as the webforms only allow one data record at a time

3. bug reports such as change password requests, missing data they expect to see, etc

4. feature requests

5. change in the workflow that the system is built around

6. anything else that is none of the above

Data related requests can be converted into features for the operators to DIY. As you might expect, I already have long backlog of features to work on. I need to prioritize accordingly. In the meantime, the systems are already live and in use by many parties., so the data requests will just keep coming.

As for bug reports and feature requests, the communications they generate cannot be entirely eliminated. Though I can ameliorate the amount of communications to some extent. In other words, I now have three major types:

1. Highly Repetitive Data Changes: the type of communications that’s highly repetitive and is a matter of time before I add features to allow operators to self-service (e.g. type 1, 2)

2. Standard Software Development Issues: the type of communications that I cannot entirely remove manual communications (e.g. type 3, 4, 5) but I can ameliorate to some extent with some bureaucracy or web forms (e.g. bug report forms, issue tracking software)

3. none of the above

Customer Success Team as Interface

I could hope against hope that my customers who are mostly non-technical people would eventually adopt an aggressive policy of eliminating communications. But it’s not ever going to happen. Based on my observations, if my customers were the type of far-sighted people to emulate Amazon in eliminating commuications, they wouldn’t have hired me as a contractor to build customized systems to replace their original haphazard workflow of emails and excel files to handle their quotation processing workload.

Why should I bank on them to do the right thing and turn our communications into something more standardized and compliant with a service contract like a SOA?

Rather than waiting for them to change, I need to take initiative on the spheres I can influence and control.

Right now, I’m training students waiting for their enrollment into universities to help me as Customer Success to handle all the repetitive tasks or at least the repetitive aspects of the requests.

Figure 1: After I implement Customer Success Team, CS Team becomes the new interface.Making it easier to implement more standardization later.

I freely admit that adding a Customer Success team is the step 1 of a long-term strategy to build a company that can run without me on a daily basis.

Steps to Convert Current Repetitive Requests into Better Abstractions

Right now, my formula for handling all the requests that come in is simply:

1. Every request from customers go to Customer Success Team

2. Most of the requests are still handled by me as they were before the CS Team was formed.

3. Every request is recorded as is and an attempt is made to identify the request as an instance of an existing class of requests. If no such class exists, then a new class is declared. All I do is simply have a name for it at this stage.

There’s no sophistication to what I do in this three step process. All I do is record them in a Google spreadsheet and each time, when I manually handled the request I will also add documentation and videocasts.

Figure 2: As you can see, it’s just a simple spreadsheet recording of requests and identify the class they belong to

As time goes by, I expect to eventually offload those request class (I identify them as Workflow in the spreadsheet) to the hires of the Customer Success Team. If I can digitize the workflow further, I will do so as well. Reducing the workload on the CS Team helps me keep the costs low as well as I expect my customized systems to grow and eat the existing workflows in the customers’ companies.

A Continuous Progression of Eating Workflows

This is not a once-and-done process. I fully expect this process of slowly replacing existing communications with standardized requests and then, perhaps, converting them into fully API calls instead. If you were also expecting some big bang technological cleverness when I talked about eliminating communications, I’m sorry to disappoint as well.

I think I have wasted too much time in the past, trying out fancy tech and overly complicated solution design. Now, I prefer to use boring, proven methods. Not all systems are of the software digital type. Yet, building systems that help me run business more effectively and efficiently are just as valid even when they require humans to run them.