First, we are new to Asana and are loving its features and potential.
I have gone through the forum and seen similar posts, but nothing really directly addresses our feedback to the development team for what we would hope to see regarding user licensing.
Currently, under the Asana user model, our understanding is that any user within the same email domain that is invited to the organization in Asana consumes a full licensed seat.
We are a .EDU, and I imagine that this becomes challenging for other larger organizations trying to accomplish project/task management where stakeholders vary often from project to project. We are also IT which means that we do a large amount of projects/tasks both internally with the entire team (currently all team members licensed), but also a ton of projects to support multiple areas on campus (building projects, facilities, business office, faculty, student services, athletics, and on and on). Simply put, the ROI of adding all users of an organization begins to diminish rapidly as those numbers begin to scale.
We have already invited outside stakeholders (vendors, etc) to some of our projects and the functionality is wonderful, although perhaps a bit too many permissions for a guest.
Currently, we are looking to resolve this by adding more seats to allow for more users, however; this may become a manual management issue when having to add/remove users all of the time in mind of seat count.
Some ways that we have seen this done in other systems:
Allow all domain email users to be able to default as a guest in the organization and not a licensed user and then assign licenses with permissions to those that are intended to have full access by those with Admin access. (role based access, not auto-based role definition).
This would solve issues with users going over license seats unintentionally.
This may help clear up some confusion on licensing for guest users
This would allow larger organizations (like .edu’s) to use Asana for more project management/collaboration through interdepartmental teams/stakeholders. I would also imagine this would excite those users in other departments to want a full license of Asana because it’s awesome(win/win).
This would probably entail decreasing some user permissions for guests, but the ability to comment, view, and be notified would be the base permissions to go from. I mention this because we also identify that Asana cannot give away too much access to everyone. We do believe strongly in the difference of a guest account vs a full license. This is one of the reasons we licensed an entire department, but the current way seat counts are used is limiting when you consider the larger organization and the desire to include them in projects or tasks.
Also, being a .edu means that we leverage sso, so having to use external domains outside of sso (for enterprise users), does not make sense from a user management perspective. It also seems wrong to say to an internal stakeholder that we can add you to a project but we can not use your organizational email to do so unless your department pays a full license for this 2 month project.
Which also leads me to the fact that because we are very annual on our budgets, constant scaling of licenses becomes more difficult for us as well.
We mentioned this to our trainer as well, but wanted to provide this feedback in the forums as well to share our idea with you. We would be more than happy to discuss this idea further with the development team if they have any questions about this feedback as well.
Also … Asana Rocks! We already know in a short amount of time it has already proven its value to our team, we just hope we can extend that functionality to the rest of our campus without pricing ourselves out of being able to use it. Fundamentally, it just seems that if Asana already allows the unlimited guest access to those outside of the organization, that they would be able to somehow make that same access available to those “guests” that are actually within the same email organization (especially under enterprise licensing and using SSO).