You’ve probably heard about personas from the days of Lync, Skype for Business or even other UC technologies. If you have not, and are venturing out into the Microsoft Teams tech-scape, then Personas mean experience profiles.
These experience profiles are like configuration buckets that you create in an effort to approach a UC deployment in a consistent manner, ensuring your users receive a predictable experience based on their usage requirements.
Microsoft Teams offers users many more configurable options than any of its heritage predecessors, expanding away from UC specific and into the collaboration and extensible spaces.
Whilst all these features and options are great from a product offering perspective, it can cause real headaches for deployment teams trying to deliver capability to an organization. If you add up all the configurable options and every permutation of each option, you’ll realise that your persona list will reach the thousand mark very quickly. Obviously, this is no good for deployment strategies.
Persona’s used to be specifically assigned per individual use case, but with the inclusion of collaboration, we are now tasked with applying a persona to a team, and indeed several teams by proxy of the user being a member or owner. There is no easy formula to follow, collaboration is a fluid genre and the boundaries must be well defined to maximise the benefit whilst protecting intellectual property and organizational security.
Focusing on the user specifically for now, when we inspect the Teams user object we realise that there are only a handful of policies available that can effect a user’s Teams experience. These are:
- Messaging Policy
- Meeting Policy
- Calling Policy
- Upgrade Policy
These four policies govern the users core functionality in Teams, yet between them you can muster over 20 different experiences from them.
Trying to manage 20 core personas from an operational perspective is a nightmare, and not something that is sustainable. You need to focus these down to a handful of persona options, 5 at most, 4 better, 3 optimal.
You have to take the lead and understand the objectives that have laid in the foundations of the project. It is in your organization’s, it’s users and your project to ensure you arrive at the end state quickly, within budget and with as little friction as possible.
This is where your creators license comes in. If you sit and discuss each and every option with your organization, you will be designing bespoke personas on a departmental and even individual level. Your project will never get off the ground and even if it does, trying to implement that over tens of thousands of users is going to lead to mistakes. Even worse, neither you or the user may notice the mistake. You’ll have policies that overlap with functionality and mixing those together can have adverse effects which increases trouble tickets and contribute to negative feedback from users. It will be carnage at biblical scale.
It is important to sit down with departmental heads to gain an understanding of what they use, why they use it and what they need to make their jobs more efficient. Collect that information across multiple departments and use that collective data to figure out your persona requirements.
For instance, you may find that 7 out of 10 departments require screen sharing capability within meetings or peer-to-peer. If the percentage is over 70% then that requirement should become standard and offered out of the box in your personas. Configuring a baseline aimed at the majority not the few is an about turn in the normal deployment methodology I know, but we live in modern times and old ways just aren’t optimal these days.
Certain policy options such as allow external users to request control, or anonymous users can start a meeting are global business decisions that transcend every policy created. Therefore, you do not need a policy that allows or denies these with every permutation. Simply pick the setting that complies with the organization requirements and bake it into your base policies.
You may find that there are valid cases for more restrictive use based on your findings. For example, perhaps only 4 in 10 departments require the use of Video. So there would be a cases to have both a video on and video off meeting policy.
Your standard offering meeting policy would therefore be; allow meetings, allow screen share, disable video. Furthermore, you now only have 2 meeting policies to choose from in your personas instead of 3. Not much you say? But wait, what about other policies?
Another tip, when looking at departmental persona assignment, if more than 50% of the department falls into a persona of most privilege, then you should plan that the other 50% also get the same persona, even if your data shows that they can function on a more restrictive persona. Why? Its down to peer jealousy. Why has Jane got Video and I haven’t? Believe it or not, on the last Teams roll out I did, this type of feedback was the most common and caused the project to spend too much time reworking people so that they can feel equally treated. At the end of the day, you know that they are probably not going to use their additional feature that much, they may dabble, but most people revert to type after a few days. If they do, and they become a prolific user of the additional features, then you’ve transformed that user, and that is a massive win for the project and grade 1 justification for your existence!
It is a fair assumption that no one in Teams is going to want their Chat policy to be turned off, so therefore really this the decision here is whether you want to allow Giphy/Meme support or not. My personal opinion is we should allow them with moderation set to strict to avoid insensitive posts being sent. I don’t find Giphy’s offensive, or not for the workplace. Properly used can add sentiment to a conversation that could otherwise be confused between parties (avoid the i was only joking, I didn’t mean to offend comments). We had the same arguments when emoji’s came into UC chat, ohh they will be abused said the scaremongers, but now they are old school and accepted as an integral part of UC. Giphy’s are just emoji’s version 2019!
Now I still have two personas to choose from after making this decision. On with the next.
Now we are going to discuss the calling policy. This controls whether a user is allowed to make a P2P or Enterprise Voice Call. I’ve had many discussions about this policy with respect to whether we should block P2P audio or not as a persona offer. My personal view on this is to allow P2P out of the box. The excuses commonly used to disable it is the lack of peripheral distribution or project budget to cover headsets. However, although valid, we simply cannot think that blocking P2P audio is a solution to hardware distribution woes. Why? Every Teams user has the capability to join a Teams meeting, even if their meeting policy is AllOff. If they have to join their managers or execs meeting, they need a headset. Therefore the policy to prevent P2P is flawed and ineffective, although may help to reduce the impact it doesn’t warrant the block.
So now I have decided there really is going to be one calling policy offered to everyone, so my persona count is still 2.
The last policy we are interested in is the upgrade policy and this determines the interop / coexistence mode applied to the user inheriting the persona. The likelihood here is that you’re going to have 3 upgrade modes, not including the tenant default. If you’re coming from Skype for Business, then probably your tenant mode will end up being sfbonly, at least until Teams is mainstream on your tenant as it preserves current state without causing untested havoc. The 3 that you’re going to have is SfBwithCollab, SfBWithMeetingsAndCollab and UpgradetoTeams.
By definition of one of these modes, SfBwithCollab, we now realise that we need another meeting policy in Teams to turn all meeting options off for these users and a calling policy that turns off P2P. Now we have 3 meeting policies, 1 chat policy and 2 calling policies. Now I can build my persona offers to users
Collab Only – Chat Policy: Global; CallingPolicy: DisallowCalling; MeetingPolicy: AllOff; TeamUpgradePolicy:sfbwithcollab
Chat Policy: Global; CallingPolicy: DisallowCalling; MeetingPolicy: Global; TeamUpgradePolicy:SfBWithCollabAndMeetings
Chat Policy: Global; CallingPolicy: DisallowCalling; MeetingPolicy: AllOn; TeamUpgradePolicy: SfBWithCollabAndMeetings
Chat Policy: Global; CallingPolicy: Global; MeetingPolicy: Global; TeamUpgradePolicy: UpgradeToTeams
Chat Policy: Global; CallingPolicy: Global; MeetingPolicy: AllOn; TeamUpgradePolicy: UpgradeToTeams
I now have my 5 Teams personas I can assign users to. Its a manageable number so I can accurately predict each user’s experience and these can easily be baked into operational and MACD support. The project and organization is clear on what is going to be deployed and other Teams such as Change Management can accurately deliver training and first day support with confidence.
I cannot stress enough to instill the processes and implementation strategy engineered by the project into your BAU team and processes. If you don’t then very quickly your nice standardised deployment will quickly descend into configuration chaos that will be another huge project to clear up, and all this effort you’ve put in gone to waste.
As a result, your feedback rating rises, users are satisfied and it’s easier to adopt within the business.
Obviously, you need to perform your own analysis and persona design that reflects your organization’s needs, as with anything, your mileage may vary, but try to keep things concise and designed for the many out of the box rather than the few and you won’t go far wrong. Hope this helps.