Month: March 2018.
Report: “Product”
1. Team growth.
In March, the Product team grew by two people — we’re three now.
- Shane had been working part-time and is going full-time now.
- Robbie (consultant) was doing UX Design work from within the Support team and is now working us.
This is exciting! Shane and Robbie have been assigned their own projects, allowing me to focus on Roadmapping, designing the Digital Assembly Line 2.0, and building internal systems for the Product Team.
Technically, Skyler is also on the Product Team but he’s on a longer transitioning period out of Operations — his presence is still vital there. Moreover, having Skyler in Operations is still helpful to Product, as it gives us an “insider”.
2. Automating Dashboards.
In March we have automated the Instances and Process sheets of the Client Dashboard.
That is, we’ve deprecated the manual updating of these spreadsheets in circumstances such as:
- when a new Process gets build;
- when a Process gets updated;
- when new Instance (of a Process) is created;
- when an Instance is completed, esp. how much time it took.
This reduces the number of mistakes and makes Agents more efficient.
3. Routing v2.
Whenever you send us a message, we have to route it to the proper place. This past month we’ve finished writing the implementation plan for the second iteration of this technology and delivered it to Engineering for building.
As you can see above, this is almost completely shipped. As Engineering progressively delivers the features, the Product Team syncs with Operations on how to put them to good use.
4. Texting and Calling your Assistant.
We have set up Zendesk and have had one client in an alpha test for a month now — which proved this won’t scale as-is. There are (obviously) no off-the-shelf integrations between Zendesk and the Digital Assembly Line. We’re evaluating building the integration versus building Text and Call natively into the Digital Assembly Line (without third-parties).
You might think it’s obviously cheaper to build just the integration, but I must remind you that there’s nothing quite like the Digital Assembly Line out there. Bending existing services to make them work with DAL concepts often times breeds overwhelming complexity.
5. Slacking your Assistant.
We’ve gotten ourselves to a weird situation where we used to support Slack but can’t anymore. We’ve optimized the Routing Team and our Email-based technologies to such an extent that conversational mediums like Slack can’t be elegantly handled by the Digital Assembly Line at this moment.
That says more about conversational mediums than it says about us. Invisible’s thesis is that we can figure out a way to transfer context from the Client (who’s delegating) to any Agent (who’s to execute). By trial and error we’ve realized that transferring context from an ongoing conversation (like Slack) is harder than from a naturally threaded medium (like Email).
Solving this problem requires adjustments not only to Routing but also to larger parts of the Digital Assembly Line (DAL). As such, this project is moving forward with close alignment with our work on the DAL 2.0.
“Agent, replace this line with the desired text.”
When replying to Emails, Agents would often forget to remove this line before hitting “Send”. Erasing it from the template was not desired either. We’ve implemented a new filter to Postman (our Email service) that prevents outgoing emails from containing that string of text. Quick fix, small win.
Assistant-Client communication visibility.
In March we’ve developed a technology called Eru that allows us to drill down into the specific messages that were sent back and forth in a delegation. This data was previously silo’ed inside Instance Channels.
The need for such a tool is obvious in retrospect. Visibility is useful and necessary for many reasons, especially for investigating mistakes (and preventing them from happening again).
Digital Assembly Line 2.0.
We’ve started investigating recent mistakes and inefficiencies in the Digital Assembly Line. Skyler, from inside Operations, is getting us the data necessary for the analysis. After getting a good picture of the problems, we’ll move on to brainstorming, then to implementing solutions.
