Practical B2B SaaS Design

Prerequisites

Target Audience

Business professionals looking to develop and deploy multiple digital services

Article Terminology

Purpose of the Article

When developing multiple application services—particularly under the super app concept—the underlying technical foundation is nothing short of a B2B SaaS Platform (see terminology section above). While this may be an understatement, many system components operate behind the scenes, often being deferred until later stages and remaining difficult to visualize.

※ The rationale behind creating a foundational platform when deploying multiple web services is intentionally omitted from this discussion.

Reading through this entire article should deepen your understanding of B2B SaaS Platforms and help clarify the often-obscured challenges that lie ahead when developing multiple digital services.

First, we'll outline the key components of B2B SaaS, then examine how even considering "organizational structure" alone can significantly complicate service development. This approach aims to facilitate better understanding of what constraints must be imposed on each application layer above the platform, and how providing common functionalities can streamline the design and implementation process for each app.

Note

Actually, few people possess both the knowledge and experience to independently develop B2B SaaS. This is because B2B SaaS has only become actively developed over the past decade, and the ecosystem of various standards and services supporting B2B SaaS remains still in development. The "foundation" that consolidates multiple B2B SaaS offerings is even more advanced in this regard.

Key Points of B2B SaaS

When distilling the critical aspects of B2B SaaS, we can broadly summarize them into these three core elements:

1. Organizational Management

Within corporate environments, it is necessary to control access permissions by department or position, maintain operation logs, and enable centralized management of service usage status and access controls. (Connected Business Value Examples: Flexible service models, implementation of billing mechanisms, support for separating payment authorizers from service users)

2. External Integration

Since businesses using SaaS services typically need to integrate with existing systems or other SaaS platforms, architectural design must prioritize compatibility and extensibility to ensure smooth integration. (Connected Business Value Examples: Storing customer information in existing CRM systems, integrating with accounting systems to maintain customer billing and payment management as before)

3. Security

Given the extensive handling of business-related data, stringent security measures are essential. Initial architectural design decisions, such as maintaining loose coupling between corporate data, can significantly impact future security risks. (Connected Business Value Examples: Minimizing negative impacts on service reputation from data breaches or security incidents)

Based on these three key considerations, we recommend following this structured approach to thoroughly organize requirements and ensure comprehensive design coverage.

When examining B2B SaaS services through the organizational lens (*), we observe that most offerings provide the following core functionalities in common:

* In this context, "organization" is also referred to as "tenant."

• Organization administrators invite users (organization members)
• Organization administrators handle payment processing
• Organization administrators manage user permissions
• etc...

Note

The presence of these features does not automatically define something as a B2B SaaS solution. For example, if a consumer-facing application requires family account management functionality, it would naturally need to implement the above-listed features.

From a technical perspective, providing SaaS services requires managing data from all participating companies, which inherently necessitates designing multi-tenant* logic and data management capabilities. Furthermore, B2B SaaS solutions often extend their services to end consumers beyond direct business partners, making design considerations for B2C (B2B2C) scenarios from the outset capable of significantly reducing overall implementation costs.

* For fundamental design principles in multi-tenant system architecture, this article from AWS Blog provides valuable reference material.

Next, let's examine concretely how incorporating "organizational considerations" introduces complexity to software systems.

Key design perspectives when accounting for organizational structures

When attempting to specifically envision the UI design for "social networking services" versus "in-house corporate social networks," it becomes clear that simply adding the constraint of "only usable within specific corporate environments" significantly makes it harder to focus on the core SNS functionality (despite it being the most important aspect). This alone demonstrates intuitively how organizational considerations introduce complexity, but to better understand what specific considerations arise when accounting for organizations, let's examine some concrete examples.

Where should users select their organization?

Case A: Selecting organization before login

The following factors would need to be carefully considered.

• What measures should be in place if users forget their organizational name?
• Using selection-based organization identification risks exposing which organizations are using the service to third parties.
• Do different organizations require separate authentication credentials? If not, wouldn't it provide better UX to allow selection after login?

Case B: Selecting organization after login via switch function

How should the system determine which organization the user is currently associated with?

If identification is based on domain names (e.g., abc.example.net), changing organizational IDs would result in bookmarks becoming invalid. Additionally, assigning random IDs as part of domain names would significantly degrade URL readability.

Alternatively, if identification is based on URL paths (e.g., example.net/abc), changing organizational IDs would similarly invalidate bookmarks. Furthermore, different paths would lead to duplicate caching of shared static resources across organizations.

In such cases, would storing the selected organization ID in cookies or LocalStorage be appropriate? Would this approach cause issues when users want to switch organizations between browser tabs?

Should user-submitted messages be accessible to users outside their organization?

Case A: Messages are never visible to users outside their organization

If this is no longer the case within a year, should we prioritize implementing this feature despite additional development costs?

Case B: Allow guests from outside organizations to view messages by inviting them to the organization

When inviting users from other organizations as guests, is it acceptable to reuse their usernames?

Case C: Flexible visibility control for messages regardless of whether they involve internal or external organizations

When an organization's service contract expires, should messages sent to external users be automatically deleted?

What are the available methods for organization registration?

Case A: Add organizations to a waiting list, then have system administrators invite them later

• Should administrators receive notifications via email or Slack when organizations are added to the waiting list?
• How much development effort should be allocated to management functions for waiting lists that aren't visible to end users?

Case B: Enable self-registration for organization setup

• Measuring and reducing drop-off rates during the organization information input process could improve registration rates, but this isn't a core feature—should it be prioritized later?
• How can we prevent malicious third parties from registering under other organizations' names?

Case C: Have system administrators invite organizations

• It might be beneficial to implement organization invitation history management and an undo function for accidental invitations.
• Could we verify whether invitation emails have been opened?
• Since we want to customize invitation email content by country/region, could we create templated messages for reuse?

Case D: Have system administrators directly register organizations

• How can we securely provide organization administrators with their credentials (e.g., ID/password)?
• Would a workflow that generates random passwords, emails them to the organization administrator, and requires password reset on first login be sufficient?
• Since interacting with the organization administrator outside the system to gather registration information would negatively impact UX, could we instead complete registration with just the administrator's email address and organization name, allowing the administrator to complete the remaining details during their first login?

What are the available methods for user registration?

Case A: Self-registration for individual use plans (not affiliated with any organization)

• When the service is available without organizational affiliation, wouldn't each feature require additional implementation efforts and increase development costs?
• Does the current user duplicate check method adequately prevent vulnerabilities that could expose whether services are being used by third parties?

Case B: Users select an organization during self-registration, with organizational administrators approving their participation

If users can already know the organization name before signing up, this likely means someone from the organization has already informed them. In such cases, it might be better to allow existing organization members to send invitation emails or links to new members, which would provide a more intuitive user experience.

Case C: Existing organization members invite new members

• Should we allow invitations to users who are already members of another organization?
• Could we implement a system where anyone can invite others, but without proper permissions, invitations would require approval from authorized members?
• Should invitations be disabled if the participant limit for the billing plan has been reached? Or would it be better to allow invitations while prompting authorized members to update the billing plan?

Case D: Organization administrators directly register users

• A malicious organization administrator could potentially register users using someone else's email address. How should we verify user identity in such cases?
• If we implement email verification, what would be the appropriate timing for sending the confirmation email? If sent immediately after registration, the receiving user might find it suspicious to receive an email without prior notification.

Case E: A user who previously left the organization is later invited back

• Should we treat their past and future posts as coming from the same user, or as coming from different individuals?
• If we determine that users with the same email address are the same person, could this lead to situations where departed employees' email addresses are reused by the new hires?

While we could continue listing examples indefinitely, the questions presented here represent only the high-level requirements. As these requirements evolve into system design and implementation details, each individual challenge becomes increasingly complex. Despite having barely touched on the service's core domain requirements, simply incorporating organizational considerations already requires significant time and resources - a fact that's immediately apparent.

Regarding system design, it would also be helpful to provide examples, so I'll briefly address this next.

When implementing a feature to group users by department, what distinguishes this from an organization itself?

Both organizations and departments can be considered units for grouping people, so from a functional perspective, there wouldn't be much difference, making it natural to assume adding organizational concepts wouldn't be particularly challenging. Conversely, if the department concept proves equally complex as organizations, you might wonder why you didn't encounter such difficulties when developing similar systems in the past.

If organizations are merely "units for consolidating billing and payments," and many features span multiple organizations, then they differ little from departmental groups. In such cases, organizations could be viewed simply as groups capable of handling billing and payments. In fact, some services actually operate quite effectively with this simplified approach.

However, one critical consideration here is: In software developed before SaaS models, applications were typically installed on each company's (organization's) servers. When an organization ceases service usage, can you safely delete all their data? Given regulations like GDPR, failing to account for this could prevent adoption altogether. For example, if application audit logs are written to a single file spanning all organizations, would it be possible to implement requirements that restrict access to only specific organization's logs?

When considering these factors and viewing organizations as "data isolation units," their handling differs fundamentally from departmental groups.

Data isolation units refer to the following.

• Areas where data breaches would pose less risk if they occurred within these boundaries
• Features that are difficult to implement with data connections to external areas (resulting in fewer data breach incidents caused by implementation flaws)
• Data that maintains loose coupling with external data, enabling recovery operations at the unit level

Furthermore, when considering multi-service operations

While we've been conceptualizing this as a single service, the actual implementation of multiple services adds significant complexity.

Costs of developing common functionality separately

For example, in the case of registering organizations through self-registration as shown above:

1. Service A allows self-registration
2. Service B prohibits it, instead using an invitation-based system

This scenario is plausible. While Service B could certainly implement its own invitation system separately, if Service C and D also require invitation-based registration, repeatedly designing, implementing, and testing each service would be highly inefficient.

Risk of breaking existing service assumptions

In the above discussion, we raised the consideration point of "whether users already belonging to another organization should be allowed to be invited." For instance:

1. Service A prohibits users from joining multiple organizations
2. Later-developed Service B allows users to join multiple organizations

What would happen in this situation?

Here, the case of allowing multiple organization memberships #2 has emerged later. If trying to implement Service B's requirements, this would break Service A's underlying assumptions, leading to data inconsistencies and potentially causing unexpected system failures.

Risk of becoming unable to accommodate new needs

This is a common requirement in modern services, but if you aim to provide a mechanism for third-party developers to create applications that utilize your service's resources (e.g., Slack's Google Calendar app), you'll need to implement a secure system for these third-party applications to access organizational and user information safely.

In conclusion

While not covered here, B2B SaaS-specific features like enterprise billing systems and CDP integrations are also required across services. When a B2B SaaS Platform is designed with these considerations in mind, it enables service developers to focus on their core domains and allows effective utilization of consolidated customer data for marketing purposes. However, if implemented poorly, this could result in development and maintenance costs equivalent to several standalone services. In such cases, initially building each service completely independently and then performing refactoring and data migration when truly necessary is another viable option. Either approach has its advantages and disadvantages, and the final decision should be made in light of your business phase and future roadmap.