The Engagement-Centric Model
What is an Engagement?
A Service Instance Between Two Parties
An engagement represents a specific service being delivered to a specific customer over a defined period. If you run a “Managed IT Support” service, each customer contract is a separate engagement — “Managed IT Support for Acme Corp — 2025.”
Engagements are the fundamental unit of tracking in DigitalCore. All financial data, performance metrics, and capacity allocations attach to engagements.
How Engagements Relate to Services, Contracts, and Portfolios
- Services are the parent — an engagement always belongs to exactly one service
- Contracts are the commercial wrapper — an engagement can be linked to a contract that defines rates and SLA terms
- Portfolios are groupings — services (and their engagements) can be organised into portfolios for strategic views
The Entity Hierarchy
Organisation → Service → Engagement → Data Tracking
The hierarchy is straightforward:
- Organisation — Your company. All data belongs to one organisation and is isolated from others.
- Service — A type of offering you deliver (e.g., “Cloud Hosting,” “Brand Consulting”)
- Engagement — A specific delivery of that service (e.g., “Cloud Hosting for Contoso FY2025”)
- Data — Finance plans/actuals, performance KPIs, capacity hours — all at the engagement level
Portfolios as Cross-Cutting Groups
Portfolios group services across natural organisational lines. You might have a “Key Accounts” portfolio spanning multiple service types, or a “Government” portfolio grouping all public sector work.
Contracts as Commercial Wrappers
Contracts define the commercial terms for one or more engagements: contract value, type (fixed-fee, T&M), dates, rate overrides, and SLA terms with penalty definitions.
Engagement Lifecycle
Statuses: Draft → Active → On Hold → Completed → Archived
| Status | Meaning |
|---|---|
| Draft | Set up in progress. Not yet accepting check-in data. |
| Active | Live and accepting monthly check-ins. |
| On Hold | Temporarily paused. Data preserved but no new check-ins expected. |
| Completed | Service delivery finished. Historical data preserved for reporting. |
| Archived | Removed from active views. Still accessible for historical queries. |
What Happens at Each Stage
- Draft → Active: Templates must be assigned before activating. Once active, the engagement appears in the Operations workspace for check-ins.
- Active → On Hold: Health scores stop decaying for data freshness. Check-ins can resume when re-activated.
- Active/On Hold → Completed: Final check-in should be entered. Engagement moves to historical views.
- Completed → Archived: Engagement is hidden from standard lists but remains in the database for reporting and analytics.
Delivery Attribution
Customer Party vs. Deliverer Party
Each engagement can track two types of parties:
- Customer (Consumer) — The organisation receiving the service
- Deliverer (Provider) — The organisation delivering the service
Tracking Who Is Responsible for Each Cost or Metric
Delivery parties are assigned at the engagement level and can be overridden per item or per period. This enables granular tracking: “Who is responsible for this cost line?” or “Which delivery partner owns this KPI?”
Multi-Party Engagements
For complex engagements involving multiple delivery partners, each can be assigned as a separate delivery party. Costs and metrics can be attributed to specific partners, enabling showback and multi-vendor management.