At Tines we drink our own champagne. The tines@tines blog series is a testament to the unique ways we’ve leveraged Tines to accelerate our own processes. As the title implies, this post is about how we built a self-service free trial process using Tines.
The brief
This all started with the following goal: let our users try cases for free. We’d get valuable feedback, and our users would experience the value of cases. What’s not to like?
The original plan was to manage it entirely manually. Our users would contact support or their CSM, then the CSM would enable the feature and set a calendar reminder to disable the feature after 45 days. We got this!
However, the problem was the manual approach lacked:
Any real tracking abilities
A way to manage the backend mechanics of the trial
Considerations for sick days or out of office
Visibility for the customer into their trial duration
Freedom for the customer to activate the trial without friction
The launch date was June 7th, and I briefed Martin and Ruairi on May 22nd. We had 16 days to build, test, and release something that had taken months with entire teams to build in previous companies. It involved designers, engineers, roadmap, and months of development work to tackle. When Martin replied with, “give me an afternoon to tinker with it,” it’s safe to say Ruairi and I were a little skeptical.
So, I mapped out what the workflow and process should look like using the storyboard as a diagramming tool. It looked like this:
Then I sent the following Slack message to Martin:
Hi Martin — I added you to my tenant and once you accept the invite, I can add you to the team that it’s on. I’m curious about how to get the story to run and provision then de-provision cases and records on a customer tenant.”
Nice, vague, wildly overconfident.
The output
So, that was the brief in full. It turns out that I had wildly underestimated what we could actually build in Tines. Martin, being a bit more familiar with the mechanics of how we provision access in Tines, took this outline and started building to solve the problem.
“As soon as Kelli sent me the initial sketch of her plans, it was perfectly clear that yes; we can build this in Tines. And more importantly, yes we absolutely should build it in Tines! The key thing was to not look at it as a whole, but to look at each step, imagine the API calls and logical decisions that go into it, then translate that into Tines bit by bit. This makes the problem a lot more approachable.”
Goal: let our users self-serve their cases trial
With this goal in mind, Martin started by checking which steps we needed to do this and the tools to execute each step. From there, he started building out the story.
Four hours later he had a working POC that used pages to kick off the interaction.
Diving in and building the first POC was a lot of fun, and very satisfying that in just a few hours we could build out not only a working application complete with audit tracking, but also a portal for our internal team to view and manage trials.”
Martin Moroney
From there Martin, Ruairi, and I met to discuss the build from the different user perspectives: internal, customer, and community edition. Martin saw this as a teachable moment to help upskill Ruairi and I on Tines and where the pieces came together. In the discussions, we realized we hadn’t got things quite right. The primary gap was internal tracking so Martin expanded the build to interact with Snowflake and Salesforce to keep track of our trial volume in our systems of record.
By the end of the week, we had the following:
User-facing app to request a free trial
Internal app for us to check and manage an existing trial
Workflow that provisioned, managed, and deprovisioned access to the trial including updating Snowflake, Salesforce, and our cases
Post-trial survey to learn about the users trial experience
Conclusion
With Tines, we gave our users the ability to self-serve their trial on their timelines. In doing this, we gained a lot of valuable insight into our cases and records features much earlier than if we used the manual approach.
On top of that, we were able to extend our product launch and simplify how our customer success team managed feature trials without disrupting our engineering process. Our engineers were able to focus on delivering additional features for cases instead of building free trial mechanisms. And, our commercial ops team had a clear line of sight into the progress of this launch and our customer expansions.
I was so excited to watch and learn how what looked like a very complicated concept come to life so quickly demonstrating the unique ways we can use Tines as a solution for product marketing.
Check out the app
This is a visual of our internal and external app screens built in Tines!
