Automation Patterns in Support

Structured Message and Response Ticketing Systems

Over vacation, I watched “808,” a documentary on the famous Roland TR-808 drum machine which defined so much of the sound of music in the 1980’s. One of the more compelling quotes came from a musician who said that most of the developments of new styles of music have come about by advances in music technology— because in the end, we’re all working with the same limited pallet of musical notes.

Here’s the trailer:

If you’re into electronics, here’s a tear-down and cleaning of one of these vintage machines, which evidently sounded the way they did because of fuzzy reject transistors the company bought intentionally at low prices until they were no longer available and the product was discontinued:

Drum Patterns

Anyway, I had kind of an aha! moment when I saw some of the graphic notation people use for the drum patterns which they program into this thing. Something like the below:

[Image source]

Another representation of the same idea below:

[Image source]

Basically what we’re seeing are sets of blocks — drum sounds, but let’s abstract them more generally as “content blocks.” (I’m thinking text blocks, specifically when I say that.)

Or another one below:

Now, since it’s a drum pattern, it repeats. Thus the pattern repeating itself is a kind of automation — which replaces, or supplements, a live drummer.

Here’s a simple online drum machine if you’ve never played around with this kind of thing before:

Support applications

Technical Support marches to the beat of a different drummer though, obviously…

Our use case isn’t a linear loop of sound triggers. Our use case is however still concerned with repetition and with common patterns:

  • Answering the same types of questions again and again, and automating workflows around solving tickets which really need a human to answer them.

Here’s a rough outline of a “support pattern” modeled for a particular type of interaction that might come up frequently. It’s meant as a message skeleton which could be augmented with custom content by a human agent as needed:

Instead of hi-hats and cymbals, our elements are blocks of commonly used text — modular components to rapidly build messages without having to type every single word out letter-by-letter all-day-long oh-my-god-kill-me

  • Here’s a different kind of structured message response pattern pulling alternative elements from the same bank of components:

The goal here obviously would be to analyze tickets with natural language processing and use machine learning to suggest to agents relevant text blocks while building responses in high-volume structured message and response ticketing systems (S.M.A.R.T.S., get it?). Then the agent just fills in around suggested text blocks does any backend voodoo they need to do (which is also notated), and the system learns for next time. Eventually, it answers simple questions with its own unique compositions of text blocks to solve the user problem at hand.


Message building prototype

I’ve achieved a kind of primitive “Support Drum Machine” as a road test of some of these functions — more details below:

I can say that even just having this simplified hardware version of this concept saves me so much time and UI-twiddling while ticketing — it’s incredible. They are basically single key triggers for switching apps, commonly used text blocks, ticket status changes, a couple of commonly used URLs. The automation of the workflows, in this way, doesn’t replace an agent at all but takes out a lot of the tedium that goes with the job.

That’s my operating principle anyway.

See also: