TMA Network Configuration implications

[Dan Kaempff]

We have five TMAs in the Portland region and we're beginning the process of establishing their networks. The best solution for doing this has been determined to be via creating a GIS boundary for each TMA. The other options, either the passcode or administrator approval processes, would be too cumbersome or error-prone to be satisfactory choices.

 

But, what the GIS option creates that isn't present with the other choices (as far as I can tell) is the question of who exactly does the network include?

 

When you upload your GIS file and create the network, you also have to define which users will be included:

• Employees
• Residents
• Both employees and residents

The implications of this decision are significant, and create both challenges and opportunities for TMAs and similar organizations. Traditionally, TMAs have been business-oriented organizations, focusing on commute trip reduction. But in more recent years, they have been taking a more holistic look at the areas they work in and finding ways to reach out to residents as well as businesses.

 

Before we make decisions on how best to configure the TMA networks, it would be great to have a teleconference on the subject. I'm thinking that we need to make sure we understand the implications of various choices, and capture people's thoughts and questions prior to configuration. I see this as being a potentially significant tool to help stimulate the creation of all sorts of "centers", such as neighborhood groups, or other geographic areas that can coalese around transportation issues. Any thoughts?

[Stan Suchan]

The City of Bellevue and TransManage, the Bellevue-centered TMA, recently went through the process of determining how they wanted to configure themselves in the system. Staff from WSDOT and King County Metro participated in the process to provide support and to learn more about the system. Here are some things I learned in the process:

• When you configure a network using GIS boundaries, anyone who lives or works within that boundary are automatically part of your network. This approach taps into the collaborative power of the iCarpool platform. When the boundaries for TransManage were entered in the system, they automatically and instantly gained thousands of network members. As they recruit new members, local organizations and users mutually benefit.For example, if King County recruits an employer in Bellevue to use the system, all of their workers who sign up in the system are automatically enrolled in the King County, Bellevue/TransManage and State of Washington networks. If they work in a large building that has an address-based network - for example, a skyscraper or campus that's home to multiple employers - they'll also be automatically be included in that worksite network. That means they'll see messages, be eligible for incentives and can choose to ridematch within all of these networks: state, county, city, TMA, worksite/building and employer. One-stop-shopping for users. Shared database for TDM practitioners. Pretty darn cool.    
• GIS-based networks act like cities, counties and states. One of the implications is that users can't opt to leave the network. Their only escape route is to leave the entire system. As a result, network administrators who use GIS boundaries - which include cities, counties, states and GIS-based networks - must take care not to alienate members. We haven't seen any examples of this type of behavior and we're all interested in customer service and marketing. But it's good to be aware that behavior like too many messages or controversial messages could have an affect that reaches beyond your network.   
• City boundaries in the iCarpool system are based upon zip code designations. This means that unincorporated areas can be included. For example, the city of Bellevue in the iCarpool system includes some unincorporated areas. This makes a lot of sense from a marketing perspective because people in these areas are geographically contiguous with the adjacent city. This means that they are good candidates for ridematching, drive in the same travel shed, affect air and water quality within the city boundary and have a similar cultural perspective. This can be an issues, however, for programs that require a strict city boundary due to policy, regulation or requirement. For example, a city-funded incentive program that must restrict eligibility to city taxpayers.    
• If a TMA wants to duplicate an existing geographic boundary like a city or county I believe that they can do so without using a GIS-based boundary. 
• TMAs might need multiple GIS-based boundaries. These can use existing boundaries in the system (entire city), create GIS boundaries that are mutually exclusive (downtown core and a tech center in the south end of the city) or nested (entire city and downtown core or greater downtown and the downtown core). If a TMA chooses mutually exclusive boundaries they will need to post messages and offer incentives to both when they want to reach all of their customers.

We'd love to see more TMAs using the system and to continue to learn from their experience. I'd be happy to participate in a conference call to support your effort. In addition to iCarpool personnel and me, others who might offer insights on this topic include Cathy Blumenthal, Anne Bruskland, Tom Devlin and Clare Cronin from King County Metro; Caryn Walline from TransManage; Kate Johnson from Bellevue; Christopher Aiken from WSDOT.  

 

   

[Dan Kaempff]

That's great information, Stan. We're definitely interested in what our colleagues in WA have learned to date. Just to expand on my original post a bit...

 

We selected the GIS option for defining TMA boundaries for several reasons.

• None of our TMAs have boundaries that line up nicely with other defined boundaries (city, county, zip code, etc.) They may cover multiple zip codes or cities, or just be wholly encompassed within one zip code.
• We had heard that past experiences with using the passcode option had its drawbacks when working with a large and diverse number of employers and businesses. Codes were lost, forgotten, mis-entered, etc. which led to administrative problems and headaches.
• The administrative approval process was rejected for similar reasons related to the amount of time potentially needed to approve registrants.

Since the GIS option automatically puts registrants into a TMA network, it was seen as the best way to define the network. But you've touched on the main points of concern - running the risk of alienating people via over-messaging, or getting messaging from organizations they may not even be aware of.

[Stan Suchan]

I am a fan of using geographic boundaries for networks for the reasons you list above. As for the risks, I think they're minimal and manageable. We all share the common interest of keeping network members happy and offering useful information and services. We're also good collaborators and can work through differences should they occur.

[Amol B]

Dan - thanks for posting on Smart Transportation. And thanks to Stan for covering the topic with so much detail.

I wanted to add a small note to this discussion - there is one more option to consider given the scenarios above - use of domain based association. If each TMA has their own domain - then their domains can be configured to make network associations. When a network is configured with domain based association - the user is associated with the network when the user signs up or logs in using the network's designated domain. So association is much easier than passcode or explicit association.

Of course - the domain based association is not geographic - so if a user from Seattle used a Portland TMA domain - the system would associate the user to the Portland TMA domain. So there are some more details to consider - although that would be the rare case. There is also no way to associate existing users with the network in case of domain based association (so if you had a large volume of users who had already signed up using a different domain - you at least need a way to message those users to start using the new domain, else the domain association would not occur).

That said, the majority cases should work out.