Service Objects

The Essence

The Deliverable bridges the gap between sales promise and operational execution. It answers the question every customer silently asks after signing: "What actually happens now?"

Deliverables track what was committed (from Line Items), what's being worked on (from Services and Projects), and what's been completed (for the customer and the record). They create accountability for promises made during sales and visibility into fulfillment progress.

Implementation Note

Deliverable is the only non-native HubSpot object in this framework. Implementation options:

  • • Custom Object (Recommended): If you have Operations Hub Professional+ or Enterprise
  • • Rename Service Object: If not using Service for subscriptions
  • • Rename Listing Object: For project-based fulfillment tracking
  • • Rename Project Object: For pure project-based work

"Without Deliverables, commitments disappear into operational chaos; with them, promises become trackable, manageable, and verifiable."

Unified View Contribution

⚡

Team Enablement

Explore

Primary contributor. Deliverables are how delivery teams know what they need to do. Clear Deliverable records with owners, timelines, and specifications enable execution without ambiguity.
👥

Customer View

Explore

Supporting contributor. Deliverables provide customers visibility into what's being worked on and what's been completed. Portal views of Deliverable status build trust through transparency.
💰

Revenue View

Explore

Supporting contributor. Deliverable completion often triggers billing milestones. Deliverable status informs revenue recognition timing.
🧠

Business Context

Explore

Supporting contributor. Deliverable patterns reveal operational intelligence — delivery velocity, resource utilization, completion quality.

Sarah's Story

When Sarah's CVP Implementation Order was created, the commercial transaction was complete. But from Sarah's perspective, the real work was just beginning. What would actually happen? When? By whom? How would she know it was done?

Deliverables answered these questions.

From the Order's Line Items, Deliverables were created:

Deliverable 1: Chicago Headquarters - Foundation Build

In Progress
Source: Line Item "CVP Implementation - Foundation Phase" (Chicago)
Owner: Ryan (Technical Lead)
Timeline: 6 weeks
Acceptance: Unified Customer View operational, team trained

Deliverable 2: Detroit Facility - Foundation Build

Scheduled
Source: Line Item "CVP Implementation - Foundation Phase" (Detroit)
Owner: Ryan (Technical Lead)
Timeline: 4 weeks (after Chicago validation)
Acceptance: Detroit team using system independently

Deliverable 3: ERP Integration - Phase 1

Planning
Source: Line Item "ERP Integration Add-On"
Owner: Bill (Integration Specialist)
Timeline: 8 weeks (parallel to Foundation)
Acceptance: Order data flowing between systems without manual intervention

Each Deliverable had its own pipeline progression:

Planning → In Progress → Quality Review → Customer Acceptance → Complete

Sarah could log into her portal and see exactly where each Deliverable stood. No guessing, no waiting for update emails, no wondering what was happening. The Chicago build was 60% complete. The Detroit build was scheduled to begin next month. The ERP integration was in planning with Bill.

When the Chicago Deliverable reached "Customer Acceptance" stage, Sarah received notification to validate. She reviewed what had been built, confirmed it met acceptance criteria, and marked it accepted. The Deliverable moved to "Complete." The associated Invoice was triggered for that milestone.

This transparency transformed Sarah's experience. She wasn't a customer waiting for delivery; she was a partner with visibility into progress.

What It Holds

Commitment Reference

Every Deliverable links to what was promised — typically a Line Item from the Order. This connection maintains traceability: what was sold → what must be delivered.

Owner and Accountability

Who is responsible for this Deliverable? Clear ownership enables execution and creates accountability. The owner knows what they need to deliver; stakeholders know who to ask.

Specifications

What exactly needs to be produced? Deliverable specifications document requirements, scope boundaries, technical details, and quality standards. This is the "what" that the team executes.

Timeline

When is this due? When did it start? When did it complete? Timeline properties enable scheduling, capacity planning, and progress tracking.

Status and Pipeline

Where is this Deliverable in the delivery process? Pipeline stages provide standardized progression: Planning → In Progress → Review → Acceptance → Complete.

Acceptance Criteria

How will completion be validated? Clear acceptance criteria prevent scope creep, set expectations, and provide a basis for customer sign-off.

Outcomes and Notes

What was actually delivered? What challenges emerged? What would we do differently? Deliverable outcomes capture institutional knowledge.

What It Connects To

Primary Associations

To Line Items

What was sold that this Deliverable fulfills

To Orders

The transaction this Deliverable results from

To Contacts

The owner (who delivers) and stakeholders (who receive)

To Company

The organization receiving the Deliverable

To Projects

The transformation context (if applicable)

To Invoices

Billing triggered by completion

Deliverable Source Labels

Source Line Item
1

What was sold that this fulfills

Source Order
1

The transaction this results from

Primary Company
1

Organization receiving delivery

Parent Project
1

Transformation context if applicable

Parent Service
1

Ongoing service relationship if applicable

Deliverable-to-Contact Labels

Owner
1

Team member responsible for delivery

Stakeholder
∞

Customer contacts with visibility

Reviewer
1

Who validates quality internally

Approver
1

Customer contact who accepts completion

Common Patterns

The Line Item → Deliverable Pattern

When Orders are created, Deliverables generate from Line Items:
Order created → For each Line Item: Create Deliverable record → Copy specifications from Line Item → Set timeline based on delivery terms → Assign owner based on Deliverable type → Associate to Order, Company, relevant Contacts

The Pipeline Progression Pattern

Standard Deliverable pipeline stages:
StageWho ActsDuration
PlanningDelivery teamVariable
In ProgressOwnerMost of timeline
Quality ReviewReviewer1-2 days
Customer AcceptanceCustomer approverVariable
CompleteSystemTerminal

The Milestone Billing Pattern

Deliverable completion triggers billing:
WHEN Deliverable.stage = "Complete" AND Deliverable.billing_milestone = true
THEN: Create Invoice for Deliverable amount → Associate Invoice to Order and Company → Notify finance team → Update revenue recognition

The Location-Specific Pattern

For multi-location customers like Sarah:
  • • Separate Deliverables per location
  • • Each location has own timeline, owner, stakeholders
  • • Progress tracked independently
  • • Roll-up visibility at Order/Company level

The Dependency Pattern

Some Deliverables depend on others:
  • • Detroit build depends on Chicago validation
  • • ERP integration depends on Foundation completion
  • • Dependencies documented in Deliverable properties
  • • Pipeline automation respects dependencies

Value-First vs. Industrial-Age

✗ Traditional Thinking ✓ Value-First Thinking
Deliverables exist for internal tracking Deliverables provide customer transparency
Status updates require customer requests Status visible in portal automatically
Completion = internal sign-off Completion = customer acceptance
Billing based on time elapsed Billing based on value delivered
Deliverables invisible after handoff Deliverables visible throughout relationship
Scope documented elsewhere (SOW, project plan) Scope documented in Deliverable record

Why This Shift Matters

When Deliverables are internal tracking mechanisms, customers experience a black box. They signed the contract, and then... what? They wait. They ask for updates. They wonder if anything is happening. Trust erodes through lack of visibility.

When Deliverables are customer-visible progress records, trust builds through transparency. Sarah sees her Chicago build at 60% complete. She knows Detroit is scheduled for next month. She understands what "complete" means because acceptance criteria are explicit. Delivery becomes collaborative, not opaque.

In Practice

Implementation details and configuration

Key Properties

Key Properties

Property Type Purpose
deliverable_name Text What this Deliverable is called
deliverable_description Rich Text Detailed specifications
deliverable_type Enumeration Implementation, Training, Integration, Documentation, etc.
deliverable_status Pipeline Stage Current pipeline stage
owner User Who is responsible for delivery
due_date Date When delivery expected
start_date Date When work began
completion_date Date When marked complete
acceptance_criteria Text How completion will be validated
acceptance_status Enumeration Pending, Accepted, Rejected, N/A
billing_milestone Boolean Does completion trigger invoice?
billing_amount Currency If milestone, how much?
location_designation Enumeration For multi-location, which site
dependencies Association Other Deliverables that must complete first
outcome_notes Rich Text What was actually delivered, lessons learned

Deliverable Pipeline

1

Planning

Requirements documentation, resource assignment

Entry Criteria

Deliverable created from Order

Exit Criteria

Requirements documented, resources assigned

Portal Experience

In the My Value Path Portal, Sarah sees her Deliverables:

Active Deliverables

  • Name and description
  • Current status (pipeline stage)
  • Owner (who to contact)
  • Timeline and progress
  • Acceptance criteria

Pending Acceptance

  • What was delivered
  • Acceptance criteria recap
  • "Accept" / "Request Changes" actions
  • Comment capability

Completed Deliverables

  • What was delivered
  • When completed
  • Outcome notes
  • Associated invoices

"The Transparency Principle: Sarah never wonders 'what's happening with my project?' The portal shows her exactly where each Deliverable stands, who's responsible, and what happens next."

From Default to Value-First

1

Choose Implementation Approach

Custom object if available; rename native object if not.

2

Configure Pipelines

Create appropriate pipeline stages for your Deliverable types. Keep stages meaningful (5-7 max per pipeline).

3

Create Properties

Add properties for specifications, acceptance criteria, billing milestones, and outcomes.

4

Set Up Automation

Order → Deliverable creation, stage change notifications, acceptance workflow, billing milestone triggers.

5

Enable Portal Visibility

Configure Deliverables to appear in customer portal. Customers should see their delivery progress.

See It In Action

Experience in the Value Path Simulator

→ Deliverable Dashboard: See Sarah's view of her active Deliverables. Notice how each one has clear status, owner, and timeline.
→ Acceptance Flow: Watch Sarah accept a completed Deliverable. See how acceptance triggers the next steps (billing, notifications, progress updates).
→ Multi-Location View: See how Chicago, Detroit, and Atlanta Deliverables track independently while rolling up to overall engagement health.

Key Moment: Notice how Sarah never has to ask "what's happening?" The Deliverable architecture gives her continuous visibility into her transformation progress.

Experience Deliverable in the Value Path Simulator

Explore Further

Line Item Object Profile
The commitments that become Deliverables
Order Object Profile
Where Deliverables originate
Project Object Profile
How Deliverables organize into transformation work
Service Object Profile
Ongoing service context alongside Deliverables
Unified Team Enablement Overview
How Deliverables fit in team operations