About Organization Management

• Organizations in SessionM

• Key product use cases

• Understanding organization management hierarchy

• Example organizational hierarchies

• Deploying Organization Management

• Working in an Organization Management environment

Organizations in SessionM

SessionM powers loyalty and personalized engagement for global enterprise brands. Global enterprises operate across multiple business units, brands, markets and geographies. In this complex environment, you need to be able to manage loyalty and engagement initiatives from a single, central location that provides visibility throughout the enterprise.

With the introduction of Organization Management, you can use a single instance of the SessionM platform to manage multiple loyalty and engagement programs spanning your business ecosystem. You can federate customer data, program configurations, and user access to the SessionM platform according to your organizational structure.

Key product benefits

• Self-service support for multi-org programs – For brands that run discrete loyalty and engagement programs across multiple organizations from a single instance of the SessionM Platform, Organization Management allows marketing teams to operate in “self-service” mode, since their access to customer profiles and program configurations is limited to their own organizations.

• Simpler implementations and faster time to market - The ability to host multiple programs and organizations from a single SessionM instance means simpler implementations with less integration work, thus faster time to market for new program roll outs.

• Enhanced data privacy – Marketers and Customer Service agents can only see the customer profile data for their organizations.

• Improved usability – The SessionM interface filters out content that is not relevant to the user's organization, removing clutter and simplifying configurations.

• Reduced human error – Marketers cannot accidentally deploy campaigns or other activations to an organization to which they do not belong, nor can they target customers from one organization for an activation meant for another organization.

Key product use cases

Programs

• Run independent programs for each org or cross-border programs across organizations.

• Deploy campaigns and offers to a single org or across organizations.

• Single customer profile, restricted to a single org or shared across organizations.

• Self-service modules with data access and management restricted based on org assignment and user permissions:

  • Customers, Campaigns, Audiences, Composer, Promo Codes, Insights

• Admin-only modules where org assignment done by admin:

  • Loyalty, Offers, Point Management, Reward Stores

Administration

• Create and administer roles to grant access at every level in the org hierarchy across self-service modules.

• Store location association to organizations.

• Reporting dashboard broken out and customized for each leaf-level organization.

Understanding organization management hierarchy

Orgs

An Organization Management loyalty program has multiple organizations (called orgs) that represent the different brands, geographic markets, or other entities in the enterprise. SessionM platform users are assigned to only those orgs to which they require access. This setup restricts them to their authorized organizations. They are not able to access customer data and program configurations of an org to which they do not have access.

Take note of the following key attributes:

• Name: Name displayed in the SessionM interface when navigating the Org selector. Org-level setting.

• ID: Unique identifier for an org. For example, if using orgs to represent different countries, consider using 3-letter country codes as the ID. For example, the France org uses “FRA”. Org-level setting.

• Currency: Currency used for reporting on transaction spend. For leaf-level orgs, this defines the currency used by every transaction originating from stores in that org. For parent-level orgs, this defines the currency that reporting and modeling use to normalize the child orgs for rolled-up metrics. Org-level setting.

• Preferred Name: Name for your org's use case. This value is used to customize the SessionM platform interface. For example: market, brand, country or division. Environment-level setting.

• Custom Profile Attribute: Custom profile attribute used to assign profiles to orgs. For example: market, brand, country or division. Environment-level setting.

Work with your SessionM delivery team to define the attributes for orgs within your multi-org hierarchy.

Hierarchy

A hierarchy is the structure that defines the relationship among all the components of in an Organization Management implementation. SessionM supports hierarchies with up to 5 levels and up 50 orgs. Every org in the hierarchy is represented by a node.

Let’s look at the hierarchy for Verde Enterprises, the example hierarchy used throughout this document.

Nodes

An Organization Management hierarchy has three types of nodes: root, branch and leaf.

Root node

Every hierarchy begins with a single root node. All other nodes in the hierarchy descend from (are children of) the root node.

The root node is primarily for administrative purposes. SessionM platform users with root node (all access) permissions can see, navigate to and work in every other node in the hierarchy. For this reason, the root node should be restricted only to platform users like IT administrators responsible for granting and revoking permissions, and to executives in charge of the overall loyalty program.

Only SessionM objects that are objects shared among the various orgs in the loyalty program should reside in the root node. For example, corporate-branding templates that are used across orgs. Or a “golden” audience from which all other audiences in the loyalty program should be derived.

The root node in the example hierarchy is labeled “Verde Enterprises”. The IT administrators responsible for the SessionM deployment and the head of the overall loyalty program are assigned the external role of “verde-ent-group”, which grants access to the root node.

Branch node

Branch nodes classify the nodes in the loyalty program into logical sub-divisions in the enterprise. Branch nodes represent the distinct brands, regions, districts or geographies in the loyalty program. The example hierarchy has two branch nodes, “Verde Retail Group” and “Verde Real Estate Holdings”. These branch nodes divide the loyalty program into two groups: retail and real estate.

Leaf node

A leaf node represents a distinct business unit or market in the loyalty program. Leaf nodes are the least privileged. These represent, at a minimum, the countries, brands, business units, or franchises that you’ll need for your loyalty program. Marketers and customer service agents use a single SessionM instance and interface to manage their programs and triage customer issues.

Considerations when designing a hierarchy

The design of the hierarchy is critical because it sets the stage for how the SessionM platform can be used within and across orgs. Consider the following:

Permissions

An external role can be created and associated with each org. This mechanism gates SMP user access to customer data and program configurations assigned to the org. You may want some employees to only have access to a single org, while others need access to multiple orgs.

The SessionM platform uses external roles created for each org in the hierarchy to enable different access rights for SessionM platform users. Any platform user that requires access to a multi-org environment requires at least one external role that has been assigned to an Org. If not, the platform user sees an error at login and cannot access any SessionM modules.

Note that there is no inheritance logic applied to the external permissions for parent-level orgs. That is, if a SessionM user is given an external role for “Verde Retail group”, they would not automatically be given the roles for “Haven Craft”, “Canada”, and so on. If SessionM platform users need full access to the child orgs, they must be given those external roles as well.

Just like with regular external roles, multiple roles can be combined together to provide the required level of access. For example: If a client wants an employee to only have access to the Campaigns module for Green Harvest Organics, then that employee should be given the Green Harvest Organics external role and the standard ext_campaign_creator external role.

NOTE: The SessionM delivery team creates the external roles. You then assign these roles to the SessionM platform users as appropriate.

Root node permission

The image below shows that a SessionM platform user with root access can traverse the entire hierarchy in the loyalty program. In this example, a user assigned to the “Verde Enterprises” group can traverse both branches in the hierarchy.

Branch node permission

The image below shows that a SessionM platform user with branch node access can traverse all nodes in that branch. In this example, a user assigned to the “Verde Retail Partners” group can traverse the left side of the hierarchy.

Leaf node permission

The image below shows that a SessionM platform user with leaf node access is only able to access their own node. In the example below, the SessionM user is only granted access to the Haven Craft node.

Program configurations

SessionM constructs like campaigns, audiences, tier systems and offers are assigned to orgs. They can be assigned to any org regardless of its level in the organizational hierarchy. For some program constructs like campaigns, business logic is automatically applied according to the org assignment like audience targeting, venue restrictions, and outcomes available to select.

Example organizational hierarchies

Several example organization management hierarchies are discussed below. These examples represent the business types best suited for the initial release of Organization Management:

• Multi-org

• Multi-brand

• Multi-market

• Coalition

Multi-org hierarchy

A multi-org hierarchy has multiple programs in either the business-to-business (B2B) or business-to-consumer (B2C) environments. For example, a chain of hair dressing salons that has a loyalty program in which both customers and employees participate. Using Organization Management, the retailer partitions the program into separate programs, providing different loyalty experiences to customers and employees.

Multi-brand hierarchy

A multi-brand hierarchy supports one or more programs spanning multiple brands. All programs use the same earn & burn rules. A single entity owns all brands. Verde Retail partners can choose whether all of its brands participate in a single, over-arching loyalty program, or whether each brands has its own dedicated loyalty program.

Brands under the umbrella of a shared parent company create an end-to-end loyalty experience while centering customer convenience. A multi-brand loyalty program offers brands a unified approach to customer rewards and incentives. The strategy encourages cross-vertical shopping, ultimately keeping share of wallet within the brand ecosystem. Rather than seek out alternative companies for their shopping, members will redirect their spend where they gain the most value: your loyalty program.

Multi-brand loyalty programs are created by larger groups that consist of multiple subsidiaries, such as PepsiCo. In this case, we’re talking about an in-house reward system for sub-brands and/or partners that offer slightly different products or are based in different regions. This provides all independent brands with access to the same loyalty engine, but they each have the option to create their own offers and rewards. This ensures that the loyalty program maintains its look and feel across all brands, while each brand enjoys the freedom to tailor the reward experience to their image, to a certain degree.

NOTE: Do not confuse multi-brand loyalty programs with loyalty coalitions. In a multi-brand program, a single parent company owns all the brands. In a loyalty coalition, the brands are independent with a third-party broker managing the program.

Multi-market hierarchy

A multi-market hierarchy use Organization Management to define multiple regions or geographies. Brands that operate across multiple geographies often times run programs independently by region, or at least want to allow for some variability in program structure or campaign strategy across geographies.

In the example below, Friendly Fries might run a single program across the US and Canadian markets, but uses leaf-level orgs to represent different states and provinces so that they can run campaigns and offers specific to those regions.

Coalition

Often called shared loyalty programs, coalition loyalty is a unique concept in which multiple brands join together in a partnership and offer a joint loyalty program. Not to be confused with umbrella loyalty or group loyalty (where businesses with large brand portfolios offer a loyalty program across individual brands). Coalition loyalty is in play when many unrelated brands band together to offer customers rewards that can be earned from a variety of participating brands, with options to redeem rewards at the brand of their choice.

A coalition loyalty program is a collaborative rewards structure in which individual brands from across loyalty markets join in a shared loyalty program. Coalition loyalty programs are often launched by a single business, extending the program to multiple partner brands known as tenants. Tenants in coalition loyalty programs are typically non-competing in nature.

In the following figure, Arctic Airways has expanded its loyalty program to include complimentary brands.

Deploying Organization Management

This section describes how to deploy Organization Management in SessionM.

Implementation team

The SessionM Delivery team is required to enable Organization Management in your environment and configure it according to your needs.

Specific roles and responsibilities include:

• Solutions Architect – Gather your requirements and design the organizational hierarchy design that best meets your needs

• Integration Engineer – Configure your environment to support Organization Management and define orgs, including:

  • custom profile attribute that designates the organization to which the user belongs.

  • organizations that represent your business.

  • images that represent each organization.

  • mapping program configurations to organizations.

Technical requirements

You are required to use SSO to authenticate employees with the SessionM platform. The SSO provider must be integrated into the SMP dashboard for employee authentication.

Implementation process

Contact your SessionM Customer Success representative to plan and deploy Organization Management for your brand.

Working in an Organization Management environment

This section discusses the following aspects of working in an Organization Management environment:

• Self-service and admin-only modules

• Line of sight in self-service modules

• Using the Org Selector

• Landing page for self-service modules

• Audience and Composer modules

• Customers module

• Campaigns module

• Insights module

Self-service and admin-only modules

SessionM modules in an Organization Management environment are classified as either self-service or admin-only.

Self-service modules have had their interfaces enhanced to support Organization Management. You can implement multi-org functionality in these modules directly. These modules include:

• Audiences

• Composer

• Campaigns

• Customers

• Promo codes

• Insights

Admin-only modules have not yet had their interfaces enhanced to support multi-org functionality. You cannot implement multi-org functionality directly in these modules. Organizational assignments are performed by an administrator who have permissions to see across the entire hierarchy. The administrator can be your platform administrator or a SessionM account team member.

These modules include:

• Loyalty

• Offers

• Points

• Reward stores

For the most part, working in an Organization Management environment is the same as working in a standard SessionM environment. Any differences relate to the active org and your level of permissions.

This section discusses the differences that platform users (for example, marketers and customer service reps) need to be aware of when working in an Organization Management environment.

Line of sight in self-service modules

Line of sight refers to the other orgs in the hierarchy that you can see (navigate to) from the active org. Depending upon the assigned permissions, the user’s line of sight can travel up the hierarchy, down the hierarchy, or both up and down the hierarchy. That is, the SessionM interface displays those levels of the hierarchy that include the current org and its parent (ascendant) orgs, and any descendent or child orgs.

Example hierarchy

Let’s use the following hierarchy as an example:

Using the Org Selector

The Org Selector is the navigational component in an Organization Management environment. The Org Selector:

• indicates the org in the hierarchy to which this platform user is currently assigned. This is called the “active org”.

• enables users with the appropriate permissions to switch to different orgs in the hierarchy.

In the example SessionM dashboard shown below, the Org Selector (located in upper right corner of the interface) indicates the org that is currently active (here, Verde Retail Group).

Assigned to single organization

For SessionM platform users assigned to a single org in a multi-org hierarchy, the Org Selector indicates the org to which this user is (permanently) assigned (in this example, Haven Craft). The selector is static. The user is not able to change to another org in the organizational hierarchy.

Assigned to multiple organizations

For SessionM platform users assigned to multiple orgs in a multi-org hierarchy, the Org Selector indicates the org to which this user is currently assigned (in this example, Verde Retail Group).

The selector is dynamic. The user can change to different orgs in the organizational hierarchy depending on their level of permissions.

Line of sight in the Org Selector

In the Org Selector, you only see the orgs to which you have been granted permission (that is, you have an external role for that org).

Changing the current org

Platform users in a multi-org environment can switch to other orgs in the hierarchy to which they have been assigned external permissions.

To change to a different org, select that org from the Org Selector list. SessionM asks you to confirm the change. Click Confirm.

Take note of the following about switching orgs:

• When a user logs in to the SessionM platform, the active org is set to the org that was active when the user logged out.

• Users do not need to sign out and back in to change orgs.

• If a platform user changes orgs in the middle of creating or editing an Audience, Composer Audience or Campaign, they are prompted to save the current work before continuing, or the current work is lost.

Landing page for self-service modules

The landing page for self-service modules has the following modifications:

• The Org Selector indicates the active org. Use the selector to change the active org.

• A column that indicates the org in which this campaign was created. This name is custom to the implementation (taken from the “preferred_name” attribute).

• The list of objects (audiences, campaigns or promo codes) shown on the landing page is constrained to the line of sight of the active org (explained below).

Line of sight on self-service modules’ landing pages

Line of sight extends both up and down the organizational hierarchy. That is, the interface displays all campaigns assigned to the active org, any of the ascendant or parent orgs, and any descendent or child orgs.

In the example hierarchy:

• When the active org is set to Verde Retail Group, the SMP user sees SessionM objects (for example, campaigns) assigned to the Verde Retail Group, Green Harvest Organics, Everyday Edibles, Verifiably Vegan, Peak Sporting Goods and Carl’s Curling Supplies.

• When the active org is set to Green Harvest Organics, the SMP user sees SessionM objects (for example, campaigns) assigned to Verde Retail Group, Green Harvest Organics, Everyday Edibles and Verifiably Vegan.

• When the active org is set to Everyday Edibles, the SMP user sees SessionM objects (for example, campaigns) assigned to the Verde Retail Group, Green Harvest Organics and Everyday Edibles.

• When the active org is set to Peak Sporting Goods, the SMP user sees SessionM objects (for example, campaigns) assigned to Verde Retail Group, Peak Sporting Goods and Carl’s Curling Supplies.

Program configurations assigned to branch-level orgs are inherited by child orgs in both business logic and in the SessionM interface. For example, an audience created at the category-level includes customer profiles assigned to all children orgs.

NOTE: Future releases will introduce a “Private” vs “Public” concept to all self-service modules. This will allow only “Public” objects to be inherited. Private objects will only be accessible by users with access to the Org to which the object is assigned.

Audience and Composer modules

Take note of the following differences when working in the Audience and Composer modules in a multi-org environment.

Assigning audiences to an org

When creating a new audience in a multi-org environment, you need to assign that audience to the org within the hierarchy.

Assignment will default to the Org the user is Active in at the time. If there’s a need to change the assignment, the user will be able to choose from any of the parent or child orgs they have permission for.

The most common use case is where a marketing manager assigned to a single org creates one of these objects. For example, a Group Brand Marketing Manager setting up campaigns for several brands at a time. Rather than repeatedly switching between “active” brands, they simply change the assignment of the audience itself.

Targeting audiences

When building audiences, the starting set of customers eligible to be included in the audience is limited based on the org to which the audience is assigned. Inheritance logic is applied down the hierarchy. If the active org is at a parent level, then the pool of eligible customers includes customers from its children’s orgs.

In the example hierarchy:

• When the active org is set to Verde Retail Group, all customers are eligible.

• When the active org is set to Green Harvest Organics, customers assigned to Green Harvest Organics, Everyday Edibles and Verifiably Vegan are eligible.

• When the active org is set to Everyday Edibles, customers assigned to the Everyday Edibles are eligible.

• When the active org is set to Peak Sporting Goods, customers assigned to Peak Sporting Goods and Carl’s Curling Supplies are eligible.

Working with cards for segments and attribute groups

SessionM limits the values displayed in the interface elements (for example, drop-downs and selectors) to the org. Inheritance logic is applied up and down the hierarchy.

• In the Audience module, the available values for the Audience segment are limited to active org.

• In the Composer module, the available values for the following elements are limited to the active org:

  • Points

  • Loyalty Tier

  • Offers

Additional considerations the Audiences, Composer modules

Audiences

• When navigating to Manage Exports > Destinations, the list of destinations is not limited to the current org. All destinations in the entire loyalty program are returned.

• When navigating to Manage Exports > Encryptions, the list of encryption methods is not limited to the current org. All encryption methods in the entire loyalty program are returned.

• When configuring a bulk offer issuance, the Select an Offer picker is filtered to match the current org.

Composer

You can use account permissions to disable the Composer Query Builder to prevent non-admin users from querying data across orgs.

Customers module

Take note of the following differences when working in the Customers module in a multi-org environment.

Searching for customer profiles in the Customers module

Customer search results are constrained by the active org assigned to the SessionM platform user. Line of sight extends down the hierarchy only. If the active org is at a parent level, then search results include customers from its children orgs.

Customer search works as follows:

• When the active org is set to Verde Retail Group, search results include customers assigned to Verde Retail Group, Green Harvest Organics, Everyday Edibles, Verifiably Vegan, Peak Sporting Goods and Carl’s Curling Supplies.

• When the active org is set to Green Harvest Organics, search results include customers assigned to Green Harvest Organics, Everyday Edibles and Verifiably Vegan.

• When the active org is set to Everyday Edibles, search results only include customers assigned to Everyday Edibles.

• When the active org is set to Peak Sporting Goods, search results include customers assigned to Peak Sporting Goods and Carl’s Curling Supplies.

Additional considerations

• Displaying data in customer profiles: Customer data is not filtered in the returned profiles. For example, their activity log, issued offers, and current point balances are included in the profile display regardless of the permissions of the customer service agent performing the search.

• If a customer profile belongs to more than one org, their program data and history are visible to any SMP user that can access their profile. For example, if they’ve earned points in Green Harvest Organics and Koalla Retail, customer service agents from either org can see both balances.

Campaigns module

Take note of the following differences when working in the Campaigns modules in a multi-org environment.

Assign to org

When you create a campaign, you need to assign it to an org in the hierarchy.

• If you are assigned to a single org, then you must assign the campaign to that org.

• If you are assigned to multiple orgs, you can decide which org to assign the campaign to. Generally, assign the campaign to a leaf-level node. Most campaigns operate with the boundaries of a single node.

• However, if you are responsible for creating campaigns that span orgs, create the campaign in the branch level that is the parent to all of the orgs that the campaign needs to span.

Targeting audiences

Campaign targeting automatically filters for customers that belong to the org to which the campaign is assigned and any child orgs.

Define behaviors and outcomes

When defining behaviors and outcomes for campaigns, the Campaigns module only shows audiences, behavior restrictions, behavior and targeting templates, point sources, point accounts, and offers that match the user's orgs.

Customer Behavior configuration

• In rules with catalog restrictions, the SKU picker is not filtered since there is a single catalog used by all orgs.

• The Qualifying Locations restriction only shows venues with the venue tags that match that the user's current org and only allows for further exclusions to be made.

• Behavior templates are limited to the user's orgs.

Outcomes configuration

• Point sources and accounts are filtered to only show those that match the user's orgs.

• Offers are filtered to only show those that match the user's orgs.

Define messages

• Outcomes and other campaign selectors are limited to the user's orgs.

• When configuring bulk offers, offers are limited to the user's orgs.

• SessionM does not filter messaging providers, variants, and templates, since they are available across orgs.

Additional considerations

Campaigns

• The Campaigns calendar only shows campaigns that match the user’s orgs.

• Campaigns automatically restrict transactions by org. As part of the Organization Management back-end configuration, every store is assigned to an org. Since every transaction comes from one of these stores, SessionM can automatically set store restrictions on campaigns so that the rules engine only evaluates transactions coming from stores belonging to that org.

• The behavior builder interface allows platform users to exclude venue tags for further filtering, but only by venue tags, not venues.

Insights module

Insights reports are limited to a single, leaf-level org. You cannot use Insights to generate reports that span orgs. The following image shows a report generated for the United Kingdom org, which is a leaf-level node in a multi-region hierarchy.

The SessionM platform returns the following error if you attempt to report on an org that is not a leaf-level node.