The terms need, demand, requirement, request, order, call, and wish are often used interchangeably, which frequently leads to (potential) misunderstandings. A solid architecture requires clear definitions. In USM, these terms are positioned and defined as follows in the context of service delivery.
- A demand exists in the customer domain. The demand specifies something that the customer wants or needs in order to fill a gap.
- As soon as the customer decides to activate that need and fill the gap, the customer translates the need into a request to the service provider.
- The service provider receives the requests in the form of calls and categorizes them according to the triggers of internal processes and workflows: wishes, change requests, incidents, and service requests.
This relationship is represented in the USM Customer-Provider Interaction Model.

Primary concepts and alternative concepts
USM defines a demand as a (to the provider) yet unspoken specification of (an aspect of) the service that the customer wishes or needs in order to remedy a shortage. Only when the customer takes action, by converting this demand into a request to the provider to remedy the shortage, does an interaction-based service delivery arise.
The demand, request, or call may relate to both the facility and the support thereof.
The preferred terms are therefore demand, request, and call. Each of these preferred terms has one or more alternative or specific terms:
- Demand has the alternative term: need, or desire. The terms requirement and order can also be used as alternative terms here.
- The customer's request is called a ‘request’ from the customer's perspective, but from the supplier's perspective it is called a ‘call’. The terms requirement and order can also be used as alternative terms here.
- On the supplier side, a call is translated into the call types wish, change request, incident, and service request. Even if it concerns a proactive improvement from the provider that requires a contribution from a supplier, that provider translates the contribution to that improvement (the risk) via a request into a reactive call for the subsequent supplier in the chain.

