Conversation Attributes on public pages | Community
Skip to main content

On this new feature release - anyone have ideas on or played with the use of conversation attributes on a non authenticated public page?

 

My use case is to ask some questions (email, product, request type) and then route those conversations to our chat team instead of it being a static webform.

Hey @craig​, a Custom Bot for visitors would work wonders here. You could trigger it on a button click or set it to fire automatically. As part of your bot path, you'll be able to ask your visitors certain questions as you've outlined above, or automatically assign conversation data values based on their actions or responses.


Yup that is what I have done, just struggling to get the transition from visitor to user if they then log in. As the goal is to capture context, push them to login and then carry convo as a user (rather than visitor).


Wonder if you could potentially leverage Intercom's API here? For example, as soon as x attribute has a value, convert lead to user?


Was less about leads and more about visitors who we assume are users but they have not logged in. So we already know who they are, but only when logged in.

 

Same sort of scenario of me visiting Interconnected and not being logged in - if i tried to start a convo with y'all it would not know who i am until I was somehow authenticated.


Gotcha, so what does your desired scenario look like? Is it a case of a visitor providing details, you prompting them to log in, and then that conversation gets merged with their user profile?


Yup exactly - lots of strong use cases for many customers I would feel;

  • Authentication issues, chat pre-auth, get help, log in and the convo merges
  • Public community / web (pre-login), have a chat, get answers, log in and the convo merges
  • As above but on a mobile / diff device and not logged in, need help etc same outcomes as the first 2 points

 

General concept / idea is to reduce friction for end users and still allow their actual records in our systems to reflect the interactions.

 

 

 


Gotcha! I wonder, in that case, if the user/lead merging via the API would still work for you in this case? We treat leads and visitors identically within our API (a lead is only a visitor that's given their email address, after all!)


Reply