Acknowledged

Ability to have different content(Engagements) depending on which URL the user is on

Votes
S
Rank
Userlevel 5

Posting on behalf of a customer:

In a KC Bot Currently we cannot show different engagements based on the URL the user is currently on. It would be great if we could show the different content(Engagements) based the URL the user is on.

 

Use Case: If a user in on a URL1 then the user should see Engagements(if any) related to URL1  in  KC BOT  and If a user in on a URL2 then the user should see Engagements(if any) related to URL2 in the same BOT.  

4 replies

susan_parker
Rank
Userlevel 1

Our online help is context-sensitive, and directs users to the correct section of the help based on the page they are currently viewing.  Our expectation would be that KC items would be similarly responsive.

If I am working on meeting minutes and need assistance, the KC should first offer any engagements, articles, videos that are related to that topic based on where I am located in the product.  The category of the webpage for analytics should correspond to the category of the engagements and other materials.

A
Rank
Userlevel 1

We have a large application, and several different types of users. We are very limited by not having the ability for the knowledge center bot not being contextual. Very little of our content would apply to ‘all’ users.

Jef Vanlaer
Rank
Userlevel 6
Badge

It would be really useful for us as well to be able to launch a different KC Bot or different engagements in one bot based on the url, as we have different Hubs in our software that can be distinguished based on the url.

@link_black Based on your experience, do you see a workaround for this?

T
Rank
Userlevel 1

Much like Jef’s situation, this would be super helpful for my application, as well. We have a lot of deep modules in our application (following specific URL components like */project/survey/view*), and each customer gets their own unique domain. We can’t use the “URL redirect” function available to engagements now because of those dynamic domains and query parameters, so choosing a URL Rule to make an Engagement available in the KCBot would let us build contextual, on-demand support guides. 

 

There are few things more obnoxious in the Support world than incorrect or out of context guidance. Big, big, bigbigbig value in preventing that.

Reply