How to offer quality, tailored support for hundreds of Atlassian customers with a limited but overly qualified team of professionals? Sounds like a challenge, right? Well, this has been the challenge Deiser has faced and perfected in the last years; one of the main characters of this story will explain through an interview how to repeat his success story.
It’s been nearly a year since Leo Díaz stopped running projects for customers. Rather than becoming anybody’s boss, he’s seen as a facilitator and a coach—always there as a guide in our customers’ Atlassian journeys. As a veteran consultant, Leo accepted the opportunity to talk about his job and how it can inspire other organizations with similar challenges.
This time, we’re dealing with Deiser's steps to automate expert support for our Atlassian customers. Thanks to a combination of Jira and Projectrak (formerly Profields), Deiser could diminish administration work and maximize logged time. In the last four years, the service has multiplied the number of customers subscribed by four without hiring any new staff.
A support pack is a translation of the Spanish "bolsas de horas". It simply means that our customers purchase a prepaid block of consultant time that they can use on demand. We've found different translations, but none of them is entirely satisfactory: on-demand service management, support packs, prepaid time blocks. They all capture a fraction of what "bolsas de horas" mean to us. What do you think? What would you call this type of offering? Let us know in the comments of this post!
Leo: The idea is simple. We use support packs to give our customers a flexible work framework. Customers pay in advance a number of hours of consultant time that they can use as they wish for a full year, and we’re often doing complex and highly technical consultancy work: we may take on an audit, a migration, or an update.
Some blocks are small (25 hours), others can be quite large (up to 400 hours).
Before we started using Projectrak, 1 full-time staff could support a maximum of 25 customers. Now she runs over 100 on-demand customers on just 10% of her time.
L: This is how we do on-demand service management: We want to provide Atlassian solutions of the highest quality and understand that our customers need us to respond promptly.
The basic notion is that customers have many unknowns in their Atlassian journey, and we want to support that process by taking one thing at a time without dictating our own agenda.
L: The main challenge of keeping so many open tabs is that you still need to manage and control each customer. That control needs to be centralized in a single location: You need to know how long ago you last interacted with them, how much time they can still use, and who the Point of Contact is. That information should be searchable and dynamic.
If you run it manually, you’ll either need a large workforce or make many mistakes, which will hurt the business.
Information about customers should be centralized, searchable, and dynamic. If you run it manually, mistakes will hurt the business.
L: Precisely. Then you still need to look at aggregate data to make decisions. For example, you should always keep the ratio between your capacity and total outstanding demand below a certain threshold.
L: There’s only so much you can do manually. Before we started using Projectrak, 1 full-time staff could support a maximum of 25 customers; it’s almost a natural limit. But eventually, you want to scale, so you need to automate and be as efficient as possible. Since now the info in our Jira is always complete and current, that same person is only putting 10% of her time into supporting the process --and we’re serving over a hundred active on-demand customers with numerous consultants involved at different times.
The volume of data the coordinator manages is so large that Projectrak has become critical as a central location with all the info globally and about every customer.
L: Again, we reached a tipping point where we realized that we needed to eliminate errors and design an immediate mechanism to know the status of each project.
We decided to power up Jira with Projectrak to store more information at the project level, and we created one project for each on-demand customer.
A snapshot of an example of Projectrak 7 (formerly Profields) where it shows imaginary companies and their corresponding support packs
Projects are completely standardized: only one Projectrak layout is associated with all of them, indicating what info we need to capture.
The layout that Deiser uses to run each block of prepaid time for an on-demand customer
When we create the project, we fill in some of the data, namely the size of the block, the Point of Contact on both sides and the expiration date.
But then the entire process is automated: as our consultants solve tickets linked to the projects, the remaining time diminishes. And once we hit the expiration date, the project is tagged as expired.
We have been able to shift around the conversation and create a more proactive relationship with customers: our efforts go into the top-notch execution they expect.
L: We have eliminated interactions that don’t add value. Customers can access our Jira and see outstanding time, what tickets are linked, or when we delivered the last work item. We only communicate with them to negotiate renewals and extensions and, of course, to talk about the actual work.
L: Projectrak notifications were a big change for us. Our team gets notified whenever a project is modified manually. There might have been an extension, a cancellation, or a change in the contact person. I can’t exaggerate how important notifications are for us.
Plus, I’m subscribed to a weekly summary of all our on-demand projects. That allows me to have a quick visual of every active customer and to spot if there are any.
L: I’d say that the business benefits are really crystal clear if you’re dealing with flexible time consumption from your customers like we do. Generally speaking, we put very little time into administration, and all our effort goes into the top-notch execution our customers are expecting from us.
First, you can decrease your response time without increasing your team. We’ve seen that the time devoted to administrating customer relationships is only a tiny fraction of what it used to be.
We also save a lot of time in meetings that we no longer need to hold. Instead, I have the summary report, and I can ask around if I see anything suspicious.
But perhaps the most important aspect of a smooth execution is that we can shift the approach and have a more proactive relationship with customers. Since the service is running in the background, we only spend time creating value. In my case, that means focusing more on new opportunities; for the coordinator, it means approaching existing customers strategically and helping them make the most of their time block, for example, negotiating a renewal or discussing possible scopes for pending hours.
L: That’s true. When you think of ProjectrakProjectrak, you usually think of corporations that need to catalog their applications and processes… but as a consultancy shop, you can generate enormous value with relatively little effort.
L: Hah! I wish I had a bullet-proof answer to that. Sometimes, there are grey areas, but we typically recommend it in two ideal situations.
Some customers are looking for advanced support. We’re talking hard, behind-the-curtains work that an Admin with even a few years of experience can’t solve. They already know they need help making certain adjustments, and they expect this kind of relationship to speed things up and avoid mistakes.
The other situation is when a customer doesn’t know exactly what to do with the tools. We do an initial training and set-up, but we know they will discover requirements and will need help as they go.