Version: 02
Wednesday, 21 February 2018
The Routing System.
This a more in-depth explanation of how we’re going to improve our routing system. To see the big picture, you may want to take a look at the Roadmap.
Delivery Schedule
1. Improvements to the existing Slack-based system.
Shipped by Monday, April 2 (was March 12).
2. Dedicated User Interface
Shipped by Monday, June 4 (was April 2).
What do we mean by “Routing”?
The Routing system is responsible for forwarding Client messages to their appropriate places.
A Client might be telling us a new preference, requesting us to build a Process, or simply asking to operate an existing one — often times many of these cases in a single message. We call each of these cases a “Route”.
The current Routing system was built as a Synthetic Intelligence, having both humans and machines interacting. It works well, but now it is time to make it even better.
What are we looking for?
We’ve identified a few problems that Routing v2 should solve. These problems are here rephrased as benefits (features).
- Inbox Zero-style.
Less clutter, less mistakes. - All Routes automated.
Only the Instance Route is currently automated. - Reduced number of channels.
Single channel for routing messages from all clients.
What is the plan?
There are two major categories our approaches might fall into:
- Improving our existing Slack Apps.
- Building a User Interface from the ground up.
We know we’ll need to build our own User Interface eventually, but it might make sense to leverage Slack some more first.
What is the difference?
We estimate that improving our existing Slack Apps is only half as expensive as building a User Interface dedicated to Routing— and both would provide the benefits we’re looking for.
That being said, having a dedicated User Interface would be a game-changer. We wouldn’t be limited by Slack capabilities anymore.
1. Total control (pro).
With a dedicated user interface, we would be able to take Agent ergonomics to unprecedented highs, which is expected to reduce mistakes, decrease response times, and increase overall quality of our service.
2. Simpler code (pro).
(Technical terminology ahead.)
Building from the ground up would allow us to write more declarative code. For example, the React library makes the view a pure function of the model, i.e. V = f(M). Which means after mutating the Model you don’t have to worry about updating the View—the library will do that for you.
Slack is not like that. We could call Slack an “Imperative View”. Every time something changes, you’re solely responsible for making sure the change is propagated. This means having to write and maintain two-way synchronization drivers: mutating the database requires updating Slack, and mutating Slack requires updating the database. This is complex, boring, and error-prone.
Additionally, building a dedicated User Interface means we won’t have to worry about Slack API rate limits anymore.
3. Increased software maintenance costs (con).
Building a dedicated User Interface is not without its perils. We would end up owning more code: the back-end code which we already do, plus the new front-end code for the browser interface.
Code is a liability, not an asset.
4. New period of software maturation (con).
We’ve already fixed a number of bugs in the current Routing system. Additionally, we write regression tests, to prevent the same bug for ever showing up again.
As times goes by we find fewer and fewer bugs in it. The code becomes mature.
Building a new interface from scratch means going through this maturation period again. New code, new bugs.
Which path shall we take?
Both! We’ll improve our current Slack-based systems, and at the same time build the dedicated User Interface to replace it. Why?
1. We can’t stop moving.
We can’t stop everything else to focus on building the dedicated User Interface. We need to keep servicing our current clients and onboarding new ones.
We have aggressive Sales Targets for this and next months. Our systems need to be able to accommodate a much higher number of Clients and Agents as soon as possible — that means improving the existing Slack-based system.
2. The inevitable.
We will need to build the dedicated User Interface sooner or later, so we might as well get it started. No generic communication platform will ever allow for such a high degree of customization that would enable the Digital Assembly Line to operate on it perfectly. The sooner we start, the sooner we get it done.
3. Intra-project blockers.
You can’t take a twelve engineering-weeks project, delegate to twelve Engineers, and expect it to be done in a week.
Even if we wanted to commit all our engineering resources to building the dedicated User Interface, the project could only move so fast. Software is built with layers. You have to build one layer before your colleagues can built the next one.
Moving forward with one front doesn’t necessarily slow down the other one.
4. Placing ourselves in a more powerful position.
In Chess, even though you can visualize a few moves ahead, you can’t actually predict the future. Fully committing to one path is detrimental as a single unforeseen move might break your whole plan.
Reaching check-mate is a process of placing yourself at ever more powerful positions, until you’re close enough to victory that you can actually predict every move.
By moving both fronts forward we keep our options open.
5. Evolution through selection.
Keeping options open puts us in a position that allows waiting for the best possible timing before making the switch from the Slack-based interface to the dedicated one.
We can’t be sure how our systems will evolve. Building a new interface will change not only our perception of the problem, but the very problem itself. It’s all connected.
When will we make the switch?
Once the dedicated User Interface is built, we will want to migrate a few key clients first, for testing and debugging. We’ll probably start with our CEO Francis Pedraza — dogfooding is the law.
