Steam Train Ticket Software – 5 Key Things to Think About

When considering steam train ticket software for your heritage railway, there are many things to think about.  Here’s five that we think are key:

1) Does it do what you need it to?

You need to ensure that the software meets the needs of your business. You’ll need to check that the software handles your fare structure (i.e. Adult, Child, Family, Seniors, Special Trips, Discount Offers, etc.)  Do you need to have passenger manifests or historical reports?  Do you want to be aware when passengers with special needs might need support? Can passengers sit anywhere or travel on any trip during the day, or is there restrictions and does the software support this? You’ll need to identify what you have now, determine what you want in the future, and be aware that some things may need to change.

2) Who will be using it and what training is required?

Many heritage and steam railways are run primarily by volunteers.  This means that any new systems/software must be simple and require minimal training.  Determining who will need to be trained and their level of training, is directly related to the who will be using it and why.  Some users will provide customer service in the form of front desk or telephone operators, others may be managing boarding and seating, whereas others will be more concerned about the accounting or future projection of demand.  Be sure you know who will use the software, the type of training they require and understand that volunteers will have restricted and often, differing availabilities for training.

3) Where will the software be installed?

In the old days, software was created “bespoke” or individually built for each customer.  The software was then installed on personal computers, tills/cash registers and run either standalone or over a network.  This had significant upfront cost and with limited budgets meant that upgrades were often deferred indefinitely.   Today software is typically available via the internet with data stored in “the cloud”.  Access to the software is via WIFI or 3G/4G services meaning that you are no longer limited to specific locations.  This allows additional “ticket offices” up and down the line that only require a wireless connection and iPad, tablet or PC to operate.  It also allows passengers to purchase their tickets online and reservations to be checked while the train is moving.  The software is automatically upgraded for all users, meaning you always have the latest version.

4) Cost

Cost has been left until now (number #4), because although budgets are always limited, the first three reasons will determine the total cost.  The total cost must include the upfront, ongoing and organisational costs when choosing steam train ticket software.  The software costs can be structured a number of ways including the number of users, a periodic fee (e.g. monthly or annual) or a one-off cost with maintenance upgrades.  However, it is often the hidden costs of 1) the functionality that is available, 2) the users and time/effort and training, and 3) the way that the software is deployed, that will end up having a much greater impact on the day to day running of your railway.

5) Other factors

Of course, there are a variety of other factors that will affect how you choose which steam train ticket software is right for you.  They include the level of vendor software support and how passionate they are about steam/heritage vehicles, the current software you have and if it is truly “upgradeable” when the hidden costs are calculated,  and then more emotional factors such as “I like the way the screen does this”.  Be careful when considering other factors, as although they may seem important, the real consideration should always be passenger and team experience and the best return on your investment.

That’s all for today.  Have a great weekend.

Want to Create GTFS Data? What’s in GTFS feeds?

Create GTFS - General Transit Feed SpecificationHave you ever created a GTFS data feed and wondered what’s inside?  Well here’s a quick run down / lay persons guide….

A GTFS (General Transit File Specification) file is a group of files that have been “zipped”.  “Zipping” a file is a way of compressing a group of files or directories into a single file.  This makes the total file size smaller and quicker to copy around.  It also means the person who is transferring the zipped file only needs to think about the single zipped file, rather than having to remember all the files that have been compressed inside it.

The GTFS file will contain a number of required files and potentially some optional files.  The required files are enough to produce basic routes and schedules, whereas the optional files add supplemental information that enriches, supports and (sometimes) simplifies the required information.

The required GTFS files that must be created are:

  • Agency: Describes the company that provides the transit service
  • Stops: Describes where the vehicles pick up and/or drop off passengers
  • Routes: Contains summary information about a route detail (e.g. Jamestown Line, 452 Bus route, etc.)
  • Calendar: Specifies on which days a service runs
  • Trips: Contains information for each trip that occurs on a route for a particular service day
  • StopTimes: Contains the detailed information about the trip describing at what time the vehicle arrives and departs from a particular stop

You can also create GTFS files that are considered optional:

  • Calendar Dates: This file identifies which days have exceptions to the standard calendar (e.g. Altered services for holidays, additional services, no services, etc.).  Most GTFS feeds will include this file.
  • Fare Attributes & Fare Rules: These two files are used to describe the standard adult fare.  One of the limitations of the specification at the moment is that most transit operators have a variety of fares (e.g. Child, Seniors, Monthly tickets, etc.) and the file specification does not yet cater for these.  Rather than publish partial information, many agencies choose to not include fare information.
  •  Shapes: This file is used to draw the route on maps.  The majority of GTFS feeds will include this file.
  • Frequencies: This file is used to simplify schedules when a trip occurs at regular intervals (e.g. The bus runs every 30 minutes).  This file is typically included when you have a timetable that has a repeatable schedule for a number of hours, as it lessens the data keying effort, reduces the risk of errors.  It also enables the software that displays the information to better convey the schedule  e.g. “Every 30 minutes”, rather than “Next bus 30 minutes, then another in 1 hour”.
  • Transfers: This includes rules for making transfers between routes.  This file is typically included for major transit agencies (e.g. time between platforms or between bus bays), but is often not relevant for smaller agencies.
  • Feed Info: This describes who published the feed, what version of the feed it is and when it expires. The information inside this file is used by people who manage and manipulate the GTFS files. The inclusion of this file is a good idea (though of course, it is still optional).

We’ll discuss each of the files in detail in future posts.

If you can’t want and just need to know more now, the full specification is available here: https://developers.google.com/transit/gtfs/reference

And if you want to create GTFS data, you might way to try our GTFS Editor.  Here’s the link so you can get started: https://addtransit.com/sign_up.php

Have a great day!