Service, product, service – promise and product
Blog: Tom Graves / Tetradian
Are we selling services, products or both? The short-answer is ‘Yes’ – but what we’re really selling, every time, is a promise…
The start-point for this was one of those ideas that arise first-thing-in-the-morning, seemingly without any warning:
Idea: In sales, the only thing actually sold is a promise of future value.
Services take action towards that promise.
Products are the outcomes of that action and/or records or confirmations of what we did towards that promise.
In reality, of course, the idea wasn’t entirely without warning. As part of this series on the relationships between service and product, I’d been working on a post about starting from product rather than service, so the idea presumably arose from there.
The core theme throughout all of this series is that ‘service’ and ‘product’ are not fundamentally different, but instead are just different types of views into a continual flow of creation and change of value. What we see as ‘service’ is a set of activities where value is being changed; what we see as ‘product’ is a static snapshot of value at a particular moment or specific set of conditions. A product exists only in a gap between services; and the boundary of a service is where we choose to draw that boundary, so in turn we make products ‘visible’ or ‘invisible’ according to where we draw those boundaries. In that sense, services lead to products lead to services lead to products, and so on, potentially ad-infinitum.
Yet let’s look at this from a sales-perspective. Whether we’re nominally selling ‘service’ or ‘product’, what we actually sell is a promise: we then have to deliver on that promise. In terms of the structure we’ve been exploring in this series of posts, that relationship would look something like this:
Even if we’re nominally selling a service, there should always be some kind of product at the end-point of that service-provision, to indicate that service has indeed been provided. For example, in a hotel, the room-cleaners would leave your own items nominally-untouched, but you’ll usually see that the end-sheet of the toilet-roll has been folded into a point, as an ‘indicator of service’. That change of status for the condition of the toilet-roll after the cleaning-service is literally a product of that service – an ‘indicator of service’.
To make sense of what’s going on here, we first need to note that any service sits at an intersection between two different axes of value. The one that everyone knows is what we’d see here as a ‘horizontal‘ flow of value – the supply-chain where each service adds a bit more value for the next one in the chain:
But the other axis is a ‘vertical‘ connection to what’s commonly described as ‘values’ – the shared-story or ‘enterprise within which the service-provider positions itself. At a whole-of-business level, we’d most commonly see this as the overall market, defining rules and standards so on to which each player within that market must align – though the ‘enterprise’ does actually extend beyond just the market, to the community, the country and more. We can summarise that intersection of ‘value’ and ‘values’ visually as follows:
When we look at it more closely, each transaction between players in the supply-chain is made up of multiple interactions. Some of these occur before the main transaction, setting up the conditions for that transaction – the promise that will guide the detail of the transaction. Some of these interactions will occur during what we would see as ‘the transaction’. Some occur after the transaction, in effect verifying that the promise has been met. (We’ll look at that in a bit more detail later.) So in that sense, we can summarise visually those relationships across the gaps between services as follows:
A gap between services, you’ll remember, is always and only bridged via some form of product – which means that there will often be a lot of service-products moving back and forth across each gap, in addition to the one ‘The Product’ that everyone can see. When we explore the full extent of supply-chain or value-web, the sheer number of products – and different types of product – can soon seem overwhelming:
Yet we can reduce this down to something more manageable via a simple somewhat-abstract partitioning of the activities of a service, along two axes – before, during and after (as above), and inbound-oriented, internal (‘this’), and outbound-oriented:
We can give abstract labels to each of those partitions:
…though it’s easy enough to find real-world labels for those partitions, such as these from a manufacturing context:
…or even the various roles, often assigned dynamically, the context of a small military unit:
Note, though, that that’s only the interactions along that horizontal-axis of value-flow. For any real-world service, we’d also need other interactions that connect across that ‘vertical’ axis of values – as shown in the full Enterprise Service Canvas model:
And every exchange or transaction across every gap between every pairing of services and child-services and subsidiary-services or whatever, always follows the same overall pattern. (Or rather, if it doesn’t follow that pattern, it’s likely to fail, especially in the longer term.) The pattern is what we might term ‘the Service-Cycle‘, which looks like this:
It’s a more-detailed version of ‘before, during, after’: in particular, it tells us more about what needs to happen in the ‘before’ and the ‘after’, and the typical sequence for what needs to happen. We can do things ‘out of order’, of course, but the dependencies between the elements are such that the sequence above is the one that works best.
(To make full sense of this, you’ll probably need to cross-refer back to the diagrams above. It’s all there – it’s just that, for the full detail, there’s too much to fit into a single diagram.)
In the ‘before’ part, we establish the promise:
— First, both parties verify shared-purpose and context – a connection via that ‘vertical-axis’ of shared-values, as an anchor for the value-proposition. (Note that a value-proposition is more than just ‘a fancy name for your product or service’, but is actually a bridge between perceived-value (horizontal-axis) and the respective values of the players and the shared-enterprise as a whole (vertical-axis).) This will typically involve aspirational-assets such as reputation and brand.
— Next, both parties verify who the parties are, and also verify the applicable scope. In a sales context, this would typically be person-to-person, whilst for a transaction between web-services, this would be done through system-protocols and calls to identity-management services – but the underlying principles are essentially in both cases. Either way, this will typically involve relational-assets that represent and record the links between the respective actors.
— Next, both parties establish the agreement for action – the requirements to be addressed in the transaction, and the rules and standards and suchlike that should apply. This is actually the promise itself – a commitment typically expressed in forms such as a sales-contract, the selection of web-protocols, or some other informal-yet-binding agreement. This will typically involve virtual-assets such as data-flows, signed contracts or paper-records.
At that point, we wait for some kind of trigger-event that shifts from ‘before’ to ‘during’. The trigger may follow on immediately, such as the acceptance of the agreement by both parties; or else it might wait indefinitely for some external event, and may never actually be triggered at all, as in the case of insurance-agreement. Either way, when the event does occur, we begin to take action on the promise:
— First, do any required actions to set up the required service. (Note: in the terms used in this series, it’s always a service – a product is an outcome of service, not the action itself.) This step will be required if there’s been a gap between promise and action – such as a gap of time, or location, or, in a classic B2B (business-to-business) sales-context, where the person receiving any goods is different from the person who signed off on the purchase. This step also addresses one of the nightmare-issue where a salesperson has sold something that doesn’t yet exist – a painfully-common scenario in software-development and other domains.
— Next, run the requisite service that will enact the transaction. (Again, remember, it’s always a service, because any activity always takes place within the context and boundaries of a service: any product to be delivered is an outcome of that service.) Note also that there must be an identifiable end-condition for the service, such as a specific product returned, a time-out reached, a specific room has been swept clean, and so on.
— Next, once the end-condition is met, complete the action, including verification of any products to be output from the service. This includes all action-records to be returned to the respective ‘interested parties’, within the organisation, or beyond (such as to auditors).
At that point there’s an implicit transition from ‘during’ to ‘after’. This needs to trigger off a set of activities to verify compliance to the promise. The key purpose of these activities is to build and sustain trust, across the shared-enterprise as a whole – because if that trust is lost, so is the enterprise:
— First, complete for the agreement. In a commercial context, we need to ensure that everything that we promised to do and/or deliver has been done – and for all respective stakeholders in that promise, not solely the respective ‘customer’. In return, we need to ensure that the customer (and, again, each related stakeholder) has delivered on their part of the agreement. For example, in a ‘post-paid’ commercial context – pay when goods and/or services have been received – this is the point at which the customer would pay, and the payment made in turn verified as matching the agreed amount. (In a ‘pre-paid’ context, payment would occur at some point within the ‘Conversation / contract’ or ‘Transaction / interaction’ phases, but the check against the initial promise would still need to occur here.)
(Note that the service-cycle does not stop here: falling for the ‘quick-profit cycle‘ mistake, and jumping straight back from here to the ‘Conversation/contract’ phase with a new prospect in a new service-cycle is a guaranteed way to cause failure in the longer-term. You Have Been Warned, etcetera…?)
— Next, complete for the relationship. The aim here is verify and sustain trust at a personal level – typically with the nominal client, but often with others as well. In a commercial context, we’d see this as customer-satisfaction checks and the like, where we’ll often also see metrics such as Net Promoter Score (though for the purposes here, Gross Demoter Score is perhaps even more relevant…). The promise is made to and with another person as person: that’s why this step is so important here, and must not be skipped.
— Finally, complete for the shared-enterprise – the shared-story that anchors the vision and values for the shared-enterprise. The aim here is to verify trust at the transpersonal level – the enterprise, the community, the country and more. In a commercial context, we’ll see this in forms such as reputation-mapping – which would include concerns such as hidden risks in co-branding and the like. Yet there also needs to be consistent effort to identify anticlient risks – both potential and actual anticlients – and seek out any kurtosis risks that could not just bring down a single organisation, but in some cases place an entire industry at risk.
That’s the full service-cycle, from preliminaries to promise to service and possible product, to all of the completions needed to maintain trust overall.
And each of those phases in the service-cycle needs to be supported via their own discrete services (symbolised in that diagram above by the small nine-cell grids), each of which require their own promises and products… – it can get real fractal, real quick, especially if we’re not careful how we map it, keeping the descriptions down to ‘Just Enough Detail‘ in each case. Yet precisely because it is a fractal-type pattern, we can use the same pattern everywhere, to help guide how to model it, and keep track of all the complexities. That’s the advantage here.
So to summarise again, for a sales-type context:
- what we actually sell is a promise – a commitment to deliver a specific service and, optionally, one or more specific products
- when the promise is accepted and (maybe later) actioned, it triggers a service, to deliver on the promise
- any product is an outcome or output from the service, becoming visible and accessible once it moves outside of the nominal boundaries of that service
- further services and products will be needed to verify compliance of service and product to the promise
I’ll leave it there for now – I hope it’s useful to you, anyway. And, as usual, over to you for your comments, if you would?
Leave a Comment
You must be logged in to post a comment.
