11. Contracting and Service Level Agreements

The relationship between the governing body and the operator, no matter which operational structure is chosen, is a crucial aspect of a successful PBS. This relationship and mutual respect for each other’s goals can either make for a very successful and adaptable PBS, or lead to tensions that compromise the customer (user) experience. This relationship is best defined in a contract between the governing body and the operator, with a performance management system put into place to incentivize and reward the operator for excellent performance. The means to doing this is a detailed Service Level Agreement that defines and quantifies the various pre-agreed “performance indicators.”

Land access and political and policy support are the greatest assets a governing body has in the creation of a successful PBS. Using these to leverage a quality, user-oriented system should be the goal of the governing body in the contractual arrangements made with an operator, no matter which business model and operator type is selected. The leveraging power provided by these assets varies, depending on the area. In those where land access is scarce and political support is valuable, as in a larger-density city, the leverage is high. In areas where land is less scarce or political will does not pull as much weight, there is still some leverage, but less so.

In some cities, operators may actually pay the government for the right to provide a PBS service because of the financial rewards they will reap through user subscriptions, sponsorship and advertising revenue. In other cities, governing bodies need to guarantee usership or offer to subsidize investment into the system because the operator’s profitability is not guaranteed.

CONTRIBUTE YOUR PEER REVIEW of this chapter. If you are an industry expert who has read the book, we would value your feedback.

The images and tables below illustrate some of the aspects of the ‘Contracting and Service Level Agreements’ chapter in the book Bicycle Sharing 101: Getting the Wheels Turning. They are meant to be viewed in the context of reading that chapter. 

nubija1

BS101-7992

ABOVE: This screen grab from South Korea’s Nubija system illustrates the more high-tech, IT-integrated fault reporting, while Tutubi in the Philippines relies on users’ turning their seats backwards to notify maintenance staff of a problem with the bicycle.

Examples of Service Level Agreements

View the Service Level Agreement by Transport for London and Serco Ltd, agreed in 2009: London Cycle Hire Service Agreement

View the Service Level Agreement proposed by New York City in 2010:NY RFP SLA. (This is an extract of the fuller Request for Proposals to Provide a Bikeshare System in the City of New York: NY RFP)

Here’s an extract of it, to illustrate the principles outlined in the book.

Col. 1

Col. 2

Col. 3

Col. 4 Col. 5 Col. 6 Col. 7 Col. 8
Ref. Performance Indicator (PI) PI Description Measurement Tool Measurement Period Units Threshold 1 Threshold 2
PI-1 Overall system functionality Combined total minutes that all Stations are out of commission per week. Central Computer Database Weekly Minutes

Proposer should define Threshold

Proposer should define Threshold

Proposer should define $ value

Proposer should define $ value

PI-2 Stations in service Percentage of Stations in service. Extrapolation from field checks by DOT staff.

Daily

Percentage of Stations

Proposer should define Threshold

Proposer should define Threshold

Proposer should define $ value

Proposer should define $ value

PI-3 Station in service (per Supergrid) Percentage of Stations (per Supergrid) that are in service. RFID-based maintenance logs.

Daily

Percentage of Stations

Proposer should define Threshold

Proposer should define Threshold

Proposer should define $ value

Proposer should define $ value

PI-4 Bicycles in service Percentage of Bicycles in service. Central Computer Database

Daily

Percentage of Bicycles

Proposer should define Threshold

Proposer should define Threshold

Proposer should define $ value

Proposer should define $ value

PI-5 Bicycle cleanliness Percentage of Bicycles that are clean. Extrapolation from field checks by DOT staff. Every 3 days Percentage of Stations

Proposer should define Threshold

Proposer should define Threshold

Proposer should define $ value

Proposer should define $ value

PI-6 Station cleanliness Percentage of Stations that are clean. Extrapolation from field checks by DOT staff. Every 3 days Percentage of Stations

Proposer should define Threshold

Proposer should define Threshold

Proposer should define $ value

Proposer should define $ value

PI-7 Grafitti, “scratch- itti,” sticker removal from Stations and Bicycles Time taken to remove grafitti, “scratch-itti,” and stickers etc. after notification. RFID-based maintenance logs with photo documentation

From the time of notification to Contractor’s resolution

Hours

Proposer should define Threshold

Proposer should define Threshold

PI-8 Snow removal from Stations immediately after snowfall. Time taken to remove snow from Stations after snowfall. RFID-based maintenance logs with photo documentation

From the time of notification to Contractor’s resolution

Hours

Proposer should define Threshold

Proposer should define Threshold

Proposer should define $ value

Proposer should define $ value

PI-9 Snow removal from Stations after street plowing or other. Stations that are free of snow 5 hours after snowfall. RFID-based maintenance logs with photo documentation

From the time of notification to Contractor’s resolution

Stations

Proposer should define Threshold

Proposer should define Threshold

Proposer should define $ value

Proposer should define $ value

PI-10 Bicycle distribution Bicycle/Dock ratio or other method to be defined by Proposer. Proposer should define Proposer should define

Proposer should define

Proposer should define Threshold

Proposer should define Threshold

Proposer should define $ value

Proposer should define $ value

PI-11 Station Removal and Site refurbishment upon DOT request Time taken to remove Stations and  refurbish the site after requested to do so by DOT. Field checks by DOT staff

Daily

Days

Proposer should define Threshold

Proposer should define Threshold

Proposer should define $ value

Proposer should define $ value

PI-12 Immediate Station site physical condition maintenance reports to DOT Timeliness of reports. Receipt of reports by DOT staff Weekly Reports

Proposer should define Threshold

Proposer should define Threshold

Proposer should define $ value

Proposer should define $ value

PI-13 Financial/use and maintenance reports to DOT Timeliness of reports. Receipt of reports by DOT staff Weekly Reports

Proposer should define Threshold

Proposer should define Threshold

Proposer should define $ value

Proposer should define $ value

Would you like to add to the discussion?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s