Why we chose Teams for BeZoned

About BeZoned

Before we start, allow me a short detour. I think I owe you a short description of what BeZoned actually is. Without it, the reasoning would likely not make sense to you. If you already know BeZoned (glad to meet you 👋), then you can skip to the next section.

So let's start. BeZoned answers a question many remote and distributed teams face: how do you stay connected, collaborate better, build a sense of belonging, and know what is happening around your colleagues?

Those things happen naturally when everyone shares an office. For remote work, it's bit different story.

So we decided to build an online office that tries to make teams feel more present, connected, and close to one another.

Intro

Early on, when BeZoned was still an idea, we explored several directions.

Should we build a standalone product from the ground up? How about we integrate an existing communication tool? What about some middle ground?

Existing products in this space had already chosen to build the entire experience. But that approach asks users to go all in: either the whole team adopts the new solution, or communication becomes fragmented across yet another channel.

We chose a different path. From day one, BeZoned should be tightly integrated with an existing communication tool.

Why Teams?

Before deciding where BeZoned should live, we wanted to understand where the problem was most likely to exist.

We researched the communication stacks companies use. By scraping DNS records and other signals and looked for companies that primarily use Microsoft, Google, or alternatives such as Slack. Then we broadly grouped them by size.

Target audience

In the beginning, we assumed BeZoned would become more valuable as organisations grew larger and more distributed.

“Distributed” does not necessarily mean fully remote. They can be distributed across three floors of the same building, or simply because half the company works from home on Fridays.

What we found was that Microsoft Teams adoption tends to increase with company size. Surprisingly (at least to me), we also found plenty of smaller startups and teams using it. We also saw strong signals of remote and distributed work across companies of all sizes.

Meeting people where they already work

We all know it - getting people to use a new tool is often harder than building it.

A standalone BeZoned app would ask everyone to remember it exists. And open it. And then form habit of doing so.

Teams already has that habit.

So, instead of asking users to come to BeZoned, we brought BeZoned to them.

Once installed, BeZoned sits alongside the tools people already use in Teams, Outlook, and Microsoft 365. And mobile too. It becomes part of the existing workplace instead of another app competing for attention.

For larger organisations, adoption can happen centrally. Admins can make BeZoned available to selected users or groups and pin it directly in Teams. Colleagues don't have to discover, install or bookmark it themselves.

An existing ecosystem

Teams does not stand alone. It is part of the wider Microsoft 365 ecosystem.

Chat, calls, and meetings already exist. Calendars are already connected. Documents already have a home in OneDrive and SharePoint. Users already have profiles, belong to organisations, teams and work within established roles, permissions and policies.

That means BeZoned does not need to recreate any of it.

We do not need to build video calls, file storage or a document editor. We do not need another employee directory or a separate permission system. When someone wants to open a document, join a meeting or contact a colleague, we hand that action back to the Microsoft tools they already use.

The same is true for administration. Accounts, access policies, devices, and security are already managed in the Microsoft environment.

We can focus on what's important: creating the best online office experience.

Marketplace and distribution

Building software is getting cheaper. Distribution is not. Sadly.

Getting a product in front of prospective customers and giving them a simple way to evaluate and buy it stays difficult.

Microsoft offers a marketplace that already hosts tens of thousands of apps. Customers know how it works, and purchasing happens within a familiar environment. The less friction, the better.

And the best thing? Fees. Yes, I said it! Where others take up to 30% (looking at you 🍎), Microsoft takes just 3%. In return, we get multi-currency support, refunds, recurring payments, tax collection and a customer dashboard for managing and assigning licences.

Similar to other stores, apps also go through a validation process before release. It helped us to test BeZoned across more devices and environments than we could reasonably cover internally alone. And to practise a great deal of patience.

APIs & SDKs

Building inside an existing platform only works if you can meaningfully interact with it. Luckily for us, Microsoft provides the tools to do that.

Through Teams JavaScript SDK we can communicate with the Teams host. It handles navigation within the app and authentication.

Microsoft Graph is a common surface for Microsoft services. Instead of integrating separately with Teams, Outlook, OneDrive, SharePoint, and more, BeZoned can work through just one API.

Authentication is equally straightforward. Users do not need a separate BeZoned account; we sign them in using existing Microsoft identity.

It saved me from building a surprisingly large amount of boring infrastructure. Infrastructure which has a nasty habit of becoming very interesting the moment it breaks.

Enterprise governance and trust

Enterprise software is not only about functionality. It is also about who can do what, which data people can access and who controls that access.

When BeZoned needs access to Microsoft 365 data, it requests those permissions through Microsoft's consent model. The tenant administrator can review what BeZoned is asking for and grant consent on behalf of the organisation.

This model means we rarely need to store data ourselves. Instead, we request the data we need when we need it.

Why not Teams?

Building within the Microsoft ecosystem has helped us enormously. But it's not all sunshine and rainbows.

I've spent plenty of days trying to understand why something works the way it does. Or why it doesn't work even though it should.

However, that's a story for another time. So stay tuned ;)