Sharer/Shared Calendar/Shared Table Concept and Configuration in Smart Scheduling (MustMeet) platform

In this article we take you through the concept and set up steps of a Shared Meeting or Calendar. 

Note: Sharer concept is only applicable to Classic Smart Scheduling Platform NOT any2any.

 

What Does Shared Table mean?

What are the shared table requirements?

What "sharer_id" is?

Shared calendar requirements

What should I ask from the Organiser in order to apply this function?

What should steps should I take if the organiser asks for a shared calendar/share table/shared meetings?

What if my buyers have the location attached and sharers?

What if my supplier group which has a location has sharers; but then the buyer group also has sharers?

FAQs

  1. How does the preference phase work for sharers?
  2. They can each make preferences, right?
  3. If yes, how does that impact the scoring for their shared table?
  4. If only one logs in and makes preferences, the second sharer would still get tacked onto those meetings or do they need to log in themselves?
  5. and more questions below

 

What Does Shared Table/Shared Meetings mean?

Let me explain this from a real life experience.

Imagine that you and a couple of your colleagues have been invited to the "Event Tech Life" event. Grip has 1 table assigned at the event "Table - G001". 

Meeting Organiser (Supplier) Grip: Jack, Kate,Emma, Amy, Sara,Chatheren Grip: Jack, Kate,Emma, Amy, Sara,Chatheren Grip: Jack, Kate,Emma, Amy, Sara,Chatheren
Invitees (Buyer) Toma (Expo) Lively Coconex
Meeting Time   4:00 - 4:30 Pm 4:30-5:00 Pm 5:00-5:30 PM
Grip Table Table #3 Table #3 Table #3

 

This is a shared table concept. It means that all Grip representatives ( 6 people) will meet with 1  buyer at table #3. Shared table also means that all Grip representatives will share the same calendar throughout the event.  

Therefore the conditions for having shared meetings are as follows: 

  1. Shared Table is ONLY applicable to the HB classic. Any2any events do not have this function. 
  2. Shared table can only be applied to the type that has the location assigned. In HB Locations/tables are only assigned to 1 type. 
  3. Attendees from the same supplier share 1 table.
  4.  Attendees from the same Supplier Share the same calendar throughout the entire event. 
  5. Sharer relationship must be added to the data before phase 1- stage: set "Must meet", "Meet" and "No Thanks". 

Shared table = Shared calendar=Shared meetings

 

What are the shared table requirements?

  • sharer_id
  • Sharer relationship
  • Shared location
  • "wwe_meetings_unique" with the value of "Exclusive Meeting"

What "sharer_id" is?

"sharer_id" acts like an Exhibitor ID but to connect 2 users/suppliers in a shared calendar set up. 

You may have instances where not all the supplier representatives want to share a meeting in one location. 

For example: Grip sends 7 people to the "Event Tech Life". 

Grip: Jack, Kate,Emma, Amy, Sara,Chatheren are assigned to 1 table> will have a shared calendar. 

Grip: Tim Groot 

With "sharer_id", system connected Jack,Emma, Sara and Catheren together and on the front end shows as a sharer. But excludes Tim.

Difference between a "sharer_id" and "exhibitor_id" in a HB platform. 

  Company Sharer
exhibitor_id Tim tConnects Jack, Kate,Emma, Amy, Sara,Chatheren,Tim Grip  
sharer_id   Connects Jack, Kate,Emma, Amy, Sara,Chatheren with each other

 

Shared calendar requirements

Items Comment
Sharer relationship Create on the Grip dashboard > Data types 
sharer_id  Metadata 
Shared location All sharers must have a shared location
wwe_meetings_unique Add value:Exclusive Meeting 

 

What should I ask from the Organiser in order to apply this function?

You have to ask 2 questions:

  1. Do you have any of your suppliers who share 1 table at your event? Or 
  2. Do you have any supplier that are going to have the same meetings or same calendar throughout entire event?

What steps should I take if the organiser asks for a shared calendar/share table/shared meetings?

For the purpose of this meeting, let's assume that the meeting tables are attached to the supplier type. 

1- Make sure that the 2 supplier representatives who are going to have a shared calendar are both attached to 1 table. 

In the example above: 

 Supplier Grip: Jack, Kate,Emma, Amy, Sara,Chatheren
Connected to (Table relationship) Table#3

2- On the Grip dashboard create a relationship between the suppliers (User to User relationship). Please note that prior to 06.05.2022 the PM had to raise a ticket in Jira but after 6th May 2022 this is no longer required. 

1-Nov-07-2023-12-32-07-5980-PM

3- Connect sharers

  • API integration: Make sure that the supplier representatives have an unique "sharer_id"
  • Blender Import: Make sure that the supplier representatives have an unique "sharer_id"
  • Manual connection: Create a relationship for the users on the Grip dashboard manually: 
    1- Go to the user profile 2- Click on Relationships 3- Add a relationship
    4- Select the sharer relationship > from the dropdown list add the the other user

4- Add "wwe_meetings_unique" metadata with value "Exclusive Meeting" either through API, spreadsheet or manual

5- Assign 1 location to the who are going to have a shared calendar.

5- Double check the sharer attendees if they are connected as a sharer

2-Nov-07-2023-12-32-21-8404-PM

3-Nov-07-2023-12-32-34-1031-PM

 

What if my buyers have the location attached and sharing a table?

Sharer rule: 

  • Sharer only works for HB classic 
  • Sharers works for supplier type only 
  • Sharer works for the supplier type that has a location assigned

So far we never had an event in which the buyer type at the same time location assigned and sharers. We had events where buyers had a table but they never had a sharer option. However if in the future this case comes up there is a workaround for it. We always advise you to tell to the client that this is not possible because this is not how the product has been designed. However if you get stuck in this situation then this workwound would work: 

Sharers only works for supplier group because H2h is programmed to recognise the sharer by the "supplier group". How does H2H recognises the groups? It is by the "group_type". Therefore if you swipe the "group_type" for the buyers and suppliers; H2H would take your buyers as a supplier and supplier as buyer. The logic is the same way when we assign a table to a buyer here . 

For buyers: Enter "group_type" suppliers

For Suppliers" Enter "group_type" buyers

What if my supplier group which has a location has sharers; but then the buyer group also has sharers?

We can have sharers for the supplier group which has a location assigned. If the buyer group also has some people sharing meetings then you should: 

1-  Put 1 buyer as a primary contact in the HB Buyer group. 
2- Put the rest of the buyers in a non-HB “additional” type. You do not include this additional type in the HB experience and HB setting. The additional buyers will not be invited to the HB experience. 
3- When HB meetings are finalised (Closed phase - finalised phase), the main buyer can invite the additional buyers to each meeting separately. We user "invite additional attendee" function. 

 

FAQS

How does the preference phase work for sharers?

If one of the sharers swipes on a buyer, the other sharer will get notified if she/wants to swipe on the buyer. For example:

Supplier Kate and Jack are sharers. Buyer Nick is recommended to both of them.
Jack swipes must meet on Nick.

Here: When Kate sees Nick and clicks on any of the preferences she will get a message that Jack has already swiped on Nick. So that Kate can either skip or set a different preference. 

 

They can each make preferences, right?

They both can make preferences. Both can activate their account and has their own journey. 

 

If yes, how does that impact the scoring for their shared table?

System takes whole sharers as 1 entity against 1 buyer. For example if 5 reps have a sharer relationship, the system considers their scores as 1 rep against 1 buyer and applies the standard rule. 

1- In the case where any (supplier) sharing a table has expressed a negative preference (they don't want to meet with the buyer), or the buyer has expressed a negative preference on any of the sharers, then the scores will all be 0 and they will not meet.If any sharer says not interested - no meeting will happen.

2- If the buyer says "No thanks" to any of the sharers: The score would be zero and no meeting would be generated 

3- If one of the sharers says "Must meet" and the other sharer says "Meet" to 1 buyer: System takes the higher swipe between the 2 sharer into consideration and allocates a high score. 

4- In the case when one particular sharer has not expressed an interest in the buyer, nor has the buyer expressed an interest in them, but other sharers have expressed positive interests, or the buyer in one or more of them - then the scores of the person with no interests will be raised, but not to the level of those who have expressed an interest.

Profile name To Profile Score  Score_reason
Supplier A Buyer X 0 S: Must meet - B: No thanks
Supplier B Buyer X 0 S=Must meet - B: Meet
Supplier A Buyer X Must meet high score S: Must Meet - B: Must Meet
Supplier B Buyer X Must meet high score  S: Meet - B: Must Meet or Meet

 

If only one logs in and makes preferences, the second sharer would still get tacked onto those meetings or do they need to log in themselves?

Ok here we have 2 rules: HB only generates meeting for active users. Basically if someone is not activated, HB counts that that user does not exists. 

Sharers A and B What happens to their meeting Solution
Sharer A activates his account - Sharer B does not activate his account  Share A only gets meeting.  Ask the organiser to activate sharer B.Then both will get meetings in their schedules. 
Sharer A activates his account - Sharer B activates his account Both will get meetings   
Share A activates his account and makes preferences - Sharer B activates his account and does not take any action Both will get meetings.  System takes the higher swipe/score between the 2 sharer into consideration and allocates a high score. 
Sharer A activates his account - Sharer B activate his account after meetings are generated.  Sharer A only gets meetings Please refer to the below section on how to manage this. 

 

We just need to manually create the relationship between two sharers in the DB? Or is there also a line of metadata that needs to be added somewhere?

Through API: unstructured metadata "sharer_id"

Manually: A sharer relationship via the data type. You can go to each user's profile> relationships> connect them as sharer. 

Where does the relationship to the table go? Is this the normal default meeting location but specific to the table?

You have to assign both to 1 location/Restricted table (booth)

 

Sharer A activates his account - Sharer B activate his account after meetings are generated. 

In this situation only sharer A gets meetings. To enable sharer B to have the same meetings after he activates his account you need to follow the following step: 

1- Activate Sharer B
2- Reload the data to H2H
3- Find Sharer A
4- Go to sharer A profile in H2H
5- Unbook every single meeting and book them back ( Get a screenshot of the meetings for reference)
6- Approve schedule 
7- Push back to Grip