What are best network configurations for Mt. Hood Meadows Ski Resort?

[Mark Messinger]

What recommendations do network administrators have for network types that will meet the needs of Mt. Hood Meadows Ski Resort?

The resort would like to manage employee commute trips, which suggests the creation of an Employer/Organization network type. Mt. Hood Meadows has committed to provide resources to administer such a network, on Drive Less Connect. And, as you can see at this page, Mt. Hood Meadows is serious about providing transportation options. It would be relatively easy for resort employees to become associated with an Employer/Organization network, perhaps using a passcode or one of the other means available for this network type.

The resort would also like to have some functionality to assist with managing the trips taken by guests of the resort. Many of these guests make relatively few, intermittent trips to the resort. That suggests that, at a minimum, the Hood River regional network ought to set up a network Location, for Mt. Hood Meadows. That way, users can easily find a common location without having to join a formal Mt. Hood Meadows network.

But some guests will make regular trips to the resort. It would be desirable to associate those guests to a formal Mt. Hood Meadows network, within Drive Less Connect.

Mt. Hood Meadows might someday want to create incentives to encourage guests to share a ride to the resort.

What's the best way to associate resort guests - particularly those who make frequent trips - to a Mt. Hood Meadows' network, on Drive Less Connect?

Mt. Hood Meadows will sometimes want to send communications to both employees and guests. Most of the time, however, they will want to send communications to either employees or guests, and not both.

Here's one alternative:

In the configuration above, there's one single organization network with two division networks, as children. If a passcode were to be used, it would presumably be a common passcode to associate with the top-level Employer/Organization network. That passcode could be provided to employees through a variety of means. The same passcode would be provided to guests on the Mt. Hood Meadows' "Transportation Options" web page.

When users register with the top-level Employer/Organization network, they will choose between the Employee and Guest division, using a drop-down menu in Drive Less Connect.

If communications and incentives can be separated by Division, it seems as though this first alternative might be pretty simple.

Here's another alternative:

In the second alternative, there are two separate, un-connected Organization/Employer networks. Each one has its own passcode. Only employees are given the passcode for the employee network. The passcode for the guest network is provided on the Mt. Hood Meadows' "Transportation Options" web page.

Communications and incentives would certainly be separate, in this second alternative. But reporting would be a little more difficult. In order to report on data for all trips to Mt. Hood Meadows, administrators would have to add reports from these two networks together.

Here's a third alternative:

The two child networks are Program Program type. Why? Because Program type networks can be set to associate via wirewrap. Given that Mt. Hood Meadows already has a "Transportation Options" web page, might it be easiest to use that to associate guests to the correct Mt. Hood Meadows' child network?

Employees would be associated to their own program network using a passcode.

Thanks for any comments about advantages and disadvantages of these alternatives - or ideas about better alternatives.

[Scott Turnoy]

I will be setting up the organizational network for Meadows this week, but would appreciate any suggestions related to this thread, especially regarding the pros and cons of each structure for the guest network.

If an ETC managing the Mt. Hood Meadows staff network is also automatically able to see the users associated with the location network, would the ETC be able to run incentive programs to just those users?

Thanks,

Scott

[Pamela Blackhorse]

This scinario almost reminds me of the university network set up...also, is Mt Hood Meadows going to be offering a vanpool or bus option and do they have other locations they might would need to incorporate?

 

[Mark Messinger]

Okay. Here's what we're going to recommend. Does this network arrangement and its rationale make sense?

A top-level Organization/Employer Network with two Program networks (one for employees and the other for guests). Plus, a network location - at the State network level - so all users within Oregon's networks can see the Mt. Hood Meadows location.

This allows Mt. Hood Meadows to create a passcode for use by guests to associate themselves with their Program network. Mt. Hood Meadows can then choose to use a different passcode and any of the other means available for associating employees to their Program network.

Users can be associated to Program networks using Email domain, Import accounts, Administrator approval, Passcode, and/or Proxy registration. Mt. Hood Meadows could choose to select more than one way of associating their employees to the Program network.

Hey, it's even possible that Mt. Hood Meadows may have some source of "frequent guest" email addresses, which could be used as direct email to encourage guests to enroll in their Program network. The passcode and instructions on how to use it, along with links to Drive Less Connect, can be placed on the Mt. Hood Meadows' Transportation Options web page.

But, what happens if Mt. Hood Meadows wants to offer a formal Emergency Ride Home program, administered through Drive Less Connect? ERH cannot be run through the Program network type. But it could be run through the top-level Organization/Employer network. So, ERH would need to be offered to both employees and guests, if it's offered at all. At least, I think that's true.

The mix of formal networks and a statewide network location are meant to accommodate the needs of three groups of commuters: employees, frequent guests, and those guests who look to share the ride to Mt. Hood Meadows for intermittent trips.

[Mark Messinger]

Okay, I've had another thought. Use the "placeholder" TMA network, as the top-level network. This allows Mt. Hood Meadows to employ Employer/Organization type networks, at the sub-network (child) level. Like this:

Yes, I think this is it. The placeholder is invisible to users. Since users associated to any of the child networks are automatically associated to the top-level placeholder, it's possible to report and to communicate from the top-level placeholder network. And, Mt. Hood Meadows has separate, fully-functional networks for each of these separate populations of commuters (employees and resort guests).

In addition to the creation of a network location, at the level of the Oregon state network, I think it likely that Mt. Hood Meadows might, from time to time, want to create Events. Those events would probably be at the level of the State network, too, since resort guests might come to events from any location around Oregon.

[Tracy Ellis]

Mark,

I've given this some thought since I will likely be setting up a network for Three Rivers Casino which is very similar in nature.  Employees and Guests. 

I plan on setting up two separate organization networks.  One for Employees, the other for Guests.

I'm not sure I see the value of setting up a TMA parent, unless you are planning on the Organization running simultaneous (but different) benefit programs for their customers/guests.  Can you tell me more?

 

I would be against having two many layers of networks for people to join; i.e. Employer - Program.  I think it's too difficult and not intuitive.

 

Also, is Mt Hood Meadows planning on being an active administrator? Or will Scott be providing the admin support?

[Mark Messinger]

I think you're on the right track (about creating separate Organization type networks: one for the employees and the other for the guests).

Really, the most significant purchase of the placeholder TMA is to give ETCs rights to administer the TMA, which gets them in to the child Organization networks. So, ETC logs on, will have the option to select radio button for the TMA, and voila! can get to all children that way.

iCarpool has confirmed that users do not become associated to the placeholder TMA, by virtue of their association to the child networks. So there's really no advantage to having the placeholder TMA, except to manage the ETC administrative rights.

Which answers your next question. Mt. Hood Meadows is having a couple of their people get trained up in the Drive Less Connect system, to act as ETCs and manage both the employee and guest networks for Mt. Hood Meadows.

[Tracy Ellis]

Who will be setting up the locations at a State level?

[Mark Messinger]

Locations at the state network level. . . Yes, well I need to check on that, with RideshareOnline Support. Since I posted the diagram earlier in this thread, I have found what I think is evidence indicating the highest level network that can create Locations is the Employer/Organization type.

Interesting that it may be that the system won't allow state-level locations, but will permit state-level events. I believe it's Moses Drake who's been identified as the poor soul who must handle requests for state-level event set-up, in the system.

So, let me get back to you (and post a reply to this thread) on the question of state-level locations.

[Community Connection NE Oregon]

Thank you all for the discussion.  I am meeting with Anthony Lakes Ski Resort on Tuesday. 

Cherie Kausler

[Mark Messinger]

RideshareOnline Support has now confirmed to me that Locations can be created by only three kinds of networks: Organization/Employer, University, and School networks.

I have asked Support to reply with any suggestions they may have for some kind of similar functionality. There are certain kinds of locations - tourist destinations such as ski resorts - which could benefit from being able to be found using the destination's name, not a street address.

It's interesting for me to find, if I enter "Mt. Hood Meadows Ski" into the destination field (in Drive Less Connect), Google Maps correctly resolves the location. However, I see where Cherie is speaking with Anthony Lakes Ski Area soon. When I enter "Anthony Lakes Ski" into the destination field, Google Maps cannot find the location.

I will file an enhancement request with Rideshare Online Support. There ought to be a way for administrators of networks higher than Employer/Organization to create locations that can be used to identify trip destinations. I believe there is a way to request that Google add a common name to a location, on Google Maps. But I'd like to request a solution for this, within the iCarpool system.