Service design’s basic schtick is backwards planning from the human to the technical:

• from behaviors that make an organization flourish, to positive value exchanges that might motivate these behaviors,
• from positive value exchanges to good experiences that afford such value exchanges,
• from good experiences to service operation systems capable of delivering good experiences,
• from service operation systems to capability requirements that make the operations possible,
• from capability requirements to initiatives to develop the capabilities and actualize them.

This, of course, is exactly the opposite of business-as-usual, which goes more like this:

• from ad hoc development of functional capability, as practical needs surface,
• to hacking together of functions with technical integrations and manual processes,
• to attempts to patch up the worst customer pain points as they impact the business,
• to marketing spinning what ensues in order to attract customers faster than they leave,
• to colliding with the shocking reality that nobody’s motivated to do what the organization needs them to do.

The innovation tragicomedy: Business is never more business-as-usual than when it becomes enamored or panicked or otherwise fixated on some new technology. Everyone starts falling all over themselves in the headlong rush to prematurely answer the wrong question, which is: “How do we leverage this new thing?”

The right question is “What is the ideal for our organization and for the people who make it flourish by choosing to participate in it? How can we approach this ideal more perfectly, or even surpass it, using new capabilities enabled by this new technology?”

Everybody is asking me, “How does AI figure into service design?” They’re asking me because everyone’s asking everyone.

My answer is fairly simple. AI enters the process as another capability. By capability, I mean an enabling role or policy or process or technology.

And capabilities fit in a specific place within a longer sequence of questions — the sequence I outlined earlier.

We ask ourselves, “What do we need to happen here at this point in the service?”

We then ask, “What do we want each person to do? What do we want the customer to do? What do we need our employees to do to get the customer to behave as we hope?”

And we ask these questions through the lens of value exchange: “What are they after in this moment? What are they willing to put into it in order to get it?”

Then we ask, “What are the conditions required to actualize this value exchange? What makes this exchange and these behaviors happen?” This is where capabilities are defined.

And here is where we finally ask what everyone wants to ask too soon: “Can AI make this happen, or help make it happen, in the most effective and efficient way?”

What makes AI a little different is that it appears more as a role or process capability than as a traditional technology. But the good news is that service design doesn’t care much about this kind of blurring. AI can play the role of a person, but without the need to consider value exchange. It doesn’t care what it puts in or what it gets out of the interaction. Depending on context, this stakeless selflessness can seem altruistic or alien, and this should inform whether AI or human agency is the better choice. But the point here is that an AI role, like any human role, is a unit of agency constrained and enabled by role responsibilities, policies, processes and technology. And defining and coordinating agency has been central to service design from its earliest origins as a discipline.

Service design is the design discipline best positioned to help organizations make wise and pro-human use of AI.