2. Rural Paratransit Needs

2.1 Typical Operations

When most small to medium size agencies started up they used a manual system for reserving and scheduling trips, and they would require that trip reservations be made at least 24 hours in advance. Two types of manual systems were typical: the clipboard and the trip ticket.

The clipboard system is the simplest method and is practical for only small agencies. Five clipboards are hung on hooks on the wall representing the next five business days. Each clipboard contains one or more lined sheets for each vehicle. Each line on a sheet represents a 15 to 20 minute time interval. When a client calls in to reserve a trip, the client's name and pickup and drop off times and addresses are written in an empty line on one of the sheets. If no empty lines are available, the client either adjusts their desired times or the trip is denied. Each day the sheets for that day become the driver manifests and are distributed to the vehicle drivers. Blank sheets are placed on the clipboard and it now becomes the schedule for the fifth day. If the agency accepts subscriptions, each subscription is written on a separate sheet of paper and kept in files for each day of the week. Typically, when a new fifth-day clipboard is created, the subscription trips are written onto the sheets before any telephone reservations are accepted. The driver manifest sheets provide data for the monthly reports.

In the "trip ticket" system, each trip is hand written onto a color-coded sheet of paper (e.g. yellow for a single trip, blue for a subscription (recurring) trip, pink for a subscription with variations, etc.). The basic information for each trip is recorded on the trip ticket (e.g. client name, pickup and drop off times and addresses, purpose of the trip, etc.). These sheets of paper are called trip tickets. All of the trip tickets for a given day are assembled on the previous day. They are then sorted into piles, with each pile containing the trips for a particular vehicle. Lined sheets of paper are used to record the information from each trip ticket in a pile. The lines on the sheet may represent 15- or 20-minute intervals. Once filled out, the sheets of paper become the driver manifests. During the day, the driver records that status of each trip onto his/her driver manifest and returns it at the end of the day to the accounting person. The accounting person assembles all of the trip tickets and driver manifests for the accounting period (usually a month) and extracts, aggregates and summarizes the data for the reports and invoices.

As agencies grew and reporting requirements became more complex, the administrative workload began to require a disproportionate share of the agencies' time and resources. At some point during the growth process most agencies looked for computer technology to help with the scheduling and reporting functions. Several commercial packages were available to choose from ranging in price from about $5,000 to more than $75,000. Software features varied with the price from basic spreadsheet type applications to sophisticated geographical information systems (GIS) with automatic trip scheduling. Agency personnel, who were not skilled in computer use, were faced with the necessity to evaluate the trade-offs between cost and features.

Competition among software vendors is quite intense, and the permutations of purported features and prices are overwhelming. The purpose of this report is not to compare the claims of various software vendors, but rather to survey a select group of small-to medium-sized agencies and attempt to shed some light on the software features that are most useful for them, and the strategies used by the various agencies to implement these features. In order to meet these objectives effectively, a software product was identified that is both low cost ($5,000 to $7,500) and that is being used successfully by a wide range of small- to medium-sized agencies.

2.2 Agencies Surveyed

Data were obtained from nine small- to medium-sized transit agencies from around the country in order to evaluate the types of information that they consider most important. The agencies vary in size and type of operation. The number of clients served ranges from about 450 to about 8,000. The number of trips per month ranges from about 700 to about 17,000.

All of the agencies surveyed are currently using computer software to assist them with their operations. All of the agencies selected are successfully using the same low-cost software product.¹ The variety of ways in which it is applied provides insight into the most important needs of small- to medium-sized agencies. The details of the survey are included in Appendix A. The data summarized below and included in Appendix A were collected March 2000 to September 2001 and, therefore, do not necessarily represent current activity.

Clinton, Iowa

Colfax, Washington

Coos Bay, Oregon

Ellsworth, Maine

Grants Pass, Oregon

Ithaca, New York

Kearney, Nebraska

Salem, Oregon

Woodburn, Oregon

2.3 Typical Operational Procedures

Figure 1 depicts the typical operating procedures for the nine agencies. There are four distinct areas of responsibility listed along the right-hand-side of the Figure.

The system administrator is frequently the office manager. He/she has the responsibility for running the office, specifying the appropriate data to be collected, maintaining the integrity of the data, and producing the reports.

The reservationist is responsible for updating the client list, accepting trip requests from clients, establishing subscription trips for clients, verifying the eligibility of clients, confirming trips for clients, and changing and canceling trips for clients.

The scheduler is responsible for assigning trips and drivers to vehicles taking into account special conditions (e.g. wheelchair, car seat, etc.), pickup and drop off times, compatibility between driver and passenger (e.g. avoiding personality conflicts, drivers' ability to assist certain types of disabled persons, etc.), lunch breaks, and allowance of adequate time for loading and unloading individuals with a variety of disabilities.

The dispatcher is responsible for real-time trip management during the day's operations. He/she handles reassignment of trips due to changing schedules caused by new and/or cancelled trips, keeps track of trip "call backs," maintains communications with the drivers, and makes major schedule revisions in the case of breakdowns or other unanticipated events.

Often in small systems duties of the administrator, reservationist, scheduler, and dispatcher are all undertaken by one or two people.

2.4 Computer Support Needs

A computer application has been found to be beneficial for even the smallest paratransit agency (Woodburn, OR). The optimal software tool will provide a balance among functionality, ease of use, and cost. The boxes on the left-hand-side of Figure 1 indicate the principal data parameters that are needed in support of each of the responsibilities listed along the right-hand-side. Different software products use different schemes for storing data, but the basic data parameters remain the same. For purposes of conceptual clarity, each data parameter will be described as a database table in the following discussion.

Starting at the bottom of Figure 1, the system administrator customizes database tables containing selection criteria for the local situation. The Reservationist maintains the clients table in the database and enters trip tickets into the trip request table as they are received. The scheduler creates a day schedule for all tickets for a given day, and updates the trip request table to assign each trip to a vehicle and driver. A manifest is printed for each driver. The dispatcher utilizes the day schedule for the current day to make real-time adjustments to the vehicle schedules, and updates the final status of each trip in the trip request table for that day (e.g. delivered, no show, canceled, suppressed). The system administrator archives the completed trips and generates the report statistics. The principal database tables required to support these functions are described below.

2.5 Principal Software Data Parameters

As mentioned above, the principal data parameters needed by small- to medium-sized agencies will be conceptualized as database tables because that is the way they are typically configured in practice; even though the specific details of each software product will very. The information below is generalized from the data contained in Appendix A.

2.5.1 Clients Table

All agencies need a database table to record their clients (riders). One of the most time-consuming and redundant activities in non-computerized offices is the rewriting of the client's name and information each time a trip is reserved. The client table should contain the name and address of each client and also typical information specific to the client such as the funders of the client's trips.

2.5.2 Routes

The term, route, has several connotations. At the two extremes are: fixed route and demand-response route." Somewhere in between is the deviated fixed route. Fixed routes will not change for months or years, demand-response routes change daily and in some cases even hourly. Paratransit routes are combinations of demand-response and deviated fixed routes. Consequently, a paratransit route is commonly thought of as a place-holder (or vehicle slot) for a group of tickets that will eventually be assigned to the same bus and driver. For example, some schedulers start planning day schedules seven or even 14 days in advance by grouping the trips into routes. The vehicle and driver are then assigned to each route the day before the actual date of the day schedule, and manifests are printed for each route containing the driver, vehicle and list of trips.

Appendix A indicates that routes are used differently by different agencies. For example, Salem uses generic route names, Coos Bay uses some specific vehicle identifiers as well as two fixed route vehicles, and Colfax uses routes in some cases to help identify providers. Ellsworth, Maine, utilizes 40 POV volunteers for providing trips and they have elected to identify routes for each volunteer as well as some generic routes, as has Woodburn with 15 POV volunteers.

2.5.3 Trip Request Table

Historically each paratransit trip is recorded on a trip ticket. The trip tickets for future trips are stored in a trip request file whether it's a paper folder or a computer database table. The trip tickets for past trips are moved to an archive file where they are available for reporting purposes.

Each trip ticket must contain the information necessary for both scheduling and reporting purposes. The information necessary for scheduling includes the pickup time and address and the drop off time and address as well as special needs of the client (e.g. wheelchair, car seat, etc.). The detail reporting information varies from agency to agency, but the general types of information can be grouped into principal data parameters as described below.

Funders. This parameter identifies who pays for the trip. Typical funders include: Medicare, charities, state senior and disabled services, self (the rider pays), etc.

Providers. This parameter identifies who gets paid for the trip. Typical providers include: agency vehicles, taxi companies, other transit agencies, common carriers, privately owned vehicle (POV) volunteers, etc.

Purposes. This parameter identifies the purpose of the trip for eligibility and accounting purposes. A wide variety of purposes are displayed in Appendix A, common ones include: medical, dental, counseling, pharmacy, child care, adult day care, day rehabilitation, education, personal, and work.

Fare Types. Many agencies wish to print on the driver manifest the type of fare that the driver should expect from the rider. Appendix A indicates that typical fare types include: funder paid, direct bill, donation, cash, ticket, pass, permit, punch card, and no-pay.

Zones. Zones are geographical areas that are color coded to assist with the scheduling. Schedulers can group trips from and to the same geographical areas by visually grouping the color codes. For example in Appendix A it can be seen that Salem has identified zones by geographical sections of the city such as North, Northwest, North east, South, and Southeast as well as other meaningful neighborhood identifiers. Ellsworth, Maine, brokers rides for 85 cities and has identified cities for their zones, as has Woodburn with 17 Cities.

Jurisdictions. Agencies have found it important to identify jurisdictions for reporting purposes. Jurisdictions can be used to group clients (riders) by mutually exclusive political entity. For example, county commissioners or a city council may wish to know the extent of transit services being provided to their constituents. Appendix A indicates the wide variety of ways that Jurisdictions are used. For example Colfax, Wash., simply wishes to record whether the client was in the urban or rural area. Ellsworth and Ithaca identify cities as jurisdictions. Salem identifies a combination of a city, two counties, and rural vs. urban.

Other Special Codes. Most agencies require data parameters that are unique to themselves. To be useful, software must provide for customizable codes that can be recorded on each trip ticket, and in some cases printed on the driver manifest. Colfax and Ellsworth record billing codes for each trip. Ithaca provides custom codes that are printed on the driver manifest including: "Assist to door," "Enters via lift," "Oxygen," Get Hosp. WC," etc. Salem provides number codes that are printed on the driver manifest indicating the status (e.g. disability) of the rider.

Other Trip Ticket Information. Software should provide the capability for recording other information on the trip tickets such as the rider's gender, age group (e.g. child, youth, adult, elderly), ethnicity, phone number, etc.

Trip Status Code. Software should provide the capability for recording the trip status (delivered, no show, canceled, suspended) for each trip ticket.

Time and Mileage. Software should provide the capability for recording the time and mileage when each trip ticket is picked up and delivered. For most small- to medium-sized agencies this level of detail is seldom necessary. When it is necessary, it is typically achieved by means of a mobile data terminal (MDT) on the vehicle.

2.5.4 Route, Vehicle, Driver Information

For reporting purposes it is necessary for the software to record the vehicle and driver assigned to each route each day as well as to record the starting and stopping times and mileages for service and non-service time.

2.6 Principal Software Interface Features

Just as important as the type and amount of data parameters, is the ease with which the data can be entered and manipulated by the user. The functionality for the entry and manipulation of data are provided by "interface features." In the following section, the principal interface features are associated with the responsibilities of the users as depicted in Figure 1.

2.6.1 System Administrator

Data Entry and Editing. The system administrator needs features to customize the selection data for the trip tickets such as: the client table, vehicle table, driver table, funder table, jurisdiction table, providers table, purposes table, routes table, and zones table.

Archiving and Backup. Features need to be available for archiving past trip tickets and periodically backing up the databases.

Reporting. Different agencies have very different reporting requirements. Features must be provided to assist the user with selecting the data needed for individual reports. For example agencies need to be able to sort and select by any combination of the data parameters that they have defined for their system such as: client, funder, provider, purpose, jurisdiction, age group, client status (e.g. wheel chair, elderly, etc.), driver, etc. Figure 2 shows one type of summary report being used in Nevada.

For the nine agencies surveyed, more than 20 different reports are required. Therefore, the trip ticket information must be stored in database tables that are accessible to the user. For example, a commercial database like Microsoft Access® or Microsoft SQL Server® will provide the system administrator with the opportunity to easily develop his/her own queries and reports, whereas proprietary databases would require the system administrator to hire the software vendor whenever a change in reporting requirements occurred.

2.6.2 Reservationist

Client Updates. One of the main duties of the reservationist is to maintain the client table. Interface features should be available to add and edit client information.

Enter and Edit Trip Tickets. Features should be provided to select a client from the client list and initiate a new trip ticket with all of the client's default information already entered on the ticket. Changing the pickup and delivery times and addresses may be all that is necessary to create the trip ticket and enter it into the trip request table.

Enter and Edit Frequented Addresses. A table of frequented addresses contains a list of all of the addresses frequently visited by all of the clients. When creating a new trip ticket the reservationist need not type in each address, only click on one from the frequented address list.

Enter and Edit Subscription Trips. Features should be provided to enter subscription trips for a specified period of time and to check to see when existing subscriptions expire. It is also important to be able to suppress individual subscription trips without having to stop and restart the subscription.

Review Client Eligibility. The reservationist should have features available to check the eligibility of each client and to update the eligibility as appropriate.

Review Client Trips. Features should be provided to click on a client name and bring up all of the future trips tickets and subscription information for that client, and further to edit information on any trip or subscription.

2.6.3 Scheduler

Scheduling Trips. Features should be provided for the scheduler to view a day's trips in such a way that it helps him/her assign trip tickets to routes, and subsequently assign vehicles and drivers to those routes. This can best be accomplished by displaying the trip tickets in a matrix on the screen and providing features for conveniently moving the trip tickets between cells in the matrix. Automatic routing and scheduling using geographic information system (GIS) is normally not required by small agencies.

Pre-assignment of Trips to Routes. Features should be provided to assign a route to a trip ticket or a subscription at the time the ticket or subscription is created, and to automatically load the ticket into the appropriate route when the scheduler creates a new day schedule.

When an agency has 40 percent or more subscription trips, a pattern eventually emerges where the same trip tickets are grouped on the same routes each week. By pre-assigning the trips to routes, the scheduler is relieved of much unnecessary repetition. After the pre-assigned trips are loaded into a route, the scheduler loads the unassigned trips. In some ways a route populated with trip tickets by this method can be considered a deviated-fixed-route with the fixed part being the same group of trip ton the same day each week, and the deviated part the one-time-only trips that are inserted each week.

Driver Manifests. Features should be provided so that the scheduler can print driver manifests for each Route. The manifest should contain the vehicle, the driver and the list of trip tickets.

2.6.4 Dispatcher

Rearranging Trips in Real Time. It is the dispatcher's responsibility to communicate with the drivers and reassign trips in the case of an unexpected event such as a breakdown or a vehicle falling significantly behind schedule. Interface features should be available to facilitate the comprehension of the current status and the rearrangements that are necessary to meet the current situation.

Trip Feasibility. It is typically the dispatcher's responsibility to decide whether or not a new trip can be added to a vehicle that is already in operation. The dispatcher should be able to view a display, or access some other feature, that would permit him/her to decide immediately if the trip should be denied or accepted.

Trip Status. Frequently someone (often a parent) will call the dispatcher to inquire about someone else's trip. The dispatcher must have a convenient way for locating specific trips by client name.

Assigning Trip Status. The disposition of all of the day's trips must be recorded. Most agencies signify that a trip has been: delivered, no-show, canceled, denied, or suspended. Features for assigning these indicators to groups of tickets as well as individual tickets should be provided. For larger systems, the software should provide for interfacing with MDTs to accomplish this task.

2.7 Wide Area Implementation Technology

It is generally recognized that pooling vehicles and combining the reservations, scheduling, dispatching, reporting, and other operations of small transit providers can result in significantly better service for everyone. Each of the agencies included in this survey conduct their own operations. However, there is serious consideration in other areas for networking widely dispersed small agencies into a centralized system in order to achieve economies of scale. Such a system would have a single location for maintaining a centralized database, taking phone calls, and reserving trips. In the extreme, such a system would also dispatch vehicles from the central location. The proposed mechanism for achieving centralization over a wide area is referred to as thin-client technology.

Thin-client technology is characterized by the implementation of all data and processes on computers at a single location, and connectivity to remote sites by means of high speed lines (e.g. the Internet). Some of the advantages and disadvantages of centralization are summarized below.

Management and oversight. Centralization facilitates maintaining records, standardizing reports, generating special high level (political) presentations, preparing grant proposals, quality control, and numerous other important functions that can be performed by aggregating and comparing region wide data. It may also foster consistency throughout the region in order to obtain economy of scale and also to provide affordable assistance and support to the small communities.

Coordination between Public Providers. Centralization facilitates linking demand-response trips between public providers over a wide area. However, this type of activity is normally handled by shuttles that have more-or-less fixed schedules and are not part of a global optimization scheme.

Connectivity. Implementing thin-client technology is problematic for a system constrained by 56K modem. Our experience indicates that many rural communities have unreliable service and, even with a 54K modem, actual transfer rates vary from about 24K to less than 7K at times. It may be several years before DSL or other high speed connection is available and reliable in rural areas.

Local familiarity. Knowledge of the local situation is important for the success of any small transit agency. In the case of an unexpected event, such as a bus breakdown, it is necessary to: 1) accommodate the current riders, 2) notify parents that their children on the bus are OK but will be late, 3) notify and reschedule scheduled riders, 4) possibly mobilize another bus (with adequate special equipment) and driver, 5) make arrangements for the disabled vehicle. From the practical standpoint these activities would be difficult to accomplish from a remote centralized location by persons unfamiliar with the local situation.

Local schedulers and dispatchers know the idiosyncrasies of the clients and the vehicle drivers and they are best equipped to anticipate problems and/or make allowances to avoid problems.

Technology Dependency. A rigid centralized approach may have a tendency to replace local judgment with computer decision-making. The purported ability of computers to make decisions, and for technology to off-load our problems, is sometimes overly optimistic. If an agency becomes technologically dependent, and the technology falls short, the agency has increased its problems rather than solving them. Perhaps a more conservative approach would be to modify the centralized strategy by also providing individuals compatible tools which may be customized for the local situation to help them make better decisions at the local level.

2.8 Costs

The necessity for software features depends on several factors: the complexity of the reporting system, the number of individual trips vs. the number of subscriptions, the geographical extent of the area served, the need for mobile data terminals (MDTs) and swipe card technology, the number of privately owned vehicle (POV) volunteer drivers, and the perceived need for automatic positioning (global positioning system) and routing of vehicles. The cost of commercially available software for ranges from $7,500 to more than $50,000 for small- to medium-sized agencies. Installation and training is extra at a a rate between $1,000 and $2,000 per day. Service contracts range from about $100 per month to $1,000 per month.

2.9 Small- to Medium-Sized Operation

About 600 to 15,000 trips per month. The needs of most agencies in this range can be met with software costing between $7,500 to $10,000. The more complex features like automatic scheduling, GPS, point-to-point routing are usually not necessary.

2.10 Medium-Sized Operation

About 10,000 to 30,000 trips per month. The needs of most agencies in this range can be met with software costing between $10,000 to $35,000.