In BriefBuilder, you cannot only define requirements concerning construction projects, but also concerning the related services, e.g. maintenance, security, catering, landscaping and cleaning services.
These services may be tendered separately or they can be part of the construction tender, e.g. in case of a DCM (Design, Construct & Maintain) or DBFM (Design, Build, Finance & Maintain) tender.
To define requirements for services, you can use the BriefBuilder services module. This module allows you to define the scope of the service contract and to capture requirements for each specific service (e.g. requirements concerning response times, operating hours, staff competences, applicable standards).
For monitoring purposes, you can also link services to specific types of quality measurements that have to be executed (e.g. condition measurements or satisfaction surveys) and to different types of performance failures which may come with requirements concerning repair times.
Essentially, you are then using BriefBuilder to make a service level specification (SLS) or service level agreement (SLA) that can you use for tendering, verification/compliance management and contract management — all within the BriefBuilder application.

In this article, we will explain how you can define requirements for services in BriefBuilder.
Object types
Just like all other BriefBuilder objects, services are defined in a ‘tree’ structure: a decomposition or breakdown structure of the requested services. This decomposition defines which services must be performed by the contract party.
To make this tree structure, ou can use two kinds of objects:
- Service group: a generic group of services that must be provided by the contractor / service provider (e.g. cleaning or maintenance).
- Service: a specific service task or activity that must be delivered by the contractor / service provider (e.g. cleaning of internal areas or plant maintenance).

The services are typically part of a service group. E.g. the service façade cleaning is part the service group cleaning. See example below.

In addition, you can use folders () to organize the requested services and service groups. Note that you can also add classifications and numberings to your services (see the TIP below).
Structure
The services tree is typically built up according to what is called an assembly structure: you start with groups of services and then add specific services that are part of that group.
For example: The service group maintenance may consist of the services reactive maintenance, planned maintenance of the building’s technical systems and the facade. See example below.

Requirements
For each service(group), you can define requirements concerning how or when they need to be executed and to which part of a facility they apply. This can be done on the detail view where you can find the following tables:
- General
- Properties
- Standard properties
- Relation tables (various kinds)
- Uploads
Below we will explain the use of each of these tables.
General
In the table ‘general’, you can enter a description of the requested service, explaining its general purpose and you can add label or a classification, if relevant.

Properties
The property table is where you can define specific requirements. The term property should be understood as a required attribute, capability, characteristic or quality of a service. Examples of properties are frequency, method and scope.
Properties can have text values, but you can also define very exact requirements with comparators (<, >, =, etc) and units of measure (e.g. hours, euros, ) and references to documents. More info about properties can be found here.
See below for a simple example for the service reactive maintenance.

To create properties for a service (group), click on the Add property button.
Standard properties
If it is possible to standardize properties across all services, you may want to opt for standard properties, which can be defined via the requirements settings menu. These properties are then automatically shown on the detail view of each service (group).
Standard properties for services could be:
Timing | Does a service need to be performed at particular hours/days? |
Response time | How fast does a service need to be performed after it has been requested? |
Standards | Are there specific norms or regulations that have to be complied with? |
Method | Is there a particular protocol or method that needs be applied? |
Staffing | Are there requirements that apply to the involved staff (e.g. certification)? |
Approval | Is there a particular approval process or approval period? |
Reporting | How does the service provider need to report to the client? |
In the settings menu, you can define for each property what kinds of values are allowed. Such as text, a number of specific options from a picklist, numericals, etc.

Relations
The relation tables offer you the possibility to link specific services to other parts of the model. See below for an explanation of the most important relations.
Spaces and locations
You can use this table to link a service to a specific spatial part of the facility. For example: you may want to link the activity daily indoor cleaning to the particular spaces that need to be cleaned on a daily basis. Or, perhaps you want to specify which buildings from your portfolio are part of the maintenance scope.
Please note that you can define specific properties for these buildings and spaces which can be relevant for the services that have to be provided. For cleaning it will for example be relevant to know the sizes of spaces. More info about that here.


Systems/elements
You can use this table to link a service to a specific technical system or element of the facility. For example: you may want to link the activity technical maintenance to the specific systems that have to be maintained.

Design principles
You can use this table to link a service to a particular design principle. In a DBM project, there may for example be design principles concerning sustainability that are also relevant for the project’s maintenance.

Monitoring
This table can be used to link a service to specific type of performance failure (e.g. performance failures of different degrees of severity), which you can then use to specify the related actions or consequences (e.g. penalties).

Furthermore, you can use this table to link a service to a specific quality measurement activity or method that has to be used to measure the delivered performance. E.g. a condition measurement or satisfaction survey. See example above.
All of the linked performance failures and quality measurements can obviously have their set of specifications. You can see these by simply clicking on the object.

Uploads
The last table on the detail page is the one for Uploads, where can add files that you feel are relevant for a service(group). For example, particular standards or reporting formats. Be careful, however, not to ‘hide’ any requirements in these files.
You can also add a note for a file, which you can you to explain its relevance, or to explain which part of the file is of particular importance.