The kind of ongoing relationship a company establishes with a customer segment, self-service, dedicated support, automated, community-based, or co-created.
Customer Relationship is the building block of the Business ModelBusiness ModelBusiness ModelThe business model canvas or definitionView reference → Canvas that names the kind of bond a business establishes with each of its customer segments, and how it maintains that bond over time. It answers a question most product teams treat as ambient when it should be decided: when a customer needsNeedUserA user need, pain, desire, or constraintView reference → you, what do they get, a person, a help article, or a community of other customers. The answer shapes cost, tone, and how easy the relationship is to scale.
The block comes from Business Model Generation (2010) by Alexander Osterwalder and Yves Pigneur, where it sits between Customer Segments and Value PropositionsValue PropositionBusiness ModelA unique value offered to customersView reference →. The framing is deliberate: a relationship is established with a specific segment, and it exists to support a specific value proposition. The two adjacent blocks bracket it.
Osterwalder and Pigneur set out a small menu of relationship categories that has held up well. There is personal assistance, dedicated personal assistance, self-service, automated services, communities, and co-creation. Personal assistance puts a human in the loop, in a shop, on a call, or over email. Dedicated personal assistance assigns one representative to one account, the model of private banking. Self-service gives customers the tools to help themselves. Automated services go further, recognising the individual and tailoring the response without a person present. Communities let customers help each other and tighten the bond to the brand in the process. Co-creation pulls the customer into building the product, as a review platform does when it asks users to write the reviews that are the product.
The block also asks a strategic question underneath the category choice: is this relationship for acquisition, for retention, or for upsell. Those three motives pull in different directions. A heavy onboarding concierge is an acquisition and retention investment; an automated cross-sell prompt is an upsell mechanism. Naming the motive stops a team from defaulting to the most expensive relationship out of politeness.
A project-management tool serves two segments through two relationships. For self-serve teams paying £12 a seat, the relationship is self-service and automated: documentation, in-app guidance, and a chatbot that recognises the account and surfaces the right help. Headcount does not rise with that segment, which is the point. For enterprise accounts paying six figures a year, the relationship is dedicated personal assistance: a named customer success manager, quarterly business reviews, a private channel.
The split is a model decisionDecisionStrategyA recorded decision with context, rationale, and consequencesView reference → with a cost tail. The self-service relationship keeps the cost structureCost StructureBusiness ModelA cost category or structureView reference → flat as the long tail of small teams grows. The dedicated relationship is expensive per account and only pays for itself above a revenue threshold, so the company sets that threshold explicitly and refuses to assign a success manager below it. When a mid-market segmentMarket SegmentMarket IntelligenceA distinct group of potential customersView reference → emerges between the two, the team does not improvise; it picks a category, a hybrid of community plus periodic personal assistance, and prices it to match. The canvas keeps that choice visible, so support never quietly becomes a personal-assistance model for everyone.
In the Unified Product Graph, Customer Relationship sits in the business-model region and attaches to its model through Business ModelmaintainsCustomer Relationshiphierarchy. Its two governing links encode Osterwalder and Pigneur's bracketing: business_model_maintains_customer_relationshipCustomer RelationshipwithMarket Segmentcross-domain fixes who the relationship serves, and customer_relationship_with_market_segmentCustomer RelationshipsupportsValue Propositioncross-domain fixes what it is in service of. The structure matters because it forces every relationship to declare both its audience and its purpose. A relationship node connected to no segment is an aesthetic with no one on the other end, and the graph makes that absence visible before an undecided support model drifts into the most expensive default.customer_relationship_supports_value_proposition
Type-specific fields on BaseNode
relationship_typestringInteraction shape
acquisition_rolestringAcquisition funnel stage primarily served
retention_rolestringRetention lever primarily pulled in the customer lifecycle
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
3 edge types connected to this entity.
business_model_maintains_customer_relationshipcustomer_relationship_with_market_segmentcustomer_relationship_supports_value_proposition1 framework use this entity type.