CBC Radio 1 will be looking at the issue of TTC customer service starting on Monday, January 11, and I will be on Metro Morning dark and early sometime before 6 am.

Updated January 11:  The Metro Morning interview is now available online.

The chats with story producers got me thinking about the TTC’s eAlert system as well as other sources of information.  Knowing we won’t possibly cover all the details in a short interview, and that other aspects of the discussion will certainly come from readers here, I have started this thread.

A long-standing complaint about TTC service is that nobody knows what is going on.  At the best of times, one might peer into the mists on Queen Street and hope that somewhere there is a streetcar, or listen down the subway tunnels for the familiar rumble of a train.  Far too often, the TTC is not at its best, and the lack of information can drive people into a fury, one that may be visited on hapless TTC staff who are no better off than the rest of us.

The TTC’s website can be hit-or-miss depending on whether it is being updated regularly.  For example, the 501 Queen car’s route description was not changed back from the Shaw/Parliament split until quite recently (thanks to feedback from a reader on this site).  However, the 512 St. Clair route description gives no hint of the split streetcar/bus operation.

Diversions pose a special challenge because some are implemented thanks to emergencies such as fires or major collisions, but the most annoying are those implemented locally by the route management team, and not reflected on the website or on notices at bus and car stops.  The 41 Keele (local) service is diverting around construction at St. Clair southbound, but it took a few weeks for this to show up online, but only in the route description.  The schedule page and map still show the route running via St. Clair, and you can look up times for a stop that in fact has no service.  The info is on the “Diversions” page, but there is no alert on the route’s own page to indicate that readers should also consult the diversion information.

The subway, the main target of this article, has additional information sources for would-be riders, although all of these can be quite frustrating.

If you are at platform level, and your station has a working video screen (dead screens are becoming common), and you’re standing close enough to read it, and Transit Control considers a delay to be serious enough to put up a notice, then you have a fighting chance of discovering that something is amiss.  There may even be PA announcements, but they tend to occur only for very long-running delays.  (As I write this, there is no subway service east of Victoria Park, and info about this comes over the speaker systems regularly.  It also appears on the “Service Advisories” on the TTC website.)

If you are anywhere else, and you have cell/internet signal, you may get information from various sources:

• The TTC’s eAlert service (via email)
• The TTC’s Facebook page (via SMS)
• Twitter feeds, some from TTC sources, available via the TTCUpdates community page (not a TTC site)

I get both the eAlerts and the Facebook updates, and compiled a log of information from both sources.  My apologies to those who don’t like “busy” displays as there is a lot of info consolidated in one place.

The first few columns show the date, location (the affected part of the system) and the nature of the event.  Some of these are rather vague, although specific information may appear in followup alerts on in the “all clear”.

Next come two pairs of times.  The first two give the timestamp on the emails for the alert and the all clear for an event.  Where these are blank, there was no email.  I have used the email timestamp because it indicates when the message was actually sent by the TTC, and this is rarely identical to the “last update” time included in the body of the message.  The next two give comparable information for the Facebook page updates.  Generally speaking, these are a bit earlier than the corresponding email times.  If either the email or Facebook messages mention shuttle buses, “Yes” appears in that column.

One of the problems of emails and SMS texts familiar to anyone who uses a PDA is the lag time between a message being sent and its appearance on your PDA.  This is complicated by different strategies for retrieving messages used by various carriers and by different devices.  I have a Blackberry and that’s my frame of reference as it is for many other TTC riders.  I would be interested to hear from, for example, iPhone users to know if they see a different pattern.

The eAlerts are emails, and as such can be subject to many delays both in the originating system and at various points along the way.  (I am not going to give a tutorial about email here.)  The important point is that, in addition to the various places where delivery can be delayed enroute from the TTC to you, there is the “polling interval” of your own PDA.  In order to conserve transmission bandwidth and network load, your PDA (like the email client on a computer) checks for new mail from time to time.  This can introduce a delay up to almost the length of the polling interval before you actually receive the message even if it is already sitting in your inbox on your service provider’s system.

By contrast, SMS texts are pushed out to your PDA when they are available, and they don’t sit around waiting for your PDA to ask for them.  It is possible for these messages to get queued up at the sender’s end, but that is Facebook’s problem, not the TTC’s, and Facebook appears to have a fairly robust subsystem for shipping texts out quickly.

The remaining columns show the times when an email alert or all clear, and an SMS alert or all clear showed up on my Blackberry.  Not all messages show up here either because the Blackberry was turned off, or I had no signal (and therefore the times are meaningless), or my desktop email client picked up the incoming mail before the Blackberry did.

What is quite consistent is that the delay for email delivery is consistently longer than for SMS, and this is likely due to the nature of the media.  SMS is a “send now” message while email is “send when convenient”.  This has important implications for the TTC’s ability to update its riders with system information on a timely basis — there is a basic limit to the speed with which the message will reach people.  There are also technical implications of capacity requirements, not to mention the question of what Facebook will do if tens or hundreds of thousands of people all subscribe to the TTC’s page via SMS.

Leaving aside the technical stuff, something else is clear in the log.  There are incidents that appear in only one of the two logs.  Some of this is easy to understand because the TTC is not yet officially reporting delays to surface routes via eAlerts, while the Facebook page often has this info.  However, there was a period from December 9-11 (Wed-Fri) when there were no eAlerts.  Indeed, December 9 was an extremely bad day for the TTC with many delays through the morning peak period, including both signal problems and passenger illness.  None of these showed up in an eAlert.

Facebook activity more or less vanishes evenings, weekends, and periods when the proprietor may be on vacation (easy to check via his own Facebook posts).  This sort of inconsistency implies that both sources each depend on few or possibly one person, and if they’re not around or too busy, then the job doesn’t get done.

Also missing from this log, needless to say, are delays that nobody gets around to reporting one way or another.  It is very hard to believe that the system was so reliable over the Christmas break.

In the next article in this series, I will turn to the way that outages are managed including information for TTC staff and the handling of substitute bus services.