Just wanted to show off my work on this insane fee calculator. It has roughly 48 API call gambits to handle the complex nature of the fees and percentages. Many, many, of the connection shown below are conditional jump logic filtering everything from MSRP on a vehicle and vehicle type/year to counties and specialty fees triggered in specific instances.
To handle IE’s issue with rounding uvals, I built extra columns and rows in a google sheet (which I have to refer to for depreciation percentages based on vehicle age), and it pulls those extra data points in my GET API call to the sheet. Then I reference that call in my calculation APIs instead of a uval.
There are some rounding issues causing a variance of $.99 to .01 or a repeating decimal to display instead of currency format that I am still working on, but overall this thing is massive while still being quick and easy to the end user. The power of this calculator as a user driven tool is off the charts!
EDIT: Do not select the registration renewal option at the beginning, this only hands off the user to an online app to renew registration of existing vehicles in the Montana system. For checking out this tool, you must select “Continue”.
Give it a try at https://mvd.hellotars.com/conv/r1Qym2/?_startgid=53
Note: Just enter any value on MSRP. If you go above $150,000, a specialty fee is triggered leading to a hefty fee added to the total (I’m cancelling my order for a Ferrari as we speak ).
Seeing this I can’t help but ask you on ways which would have made the bot simpler to make.
Like currently all the maths calculations needs to be done using an external API, instead of that, doing all those calculations in the Bot itself makes a lot sense. Since maths calculations is a very common use-case.
I plan to build this feature, where you can do all maths calculations without having to make an external API call.
Other than this, let me know how else this process could have been made simpler.
I hope you understand that we cannot build all the specific features required to build one kind of chatbots. But we can definitely work on the features which makes sense from the point of view a generic chatbot and align with our own vision for the product.
Thanks again for sharing this bot with us and insipiring the community.
Yeah, absolutely! My only major gripe with math.js is getting things to format right, which would easily be solved with an internal currency calculator. When I first started this calculator, it would of had many more gambits than it does now. Part of my process was to continually simplify the steps while still delivering the solution. Other than an internal calculator, I don’t think there is much more than could cut down on this.
Conditional Jump Logic was huge in simplifying this whole process! Much of my condensing was accomplished with that incredibly powerful tool. It took a couple weeks of focused trail and error to get it to where it is now, but it was so worth it.
Considering the complex nature of all the factors, I think TARS was the perfect tool to make this feature a reality. My next challenge is to make a connection with an API that our internal system uses to automatically generate the user’s MSRP by selecting make, model, year, and features all worked through data iterations and API calls. This will make the calculator exact on the total (it comes in XML, hence the request for a tutorial handling that format).
This is definitely my most challenging (but favorite) feature builds thus far!
Upvote! @Levi Impressive!
Calculations with in Tars would be a huge game changer. Especially being able to pull from other gambits.
Currently, all of my math is being done after the form is completed in a spreadsheet and confirmed with the client in a merged doc.
Looking forward to having more dynamic data during the flow of the forms.
Keep up the great work!
Check out this other fee calculator that I built that is actually running in real time for the State of Montana.
Click “calculate my fees” on any of the buttons to give it a try. This is actually using a Google sheet to pull the fees based on the user factors. No calculations are actually taking place in this example, but it feels like it is.
Instead, fees are routed to specific columns based on user selections (built into the conversation flows), and then the user’s age determines the row and returns that value through an API call.
Still an internal calculator would be huge for numerous industries!
Thank you! Time constraints is the only reason I can’t do some testing. I do like that I could potentially have my database make the bot far more dynamic. This is where building TARS nodes in n8n.io could be beneficial for the community.
Will there be an option to allow people to return to their bot to change answers? That would make using the API even more important having evolving data with two way sync.
Thanks for this inspiration!
The current system above allows users to make multiple calculations over a single session. They do have to reenter information (though you could work around that if you wanted), but the experience is so quick and easy, I never received any user feedback complaining of reentering a few pieces of information.
I saw that. The bot is great. Fast and simple.
For real estate, people often have to get additional data, upload PDF’s, banking info, add their parents. It would be helpful if there was a way to go back and finish of make changes. I used cognitofroms.com previously. I could send a merged doc with a login URL to finish or update their form. We have mode conversion by not having to start over.
The average rental takes 3 to 5 days with data being uploaded or added.
A sale can take 90 to 120 days. New information is being added all the time. Persistence or a way to re-populate from their database record would be great for us and the client.
).
