Service-Dominant Logic

1. What Is Service-Dominant Logic?

Service-Dominant Logic (SDL) is a management and marketing framework that reframes business from “making and selling goods” to “applying competencies to help customers realize outcomes.” In SDL, service (singular)—defined as the application of skills and knowledge for the benefit of another—is the fundamental basis of exchange. Goods are important, but primarily as vehicles for service delivery, not ends in themselves.

In plain terms: customers don’t value your product per se; they value what it enables them to accomplish in their context (“value-in-use,” not “value-in-exchange”). Value is co-created through interactions among multiple actors (you, partners, customers, regulators, platforms), not delivered unilaterally at the point of sale. Your job is to propose how your capabilities combine with theirs to create outcomes—and to design the interactions, metrics, and business model around that process.

Consultants and executives use SDL to design value propositions, outcome-based pricing, platform/ecosystem plays, customer success operating models, and connected product strategies where ongoing service and data create compounding value.

2. Origin and Background

SDL was articulated by Stephen L. Vargo and Robert F. Lusch in their seminal paper “Evolving to a New Dominant Logic for Marketing” (Journal of Marketing, 2004) and refined in subsequent work (2006, 2008, 2016). They contrasted a traditional “goods-dominant” logic (value produced in the firm, exchanged at sale) with a “service-dominant” logic (value co-created in use, through interactions within service ecosystems). Their work synthesized strands from services marketing, resource-based theory, and institutional economics.

Why it was created: to explain and guide business in an economy where intangible assets, knowledge, relationships, and platforms drive value more than physical outputs. SDL provides concepts for designing business models around capabilities, interactions, and outcomes rather than features and units.

How it became known: through academic literature, executive education, and diffusion into design thinking, service design, and platform strategy. Terms like value-in-use, co-creation, resource integration, and service ecosystems are now common in modern operating and business-model design.

3. How Service-Dominant Logic Works

SDL rests on a set of foundational premises and a few practical distinctions that make the logic operational for executives.

Core ideas (simplified)

• Service is the basis of exchange: All economies are service economies; goods are distribution mechanisms for service (e.g., a compressor “delivers” compressed air service).
• Value is co-created: Firms cannot deliver value; they can only make value propositions. Value materializes when customers (and other actors) integrate your resources with theirs in use.
• Value-in-use, not value-in-exchange: What matters is the outcome experienced in context (speed, reliability, risk reduction), not the features handed over at sale.
• Actor-to-actor networks: All social and economic actors are resource integrators; value emerges within service ecosystems shaped by rules, norms, standards, and platforms.
• Operant vs. operand resources: The most strategic assets are operant resources (knowledge, skills, relationships, data) that act on other resources—not just operand resources (equipment, inventory).

From goods-dominant to service-dominant (what changes)

• Unit of analysis: From unit sold to use episode/lifecycle.
• Offer design: From features to capabilities + interactions that enable outcomes.
• Pricing: From input-based (cost-plus, per unit) to value/outcome-aligned metrics (per use, uptime, results, % savings).
• Metrics: From shipments and gross margin to time-to-value, adoption, retention/NRR, outcome attainment, cost-to-serve.
• Operating model: From handoffs to ongoing engagement (customer success, analytics, co-innovation, ecosystem orchestration).

SDL “axioms” often cited

• Service is the fundamental basis of exchange.
• Value is co-created by multiple actors, always including the beneficiary.
• All actors are resource integrators.
• Value is uniquely and phenomenologically determined by the beneficiary (context matters).
• Value co-creation is coordinated through institutions and institutional arrangements (rules, standards, platforms).

Why this matters to business models and value propositions

• Value propositions become hypotheses about how your capabilities and interactions will help customers achieve outcomes in context; proof comes from usage and results, not catalogs.
• Business models shift toward recurring/service revenue, usage/outcome-based metrics, and ecosystem roles where you orchestrate or participate in value creation across actors.
• Capabilities and data (operant resources) move to the foreground—analytics, domain expertise, partner management—often mediated by connected products and platforms.

4. When to Use Service-Dominant Logic

Most helpful for:

• Business model shifts: Product → subscription, usage-/outcome-based contracts, product-as-a-service, servitization.
• Platform and ecosystem plays: App/integration marketplaces, data exchanges, partner solutions where value is co-produced.
• Connected/IoT offerings: Designing lifecycle experiences (onboarding, monitoring, optimization) that deliver outcomes over time.
• Customer success and retention: Organizing for adoption, value realization, and net revenue retention instead of one-time sales.
• Service design and experience transformation: Reducing friction across “moments that matter,” aligning org, tech, and partners.

Especially powerful when:

• Customers judge success by outcomes (uptime, compliance, time saved) rather than specs.
• Multiple actors (partners, regulators, users, buyers) shape value; interactions and standards matter.
• Data and learning effects can compound value post-sale.

Less effective or potentially misleading when:

• Used as jargon without changing pricing, metrics, or operating model—it becomes “service theater.”
• Applied to pure commodities where differentiation through interaction/outcomes is minimal (though even there, service layers can add value).
• Over-romanticized as “customers do everything”; SDL still demands strong capabilities, governance, and economics.

Practice evolution: Modern adopters blend SDL with Jobs-to-Be-Done for customer outcomes, the Business Model Canvas for model coherence, Operating Model Canvas for execution, and Profit Formula for unit economics aligned to value-in-use.

5. How to Apply Service-Dominant Logic: Step-by-Step

1. Start with value-in-use: define outcomes and context

   Articulate the customer’s desired outcomes (JTBD) and constraints (skills, systems, risk, policy). Translate outcomes into measurable result metrics (e.g., “reduce unplanned downtime to < 1%,” “close books in 2 days”). Segment by context (SMB vs. enterprise, regulated vs. not).

2. Map actors and resource integration

   List all actors who shape value: users, economic buyers, partners, integrators, regulators, data providers. Identify the resources each brings (data, expertise, equipment, access) and where integration/coordination is needed.

3. Design the value proposition as a set of interactions

   Specify the capabilities you will apply (analytics, domain expertise, support), the touchpoints (onboarding, monitoring, optimization), and the co-creation mechanisms (workshops, APIs, self-serve tools, customer success cadences). Describe “who does what, when” to realize outcomes.

4. Choose pricing and the price metric aligned to value-in-use

   Select a metric that tracks outcomes or usage (per active asset, per workflow, per uptime, % savings). Define a corridor and tiers. Where feasible, incorporate outcome-based elements (credits/bonuses) with clear attribution rules and guardrails.

5. Set SDL-aligned success metrics

   Replace output metrics with outcome and adoption metrics: time-to-first-value, usage depth, outcome attainment, retention/NRR, cost-to-serve, and partner contribution. Make these the headline KPIs for product, success, and sales.

6. Align the operating model

   Use the Operating Model Canvas (POLISM) to create: customer success roles, data/analytics stack, service blueprints, partner enablement, and management rhythms (QBRs focused on outcomes). Build feedback loops from use to roadmap.

7. Instrument value realization

   Instrument products and services to capture outcome proxies (e.g., MTBF/MTTR, processing latency, error rates). Provide shared dashboards to customers; use them in QBRs and as the basis for renewal/expansion conversations.

8. Pilot, learn, and scale

   Run pilots with “lighthouse” customers. Define thresholds (e.g., outcome lift ≥ X%, adoption ≥ Y% by week 8, payback ≤ Z months) to trigger scale. Document co-creation practices and codify playbooks.

9. Govern the ecosystem

   When multiple actors are essential, define standards, APIs, certification, incentives, and dispute processes. Align incentives (revenue shares, credits) with shared outcomes.

10. Continuously evolve the profit formula

    As value-in-use is proven, revisit price corridors, cost-to-serve, and capital velocity (prepay, financing). Redirect investment to high-elasticity levers (adoption, outcome features) surfaced by cohort economics.

6. Example: SDL in Action

Context: “HydraAir,” a $750M industrial manufacturer sells compressed-air systems as capital equipment. Customers complain about unpredictable downtime and energy costs; purchases are lumpy; margins fluctuate. HydraAir pivots to “Air-as-a-Service” (AaaS), aligning to SDL.

Value-in-use and outcomes

• Customer outcomes: guaranteed air availability (uptime ≥ 99.7%), lower energy per unit of output (−15%), predictable cost.

Actors and resources

• HydraAir (assets: compressor expertise, analytics, service network); Customer (operators, production schedules); Energy utility (tariffs); Finance partner (asset financing); IoT connectivity provider.

Value proposition (capabilities + interactions)

• Onboarding: site audit, right-sizing, IoT sensor install; co-creation of an “air profile” with the customer.
• Run phase: remote monitoring; predictive maintenance; tariff-aware optimization; monthly outcome reporting.
• Customer Success: quarterly reviews on uptime/energy; joint improvement plans.

Pricing and metrics

• Price metric: $/Nm³ delivered + uptime SLA with credits; volume discounts by cohort; optional “Energy Optimizer” add-on at % of savings.
• Success metrics: time-to-first-value (≤ 30 days), sustained uptime (≥ 99.7%), energy intensity (−15% by month 6), NRR ≥ 110%, cost-to-serve per site trend.

Operating model

• Customer Success team; 24/7 monitoring center; partner maintenance network; data platform for outcome dashboards; outcome-oriented incentives for field service.

Results (12–18 months)

• Average uptime 99.8%; energy intensity −17%; NRR 114% via multi-site expansion and Optimizer attach (38%).
• Cost-to-serve per site −21% due to predictive maintenance; device financing + annual prepay improved cash conversion cycle to −7 days in AaaS cohorts.
• Sales mix: 42% of new logos choose AaaS; EBITDA +8 pts vs. hardware baseline. SDL practices (co-created “air profile,” outcome dashboards, success QBRs) codified in playbook.

7. Strengths and Limitations

Strengths

• Aligns strategy, value proposition, and business model around customer outcomes, not internal outputs.
• Supports recurring revenue, retention, and expansion by operationalizing value realization.
• Reveals ecosystem opportunities (partners, platforms) and shifts attention to operant resources (capabilities, data, relationships).
• Improves cross-functional coherence—product, sales, success, and finance share outcome-centered metrics.

Limitations

• Easy to talk about, hard to run: requires instrumentation, customer success, and often a culture shift.
• Outcome-based pricing increases delivery risk; needs robust attribution, guardrails, and financial modeling.
• Not a panacea in commodity spaces without service leverage or in contexts where actors are unwilling to collaborate.
• Can become abstract if not tied to concrete processes, economics, and governance.

8. Common Pitfalls (and How to Avoid Them)

• “We deliver value” theater
  What goes wrong: Outcome language with feature-led offers and unit pricing; little change in behavior.
  How to avoid: Change the price metric, KPIs, and incentives to outcomes; instrument time-to-value and retention.
• No proof of value-in-use
  What goes wrong: Claims without measurement; renewals stall.
  How to avoid: Build shared dashboards; set baselines and targets; use QBRs to review outcome attainment.
• Misaligned incentives
  What goes wrong: Sales comp for bookings only; success teams underfunded; services penalized for usage.
  How to avoid: Tie comp to NRR, adoption, and outcome KPIs; fund success as a growth engine.
• Outcome-based pricing without guardrails
  What goes wrong: You take on customer- or market-driven risks you can’t control; margins volatile.
  How to avoid: Use hybrid models (base + outcome), define attribution rules, cap credits, select customers with fit, and pilot first.
• Ignoring partners and institutions
  What goes wrong: Value depends on third parties (integrators, regulators), but roles and standards are vague.
  How to avoid: Formalize service ecosystems: standards/APIs, certifications, SLAs, and incentives for partners.
• Underestimating cost-to-serve
  What goes wrong: Value realization is labor-intensive; economics suffer.
  How to avoid: Use data and automation; segment service levels; monitor cost-to-serve by cohort; price accordingly.

9. How Service-Dominant Logic Relates to Other Frameworks

• Business Model Canvas (BMC): SDL guides how you fill “Value Proposition,” “Customer Relationships,” “Revenue Streams,” and “Key Partners/Resources/Activities” around outcomes and interactions rather than features and units.
• Value Proposition Canvas (VPC) / Jobs-to-Be-Done (JTBD): Provide the customer outcome lens (jobs, pains, gains) that SDL demands; SDL adds how value is co-created through interactions.
• Profit Formula Framework: Converts value-in-use into pricing metrics, cost-to-serve, unit contribution, and cash velocity; essential for outcome/usage-based models.
• Operating Model Canvas (OMC): Translates SDL into roles (customer success), processes (onboarding, monitoring, optimization), systems (analytics, telemetry), partners, and a management system (QBRs, outcome KPIs).
• Service Blueprinting: Maps the frontstage and backstage interactions through which co-creation happens; SDL provides the “why,” blueprints show the “how.”
• Platform Strategy & Network Effects: SDL’s service ecosystems logic aligns with platforms where multiple actors co-create value; governance and standards are central.
• AARRR / North Star Metric: Outcome-centered North Stars (e.g., “workflows successfully completed per week”) reflect SDL; AARRR tracks adoption/retention that signal value-in-use.

10. Key Takeaways

• SDL reframes business around service—the application of capabilities to help customers achieve outcomes—rather than the transfer of goods.
• Value is co-created in use by multiple actors; your job is to propose and orchestrate interactions and resources that realize outcomes.
• Design pricing metrics, KPIs, and the operating model around value-in-use (adoption, outcomes, retention), not units shipped.
• Use SDL to power product→service, usage/outcome-based models, platforms, and customer success; instrument value realization to earn renewal and expansion.
• Avoid buzzwords: tie SDL to concrete economics (profit formula), processes (OMC, blueprints), and governance (ecosystem standards, incentives).

11. FAQs About Service-Dominant Logic

Is “service” just services (human labor)?
No. In SDL, service is the application of competencies—which can be embedded in software, analytics, or devices. A product can be a vehicle for service when it enables outcomes through use and updates.

How is SDL different from being “customer-centric”?
Customer-centricity often focuses on satisfaction with touchpoints. SDL goes deeper: it changes the unit of value (outcomes-in-use), the economic model (price metrics), and the operating system (co-creation mechanisms, success metrics) to align to those outcomes.

Can SDL work for hardware businesses?
Yes—particularly with connected products and service programs (e.g., uptime contracts). Hardware becomes a platform for ongoing service (monitoring, optimization), priced on usage or outcomes.

How do we measure co-created value?
Define outcome KPIs that matter to the customer (uptime, cycle time, accuracy, energy intensity), baseline them, instrument usage, and review progress in QBRs. Link renewals/expansion—and sometimes credits/bonuses—to these measures.

Is outcome-based pricing required?
Not always. It’s a strong expression of SDL, but many firms start with usage-based pricing and outcome dashboards, then selectively add outcome components where attribution/control are clear.

How long does it take to adopt SDL?
Expect 2–3 quarters to pilot (instrumentation, success motions, pricing metric tests) and 12–24 months for full operating-model shifts in larger firms. Start with lighthouse customers and iterate.

What risks should we watch?
Overpromising outcomes, weak instrumentation, misaligned incentives, and underestimating cost-to-serve. Use hybrid pricing, guardrails, and careful customer selection while you mature capabilities.