The Soyuz-Apollo of Innovation, Part 2: Thinking Outside the Bottle

Somewhere between Chris de Burgh’s immortal observation that midnight in Moscow is lunchtime in L.A., and the bottom of a bottle of single malt Scotch in a conference room called Baker Street, someone had an idea worth patenting. This is that story.

https://www.chris-de-burgh.co.uk/track/Moonlight-And-Vodka

In Part 1, we covered the theory – how Soviet TRIZ and Californian Design Thinking dock together to give you an actual mechanism for solving problems that shouldn’t have solutions. We dissected a Stanford professor’s luggage brief and my jet-lagged toroid toilet-cover backpack. Now the rubber meets the road: a real business problem, a real solution, and a real patent buried in language so impenetrable it would make Altshuller reach for something stronger than tea.

Baker Street, Moscow. Winter. Whiskey.

Picture this. Moscow. Winter. The kind of dark that isn’t just weather – it’s a philosophical position. The conference room is called Baker Street – not because anyone was trying to be clever about it, but because corporate naming conventions are exactly as inspired as you’d expect. A small group of data scientists – and overall very smart, very funny people – sits in front of a fireplace set into the wall. Whiskey on the table. The good kind.

The full equipment. Single malt Scotch, cigars, a fireplace, and a business problem. One of these things was optional.

Outside: snow. Inside: the accumulated weight of a genuinely hard business problem that everyone had been politely avoiding for several quarters, because the honest version of the problem was uncomfortable and finance presentations prefer their discomfort in footnotes, highlighted in yellow, where it can be ignored until it can’t.

The problem was this: the business was growing fast. Customer base expanding. Relationships long – not the transactional “buy something, goodbye” kind, but the years-spanning, decades-long kind where you know your customer’s dog’s name and they know when your product team is having a bad quarter. And with that growth came an arithmetic reality so uncomfortable it had been living in those yellow footnotes for months:

You cannot keep hiring customer support headcount proportional to revenue growth and call it a strategy.

At some point your gross margins start sending distress signals. Your CFO develops a nervous tic. Your head of operations starts using phrases like “structural inefficiency” with the tone of someone diagnosing a terminal illness.

Standard industry response to this problem: hire more people, build a bigger call center, add a chatbot that infuriates everyone equally, deploy a survey nobody reads, declare victory at the all-hands, collect your bonus, repeat next year. The corporate cliché playbook has a perfectly laminated page for this situation. It does not involve a fireplace, single malt Scotch, or data scientists with a chip on their shoulder.

We were not consulting the playbook. Obviously.

The Data Nobody Was Using

Here is the thing that was sitting right in front of everyone, invisible the way that obvious things are invisible: decades of data.

Not just CRM notes and ticket history. Everything. Order data. Clinical data. Every customer touchpoint – calls, emails, visits, complaints, compliments, the occasional passive-aggressive email chain that somehow resolved itself without anyone admitting fault. Voice recordings. Call transcripts. Sales rep interaction logs. Workflow statuses at every stage, for every customer, going back years.

If you’ve been in a B2B business long enough, you are swimming in data about your customers. Most companies use roughly 5% of it for reporting and spend the rest of their time apologizing to regulators about what they’re doing with the remaining 95%, which is mostly sitting in databases generating storage costs and low-grade existential dread.

And then, somewhere between the second and third whiskey, someone said something so obvious it silenced the room:

“If we know everything about a customer’s workflow right now – why are we waiting for them to call us?”

That’s it. That’s the whole thing. The entire patent, the entire system, the entire shift in approach – it all lives in that one question. Not shouted. Said quietly, the way the genuinely important things usually are, while staring at the fire.

What We Actually Built – The Human Version

Before the DT and TRIZ analysis, let me translate the patent for you. Because the actual patent – US Application 20230206161, filed December 2021, published June 2023 – is written in the kind of language that exists specifically to be understood by patent examiners, IP attorneys, and people who consider “circumstances associated with a likelihood” to be a perfectly normal phrase to use in conversation.

US Application No. 20230206161

Here is what it says, stripped of the legal armor:

The core idea: Build a system that predicts, based on everything you know about a customer’s current situation, whether they are going to call you in the next N hours – and what they’re going to call about. Then act on that prediction before they pick up the phone.

The data it uses: Where the customer is in their workflow. What happened to their orders. How long things have been stuck at a given stage. Their entire history. Their behavior patterns. Hundreds of variables that individually mean nothing, but combined and fed into a model start to look like a suspiciously reliable crystal ball. The kind that actually works, which is unsettling, but we’ll take it.

The three things you do with the prediction:

One – a proactive chatbot or notification reaches the customer before they realize there’s a problem, addresses it, and either resolves it or routes it intelligently. The customer never had to pick up the phone. They feel taken care of. They think you’re a mind reader. You are, technically. Everyone wins except the people who were planning to be angry.

Two – a call deflection team gets a prioritized list: these 47 customers have a 75%+ probability of calling in the next N hours, here’s what they’ll likely call about, here’s the optimal outreach window. Instead of reactive chaos – agents sprinting to catch incoming fires they didn’t see coming – you have a planned, manageable, civilized operation. The team works the list. The list does not work the team.

Three – and this is the elegant part – the sales rep, who has to make proactive customer calls anyway as part of their KPIs, takes the list instead. Now the call that was going to be a frustrated customer dialing in about a problem becomes a proactive touch from their trusted relationship manager who, remarkably, already knows about the issue and has a solution ready. The customer feels valued and seen. The rep has a real reason to call that isn’t just “I have a call quota and you’re alphabetically next.” The relationship deepens instead of fraying at the edges.

Net result: fewer reactive angry calls. Better capacity planning. Reduced cancellations. Stronger relationships. Same headcount accomplishing more. Your CFO’s eye stops twitching. You get to sleep.

Now Let’s Dissect It

The Design Thinking Move

The problem as originally stated was: “We can’t keep hiring customer support people to keep up with demand.”

That is a solution masquerading as a problem. It assumes the only possible architecture is: customer has issue → customer calls → agent handles call → repeat forever, adding agents until the heat death of the universe. Classic framing trap – the kind Design Thinking exists specifically to break by asking increasingly uncomfortable questions until someone in the room admits the real problem.

The empathy phase asked a different question: what is the customer actually experiencing? Not “how do we handle their calls more efficiently” but “why are they calling at all, and what does it feel like to be them when they do?”

The answer, if you actually bother to go look, is not pretty. They’re calling because something in their workflow went sideways and nobody told them. They found out by noticing, waiting, worrying, refreshing a status page that hasn’t updated in three days, and finally picking up the phone out of frustration. The call is not the problem. The call is a symptom. The problem is information asymmetry – the company knows exactly what’s happening in the workflow, down to the minute (well, most of the time). The customer knows nothing. And nobody had identified this as a design flaw worth fixing.

The reframe – from “we have too many calls” to “our customers are calling because we haven’t told them things we already know” – is the Design Thinking move. Nothing about the underlying data changed. Nothing about the technology changed. The direction of the solution changed completely. Instead of building a bigger bucket to catch the water, you find and fix the pipe that’s been leaking all along.

The How Might We statement that emerged from Baker Street, somewhere around the third whiskey:

“How might we use what we already know about a customer’s situation to reach them before they have to reach us?”

That single reframe made the entire system possible. And it didn’t emerge from a workshop with color-coded Post-it notes and a facilitator encouraging everyone to “yes-and” each other. It came from a fireplace, a well-chosen single malt, and a room full of people who were annoyed enough by the problem to question its premises.

For the record: the whiskey didn’t solve the problem. But it did something Design Thinking’s empathy phase frequently fails to do in a corporate setting – it temporarily disabled the internal censorship mechanism that makes people say “interesting idea, but let’s be realistic” approximately four seconds after any non-obvious thought surfaces. The whiskey, in other words, did what the DT facilitator is theoretically supposed to do: it created psychological safety. Cheaper than a two-day offsite. Faster than an empathy mapping workshop. Marginally less sober, but significantly more honest.

And yes – the whiskey helped us think outside the bottle.

The TRIZ Analysis

Here is where it gets precise.

The contradiction:

Improving customer support quality requires more human engagement – more calls, more touchpoints, more personalized attention. But more human engagement costs money and headcount that cannot scale proportionally without the company eventually becoming a support operation that sells products on the side. You cannot simultaneously improve quality and reduce cost in a reactive support model. Every conventional attempt to do both produces something mediocre at both – the infamous “we value your call, your estimated wait time is forty-seven minutes” experience, which is the corporate equivalent of telling someone you care deeply about them while clearly demonstrating the opposite.

This is a textbook technical contradiction: improving Parameter A (customer service quality) degrades Parameter B (operational cost and scalability). The industry had quietly accepted this as the natural order of things. Physics. Gravity. Cost of doing business. Just the way it is.

TRIZ does not accept trade-offs. TRIZ considers accepting a contradiction a failure of imagination.

Principle 10 – Prior Action: Perform the required action before it is needed, in advance.

This is the exact principle at work. The customer service action – the engagement, the reassurance, the issue resolution – is performed before it is requested. Not in response to a call. In advance of one. The contradiction dissolves: proactive contact is simultaneously cheaper (planned, batched, workflow-optimized, no queue, no hold music revenue for anyone) and higher quality (timely, personalized, non-reactive, delivered by someone who already knows the context). You don’t choose between quality and cost. You remove the event that forced them to trade against each other in the first place.

Principle 15 – Dynamism: Allow characteristics of a process to change to be optimal at each stage of operation.

The system is not a static rule set. It does not say “call customers when orders are delayed for more than three days” and clock out. It is dynamic – the model continuously updates as context changes, probability scores shift as workflow states evolve, the priority list refreshes. It adapts to the specific moment of each specific customer rather than applying a protocol designed for the mythical average customer, who, as anyone who has worked with real customers knows, does not actually exist.

Principle 6 – Universality: Make a part or object perform multiple functions; eliminate the need for other parts.

The proactive contact mechanism doesn’t just deflect calls. It simultaneously functions as a sales engagement tool, a relationship management instrument, a customer satisfaction intervention, and a capacity planning input. One system. Four functions. Four separate processes that would otherwise exist independently, staffed separately, managed separately, reported separately, and argued about separately in quarterly business reviews by people who don’t talk to each other.

Trimming: The incoming reactive call – the angry customer on hold, the agent scrambling to pull up context they don’t have, the resolution that arrives two days after it would have been useful – is trimmed from the system entirely in the best case. Its function is transferred to the proactive outreach, which performs it earlier, cheaper, and with better outcomes for everyone except whoever was selling the hold music license.

Level of inventiveness on Altshuller’s scale: Level 3. The system doesn’t invent new technology. It uses existing data, existing models, existing communication channels, existing sales workflows. But it resolves a contradiction the industry had accepted as permanent by changing the architecture of the solution rather than optimizing any single component. That’s not an incremental improvement. It’s a structural reframe. The difference between turning up the volume and rethinking the acoustics of the room entirely.

The Patent’s Dirty Secret

Here is the thing about patents they don’t tell you until you’re already inside the process, which by then is too late to exit gracefully: the language is deliberately, structurally, professionally obscure. Not because lawyers are malicious – well, not entirely – but because abstraction serves a legal purpose. The broader and more generic the language, the wider the protective perimeter. Specificity is the enemy of coverage.

So “customer’s order got stuck and they’re probably going to call angry” becomes “circumstances associated with a likelihood that the provider will contact an enterprise of the provider network with respect to provisioning of the specific product to the specific user.” And “we reach out first with a fix” becomes “facilitating performance of one or more remedial actions through the enterprise to address the provider contacting the enterprise.”

The idea is the same. The Baker Street version took about ten minutes to explain, aided by whiskey and the natural clarity that comes from genuinely wanting to solve something. The patent version requires a law degree, two espressos, and a tolerance for the phrase “non-transitory computer-readable storage medium” appearing in multiple consecutive sentences without irony.

This, incidentally, is a TRIZ problem in itself. The contradiction: patent language must be abstract enough to provide broad protection, but specific enough to be defensible and novel. Every patent attorney lives inside this contradiction daily.

What DT + TRIZ Actually Gave Us

Looking back at the full arc from Baker Street to the patent office:

Design Thinking found the real problem. Not “too many calls” – but information asymmetry causing reactive contact at the worst possible moment for everyone involved. It found it by asking what the customer was actually experiencing, not what the business was measuring on a dashboard and calling “performance.”

TRIZ dissolved the contradiction. Not by balancing quality against cost – not by compromise, which is what mediocre solutions are built from – but by changing the temporal architecture of the intervention entirely. Move the action before the trigger. The contradiction doesn’t need to be managed anymore because it no longer exists in the same form.

The combination produced something neither framework would have found alone. Pure Design Thinking without TRIZ would have generated empathy maps and journey diagrams and a beautifully articulated problem statement – genuinely valuable, but not necessarily pointing to this structural solution. Pure TRIZ without Design Thinking would have started from the wrong problem entirely – optimizing call-handling rather than questioning whether the call needed to happen at all.

The handoff was the key. Design Thinking ran until there was a clean contradiction. TRIZ ran from there.

The whiskey, the fireplace, and Baker Street were, in retrospect, load-bearing elements of the solution.

Patent reference, for those who enjoy that sort of thing: US Application No. 20230206161 – full text available, legal armor and all. Bring espresso.

A footnote worth adding: the implementation of this system was recognized with a CIO-100 Award – an annual recognition of the 100 most innovative IT organizations in the US. Which means that somewhere between the Baker Street fireplace, a bottle of single malt, and Altshuller’s 40 principles, we accidentally built something that the industry considered genuinely innovative. The whiskey remains undecorated but no less deserving.