Is there a way we can reference the user_device to initiate conditional jump logic flows when applicable? My specific use case would be a customer is scheduling a test for a written test. Depending on the user_device, I would like to send users to different content (or include content specific to mobile device users). So if they are using a mobile device, they will be sent to a gambit to download our practice test app after they have schedule their appointment. If they are on desktop, the conversation goes on like normal, skipping the offer to download the app.
This is a simple use case, but I can think of a lot of other practical applications for a feature like this.
It would allow us to branch users at the beginning of conversations as well. Our desktop bot can run specific tasks that work well as an integrated feature into the website, where as our mobile bot could act more as a standalone feature that drives the users as a chatflow version of the website. Thoughts?
This is an undocumented feature in the product already.
You can use usys data scope to get some bot and client level varaibles. e.g.
{{usys.deviceType}} will give you the userās device type on which chatbot is being opened. this can be: Desktop, Mobile (Android), Mobile (iPhone) or Mobile (iPad)
{{usys.userAgent}} will give you the full UserAgent string for the deivce, which includes information about the device brand, model, platform, OS etcā¦ and is a unique string for a specific device
{{usys.convid}} will give the unique ID of the ConvBot. This is the same ID that you see in the URL of the Chatbot e.g. in this chatbot URL: https://mantis.hellotars.com/conv/B1UbxO/{{usys.convid}} will give B1UbxO
{{usys.tempDocid}} will give the unique ID of the current conversation that is happening with the user. This ID is randomly and auto-generate for a given ongoing conversation and will change on a page refresh on the chatbot. This can be used when you want to identify a submission on a chatbot.
Check these out. We will see and try to include more interesting variables here at the client global level. Let me know if you have any other interesting variables you want to see here.
You can use these variables in any gambit, even in the first one.
In your use-case you can use this in the conditional jump section to branch out the conersational flow right after the first gambit.
Using Zapier, we could use {{usys.tempDocid}} as an āauto-generated, unique, reference codeā to automate tracking user requests, information, etc. by Zapping it to Google Sheets, and then making a call to GS to pull user information based off of that id maybe? We could send that code to their email (using zapier as well) then when they log onto the bot and text submit their {{usys.tempDocid}} from when they submitted their info, we could run an API call and always pull that users info since the code is unique to their submission. Could be a great way to build a āsubmit a claimā bot. That way a company could adjust the column to that customer submission from pending to resolved and the user would get that information through the callā¦ This could be a lot of fun!
Hey guys,
Maybe wrong chat but this looks like it could develop into a ticketing system like zendesk where users can create support tickets and track them all BUT through a bot interface. I suspect it would have to tie into something like trello where tickets get answered so it can then report back the results on requestā¦ And people may want to be able to see all their tickets in one placeā¦
The bot can most definitely be the front face part of a typical Ticketing system, which can connect to some CRM which does all the rest of the things like ticket management, assignment to a team member etcā¦
Hey Karl - you should check out how Leo Dicaprio does all of this (helping the users create service requests and then check the status of it) using a Tars chatbot and Google sheets.
Just started experimenting with a bot to do this. The only issue I had was getting information back from a Google Sheet using the unique, conversation ID, which I generated by placing it into a button the user would click to capture it. I was able to recall the info if I stuck to numbers only in tests, but the convo ID has letters and numbers in it. I tried treating it like a string by adding the ā{{ursp.status}}ā but it still failed the call. I had to run out of the office, so I didnāt get a chance to tinker more with it, but that is the last puzzle piece to verifying this test. Any advice @vinit?
After researching, I couldnāt find a definitive answer either. It seems that there is not an easy solution for identifying a mix of letters and numbers in JSON. Iām pretty illiterate in this area
I solved this by generating a random number using math.js. Iād imagine if you changed the parameters once a month between 10,000 possible numbers, you would likely never run into a problem. Not the ultimate solution, but it works to demo for now!
Currently the timestamps info is not there in usys data scope.
But you can use this to get the real time current timestamp from the userās browser and use it the API calls to submit as a data point. This is the syntax to get current timestamp of userās browser:
Is there anything else involved with using {{=new Date()}} to pull the time stamp? I tried it with the Zap to a Google Sheet and didnāt a value transferred to the sheet.
Following from Leviās amazing work, and, again, maybe this has been answered, but if we could get it to retrieve then we could have a form that people can half fill out and come back to later (with login or cookie) to continue finishing itā¦
Handy for complex forms as well as tests.
Is there a way to refer to the startgid that you used to launch a conversation from with a user? So if I have a link https://dojmt.gov/bot-mvd-driver-services.html?_startgid=47 and I want to filter users to a different ending through conditional jump logic based on that factor, is that possible?
Awesome! That makes perfect sense. I figured there was a way. This will work great with auto-close widget in conjunction with #tarsbot to send users down specific funnels and send them back out or not based on external or internal convo flows.