The engagement model
An engagement is one specific delivery of a service to a customer over a defined period. If you run “Managed IT Support,” each customer contract is a separate engagement: “Managed IT Support for Acme, 2025.”
Every finance plan, KPI, and capacity entry attaches to an engagement.
How engagements fit
- Services are the parent. An engagement belongs to exactly one service.
- Contracts wrap engagements with commercial terms: value, type (fixed‑fee, T&M), dates, rate overrides, and SLA terms.
- Portfolios group services for strategic views, like “Key Accounts” or “Government.”
The hierarchy
- Your organisation: all data belongs here, isolated from others.
- Service: a type of offering you deliver, like “Cloud Hosting.”
- Engagement: a specific delivery, like “Cloud Hosting for Contoso FY25.”
- Data: finance plans and actuals, KPIs, hours, all at engagement level.
Portfolios cross‑cut services. A service can sit in more than one portfolio.
Engagement lifecycle
| Status | Meaning |
|---|---|
| Draft | Setup in progress. Not yet accepting check‑ins. |
| Active | Live and accepting monthly check‑ins. |
| On hold | Paused. Data preserved, no new check‑ins expected. |
| Completed | Delivery finished. History preserved for reporting. |
| Archived | Hidden from active views. Still available for analysis. |
A few notes on transitions:
- Templates must be assigned before going Active.
- On Hold pauses health score decay; re‑activate to resume.
- Completed locks the engagement for historical reporting.
Delivery parties
Each engagement can track two sides: a customer (consumer) and one or more deliverers (providers). Set a default party at engagement level and override per line or month for complex cases. This enables showback, multi‑vendor split, and partner accountability.
Related
- Engagements area: work with engagements day to day.
- Delivery attribution: how parties are tracked.
- Templates: how structure is defined.