During my time at Frame.io, I managed both the enterprise and growth product teams. As we moved into bigger and bigger organizations, and we discovered all of the requirements that came with enterprise and IT management, I got to see how deep the enterprise rabbit hole goes. 🕳

Now, as a co-founder and CEO, I find myself even deeper into that rabbit hole — from guiding enterprise product leaders as they weigh the pros and cons of buying (versus building) a notifications platform to supporting my team internally to ensure that we meet the mark for enterprise offerings.

When done right, an enterprise-ready product is a win-win. It makes account and usage management easier for your enterprise admins, which in turn helps you grow with your enterprise customers and deliver more value to their organizations.

“Enterprise-ready” is an endless topic. In this post, we'll talk specifically about why it's important for product teams to embrace enterprise-ready work. This means looking at enterprise-ready not as a chore or a checkbox, but as one of the highest-leverage things you can do for your business.

Why enterprise-ready work is high leverage work

Whether you practice product-led growth, top-down sales, or some mix of both (hint: it's almost always this last one,) at some point you'll need to become enterprise-ready.

What does it mean to be enterprise-ready? As you start to talk to bigger organizations, you'll gather more requirements that extend out of the realm of the core product requests you've heard from the rest of your customer base to date. These new "enterprise-ready" requirements tend to fit into two major buckets.

  • Security. What you need to play ball with these new enterprise customers. There are a few standard requirements you'll see all enterprise customers ask of all SaaS vendors, such as SSO, two-factor authentication, and SOC2 compliance.
  • User management. How you help customers manage your applications alongside the countless other vendors they use every day. A good signal that you need to be enterprise-ready is that you start to spend more time in your sales process talking to IT department managers and CIOs. The question shifts from "should we use this across our organization?" to "how will we use and manage this across our organization?"

For many product teams enterprise-ready work can feel like a chore. It's not core to the product. The requirements sound different for each enterprise buyer. You have to sift through ancient documentation just to understand what it is you need to do.

While this was true in the past, now there are tools that abstract away the pesky parts of supporting enterprise-ready features. It's never been easier to get to enterprise-ready, and, for SaaS and usage-based products, the benefits have never been clearer.

Next, we'll walk through a few enterprise-ready features and the notifications that power them.

The notifications that power enterprise two-factor authentication

The why and how of two-factor authentication (2FA) itself is a topic that deserves an article on its own, and for that we recommend this post by the good people at Twilio.

TL;DR: 2FA is a way of verifying authentication into your app. If you're in B2B software, most of your customers should use it and your enterprise customers will require it, and if you're a B2C app that stores private user data, you should support 2FA, too.

Notifications play three important roles in 2FA. First, depending on which 2FA methods you want to provide your users, you may need to send them notifications to get into your app. Second, if your customers want to enforce 2FA across your app, you'll need a notification to notify members of a given customer's account that they need to enable 2FA. Finally, in the event that users get locked out of an MFA-enforced account, you'll want to provide them with a way to notify admins so they can get back into your product.

We'll cover all three of those use cases here.

Notifications and 2FA-based login

When you do decide to support 2FA in your login flow, you'll have a few methods to choose from to get verification codes to your users.

  • Via authenticator app. Let your users receive their verification codes via an authenticator app such as Google Authenticator or 1Password. These are more secure than verification codes delivered via SMS (which can be spoofed) and you'll often see them as the preferred default of SaaS vendors that support 2FA.
  • Via SMS text message. Send a verification code to your user via SMS text message. Depending on the user base of your product, you may be able to get away with just offering authenticator app verification, though in our past experience we've found it's good to offer SMS as an option for less technical users.
  • Via push-based auth. You've probably seen this if you've logged into Gmail or iCloud recently. You get a push notification asking you to verify that a given device is allowed to access your account. More secure than a text message and, in some cases, lower friction than an authenticator app. Push-based authentication requires that you (a) have a mobile app with which to send these push notifications to your users or (b) provide them with a 3rd-party authenticator app that can send them on your behalf.
💡

UX design tip. While we're on the topic of push-based auth, if you support "Sign in with Google" or "Sign in with Apple" in your login flow, keep in mind they'll use push-based auth to verify users when necessary. This means pulling users out of your app an into Gmail or iOS to authenticate — it's not the end of the world, but you want to think about how your app's design handles that experience.

Depending on which of the verification options above you decide to give your customers, you may be sending no notifications (i.e. you only offer authenticator app verification) or some combination of text or push notifications.

If you decide to use a vendor such as Authy for your SMS or push-based verification codes, they'll handle these notifications on your behalf.

Notifications and 2FA enforcement

Another thing to think about if you're an enterprise software vendor offering 2FA to your customers: you'll need to support admin-managed 2FA enforcement on a per-tenant basis.

If you're trying to figure out how to enable your admins to enforce 2FA across their accounts, Slack's implementation is a good model to reference. As a part of any 2FA enforcement experience, you'll want to send an email to users on the account alerting them of the change and that they'll need to set up 2FA the next time they log in.

For this email, it's best to give the user a sense of when their current session will end and when they'll have to enable 2FA, as well as a call-to-action button to take them straight to the 2FA setup flow if they'd like. Here's an example made in Knock.

2fa-enforcement-email.png

Notifications and locked out users

Once your customers start to enforce 2FA on their accounts, there will inevitably be cases where their own team members get locked out of your product. (This has never happened to me. Not even once. Promise.) The best practice here is to give your users a way to contact their admin, who then has the ability to suspend 2FA on the user's account for a 24-hour window.

An email notification works fine for this though you may want to consider push, in-app notifications, or Slack/Teams to make sure you're getting these requests in front of admins in a timely manner.

A few Knock-made examples to get an idea of what these notifications can look like.

lock-out-notifications.png

The notifications that power bulk user imports and auto-provisioning users

Another thing that happens as you start to move into the enterprise: you have to figure out how to help your enterprise customers get all of their employees into your product.

This is a great problem to have, but it comes with a few new wrinkles to iron out. Your old invite flow won't cut it when you move from "how to get 20 employees into one account" to "how to get thousands of employees into one (or many) accounts".

There are two ways to do this: bulk user uploads and auto-provisioning users via directory sync.

Bulk user uploads

You have an invite flow in your product today. It might even include comma-separate value support for inviting multiple users at once. Even then, your customer success managers (CSMs) will eventually come to you, asking to run a script to import users in bulk for a new enterprise customer.

The standard invite flow usually breaks down when one or more of the following happens:

  • You have multiple accounts/workspaces within an enterprise customer, and they need to determine which users go where.
  • You have multiple roles/access-levels within your application, and you need to set user roles in bulk upon import.
  • You use groups as part of your access control model, and you need to assign users to groups in bulk.

When this occurs, you can either (a) have your CSMs do all of this for your customers manually (note: please don't do this to your CSMs) or (b) add a bulk invite users flow to your product with a CSV importer. Even if your CSMs end up managing this on behalf of your customers, it's a much better (read: less error prone) experience than having them do it in the product manually.

For CSV importers, we recommend our friends over at Flatfile. Try the demo once and you'll see why it's a no brainer when it comes to helping more users get into your product.

Once you do start bulk importing users into your product, you'll send them the same invite notification that we talked about in our post on product-led growth. The one thing to keep in mind here: when you're inviting users in bulk to many entities within your product, you might consider batching invites for each recipient. The end result for new users within the enterprise: instead of getting four emails from a product they haven't heard about, each of which invites them to a resource, they get one email, summarizing the four resources they now have access to. It's a cleaner introduction to your product.

Auto-provisioning users with directory sync

Bulk uploading users works, but it leaves your enterprise admins to manage access and remove users when they leave their organizations. The promised land of enterprise user management is auto-provisioning users via directory sync.

This is, again, a topic that deserves its own dedicated blog post, and for that we'll point you to this great post on directory sync from the team at WorkOS.

At a high-level, enterprise customers have IT departments that want to manage users from their identity provider (IdP), such as Okta and Active Directory, not from within your app. To do this, you need to support groups in your product and allow your admins to map them to the groups from their IdP. Once a group is mapped, all users in that group are "auto-provisioned" with access to your app. The admin is happy because they don't have to leave their identity provider to add or remove users from your product. You are happy because now your admin has a way to easily provision access to your product at scale.

When you enable auto-provisioning, it's a nice touch to notify admins on a regular cadence about the users that are added or removed from your app via auto-provisioning.

Powering enterprise-ready workflows with Knock

If you're hitting the next phase of your growth curve and want to support enterprise-ready workflows, you should try Knock.

As always, we've added a few new notification templates to our recipes page to support the notifications discussed above, so you can get up and running with 2FA enforcement notifications and auto-provisioning notifications in minutes.

Have questions or thoughts about what it means to be enterprise-ready? Anything we missed? Let us know at [email protected].

Additional resources

Here's a summary of a few of the vendors/resources mentioned above as well as a few others that are helping companies get to enterprise-ready faster than ever before.