Identify the services that will be hosted
List platform roles, connectivity components, CRM adapters, reporting tasks and monitoring collectors separately. Record which services must share a location and which can be isolated. Include temporary workloads such as imports, backups and maintenance jobs: they can compete with routine activity even when average utilisation looks low.
Choose the operating boundary before assigning a generic hosting label. Software support, operating-system maintenance, connectivity troubleshooting and platform administration are different responsibilities.
Mark included and client-operated work
| Workstream | Specify in the proposal | Acceptance evidence |
|---|---|---|
| Provisioning | Resources, storage, network placement and access route | Inventory and approved access checks |
| Maintenance | Patching owner, change windows and restart responsibility | Example change record and rollback procedure |
| Observability | Metrics, log access, alert destination and on-call boundary | A test alert reaches the named operating role |
| Recovery | Protected data, backup ownership and restore procedure | Recorded restore exercise against agreed objectives |
When an external platform or connectivity vendor must participate, identify the handoff and escalation route. A hosting supplier cannot resolve every application issue through additional CPU capacity.
Review the service through an operating day
Illustrative hosting review: routine activity overlaps with a scheduled reporting export. The team observes resource contention and decides whether to reschedule, limit or separate the job. The review records the measurement and the change approval rather than assuming a larger server is automatically the answer.
For an existing environment, bring recent incident windows, resource graphs and a service inventory. For a new environment, bring the expected activity profile and external dependencies. These inputs make a hosting proposal comparable and keep the support boundary visible after launch.