Video Transcription
Welcome, everyone.
Thanks for joining. We'll get started in a couple minutes or so. Just gonna let a few more people join in.
Welcome in, everyone.
Thanks for joining everyone. We'll wait just another minute or so more. Just a few more people hopping on.
Thanks so much for joining, everyone. We're just gonna wait about one more minute. Just let these last people come on in.
Hey, Taylor. I think that we can probably get started here. Awesome. Thank you so much for joining, everybody. Thank you for taking some time out of your day to hop on this webinar. Today, we're going to be chatting about what strategic finance teams get right when it comes to driver based planning.
So next slide, Taylor. Just a couple of housekeeping items for everyone to be aware of. There will be live q and a, at the end of this webinar. So we're going to reserve around fifteen minutes at the end of the talk to answer any and all questions that you might have.
So feel free to use that q and a button at the bottom of the Zoom screen, and then we will get to your questions right at the end of this webinar. As a reminder, the recording and slides are going to be sent out shortly at the conclusion of the webinar, so stay on the lookout for an email from me, and I'll be sending, these resources over at the end of our conversation. Lastly, before planning season kicks off, we wanted to let everyone know that Cube is opening their doors for an event that we're calling f p ned AM New York. It's a morning meetup with New York City based finance leaders and Cube enthusiasts.
There's going to be a coffee tasting from New York City's own Libra Coffee experience. We'll have office hours and live demos as well as provide a space and time to network with local cube users and strategic finance professionals. So this event will be hosted on Wednesday, August twentieth from eight thirty to ten thirty AM. Don't worry.
I'll be sending out more information in our follow-up email. However, we know some of you on this call are from the greater New York and New Jersey area and or may have colleagues in the city. So we just wanted to extend an invite to everyone here as well. Please feel free to sign up and stop by when you get the email.
Again, more info will be provided, in that follow-up that I'll be sending out.
Next slide, Taylor.
So our speaker today is none other than Taylor Josephs. Taylor is our senior product marketing manager, and she has been with Cube for about three years. She was formerly a solutions architect and now on the product marketing team. She has years of experience as an FP and A consultant implementing other tools like OneStream, Essbase, and Adaptive, and she will be leading our conversations today. So without further ado, Taylor, please take it away.
Awesome. Thanks so much, Jasmine, for that introduction, and thanks everybody for joining today's webinar.
This webinar will be for the next forty five minutes or so. We're gonna reserve about the last fifteen minutes or so for q and a. We do also have a fifteen minute buffer after that for anybody who wants to hang out and ask more questions, but looking forward to spending the next forty five minutes with you all.
Our agenda for today is as follows. We're gonna kick things off with just a brief introduction to what we mean by driver based planning.
We'll give a brief overview on what driver based planning is, what the common challenges are with it, and what some potential solutions could be to solve those challenges.
Then we'll dig deep into one specific cube solution, which is our driver based planning tables. I'll also give some live demos of those tables in action in three specific use cases, headcount planning, CapEx modeling, and pipeline planning.
I'll briefly recap what we covered, and then again we'll leave that fifteen minutes for the q and a at the end.
So jumping right into it, what is driver based planning? Driver based planning is really the concept of building your budgets, your forecasts, and your plans around key assumptions, drivers, and metrics within your business versus the traditional kind of line item bottoms up approach of building your plans.
And so some of those key drivers could be, you know, a multitude of things, but some examples are revenue, revenue per customer, headcount, maybe utilization rates. It really could be anything that's incorporated into your models.
And the idea here is that all of those metrics and drivers are going to influence financial outcomes and what if scenarios that you can compare against.
Now who's typically involved in driver based planning? First and foremost, FP and A or finance teams are heavily involved in building the models for driver based planning and maintaining those models, updating them over time.
But also department heads also play a key role here, especially when we think about something like driver based headcount planning. You know, each department head is going to have to provide their metrics and their assumptions around who they're going to hire the, you know, next quarter, next year, who they're giving raises to, etcetera. And they may contribute to other models like maybe sales forecasting.
And executive leadership also plays a critical role here in sort of setting strategic targets for the business and ultimately reviewing the performance of those key drivers.
And lastly, why is driver based planning really important? Firstly, it can help enhance the accuracy of your forecast and your plans when you're building those off of true business mechanics and key metrics versus just, you know, manual plug ins, manual, you know, assumptions around your data and inputs.
Additionally, driver based planning also becomes much more agile and empowers more rapid scenario modeling and and what if use cases when you can assign drivers to specific plans and scenarios.
And lastly, driver based planning also provides a lot more transparency into how you actually got to your numbers.
You know, if the board or a c suite member asks you, you know, why is our budget off by x percentage? You'll actually have true defensible metrics to provide them with when you're building up your plans with drivers and assumptions.
Now what are some common challenges with driver based planning? I've kind of categorized these into some of the key functions that finance and FP and A teams perform. So starting with data management.
What becomes really difficult when you're trying to apply drivers to your forecast and plans is that you're gonna be managing lots of formulas that could potentially be prone to errors, especially if there's lots of users that are collaborating on those plans. Know, it's really easy to wipe out a formula and a spreadsheet, and it's also really easy for all those department heads to potentially calculate things in different inconsistent ways.
Additionally, storing your assumptions in static spreadsheets is also quite risky as well because you always have to make sure you're working off of those most recent versions of those spreadsheets, and there's no true source of truth to systematize those assumptions or key drivers.
And as mentioned, there's that huge lack of security without a solution. When everyone's planning in static models, they could easily access data that they shouldn't be privy to.
Now when it comes to reporting, driver based planning is also kind of risky when you don't have a solution consolidating your data because ultimately to get those key metrics and assumptions into your models, you would have to perform lots of manual exports out of something like an employee roster. You'd have to make sure that that data is all aligned perfectly in your spreadsheets before building out your plan, and this is ultimately really time consuming and error prone as well.
Consolidating all of the financial outputs and results from your driver based plans can also be very time consuming in static spreadsheet models because there's no true system to allow you to quickly digest that and slice and dice that data easily.
It's also difficult to drill into the assumptions and the details that made up your financial outcomes when you're performing everything outside of a solution like Qube because you'll have to ultimately go back to source spreadsheets that are maintaining your drivers, and it can be really tricky to understand which is the right one.
And for reporting as well, this can also just lead to inaccurate outcomes When you have all those error prone formulas, all of the risky manual consolidations, your outputs might be off by a bit if you're not accessing the correct data or applying those formulas correctly.
And lastly, when it comes to actually building those plans and building those driver based models, there's a huge risk in different departments performing these processes inconsistently because if they're all working off of offline spreadsheets, there's no true visibility or consistency in what everybody is doing.
And lastly, maintaining separate scenarios as well is very challenging without a solution like Qube because each time you want to build up something like maybe a what if scenario, a budget v two, a reforecast, Those would all have to be saved down as separate spreadsheets or workbooks, and ultimately consolidating those together to perform variance analysis down the line becomes very challenging.
Now what are some key solutions to solve those challenges?
From a data management perspective, a solution like Qube can really allow better automated data syncs into one central source of truth. Rather than having to manually export drivers like your employee roster or your opportunities out of Salesforce, Qube can ingest that data automatically and allow for immediate retrieval of that data in your spreadsheets as we'll see later on in today's demonstrations.
Additionally, systems like Qube can also solve for that formula component because you can plug in your consistent logic and your formulas into our platform, making that process of applying that logic more consistent and repeatable across the board. You can host any of your assumptions and metrics in Cube in the same way as well.
And lastly, applying that security per user who's accessing your data is also really key here. You can segment off, you know, which department leader has access to what data. If I want to invite Jasmine to my Cube as the head of marketing maybe, I can just give her access to the marketing department's data and ensure that she's not gonna wipe out the sales forecast for next year.
In terms of reporting, a system like QUBE can also help solve for that consolidation component. Our platform is designed to automatically compile data across different departments, entities, accounts so that you can report more quickly on those financial impacts of any of your driver based plans and assumptions. And this is ultimately gonna make your reports much more accurate When you have a solution performing all of that consolidation work for you, there's no risk of accidentally missing a SUMIF or a VLOOKUP formula somewhere.
And that reporting piece is also much improved by solutions like Qube via our drill down functionality.
Whenever you're looking at a consolidated model or report and you want to understand how that number got there, Qube gives you instant access to those details via drill downs.
And lastly, in terms of planning, Qube makes it much easier to set more standardized templates, whether you're using our spreadsheet applications to do so or you're working within our Qube workspace. Our solution will provide much more consistency around that process and give you more audit visibility into which department heads are changing what slice of data.
And finally, you'll also see today in our demonstrations that the scenarios concept is really critical when it comes to driver based planning because Qube is going to allow you to store those financial outputs and store those assumptions and metrics for specific scenarios like an initial budget pass, a budget v two, or any what if use case you want to build.
Now to dial in a bit on one specific solution that Kube offers, we're really gonna dig deep into Kube's dynamic planning tables today. Now our dynamic planning tables allow our customers to store, collect, and refresh any type of data and apply that data to their driver based plans.
Now this data does not have to just be financial information. This can also be text based assumptions and key metrics as well, such as an employee's name, an opportunity name, maybe an employee's start date, or an asset you're thinking about purchasing.
The ability to consolidate and store that data in one model allows you to then refresh and update that data, and these cube tables are also going to allow you to assign those assumptions to specific scenarios.
So if I want to apply a list of five hundred opportunities to one version of my forecast and maybe I'm adding, five more opportunities that we might close to a reforecast, I can do that with Qube without having to maintain a bunch of separate spreadsheets or workbooks.
Additionally, this will also allow you to apply filtered views for key stakeholders or budget owners that are gonna be working with your data. So, again, I could limit Jasmine's access just to the marketing department when she's refreshing maybe her employee roster.
And, additionally, this gives you the power to start toggling between scenarios more easily for driver based planning so that if you want to see what your last version of your forecast looks like, you're not gonna have to open up a previously saved version of a template again.
But moving into the more exciting part of today's webinar, let's start seeing this in action and applying this to specific use cases starting with headcount planning. So I'm gonna go ahead and open up a spreadsheet here.
And this spreadsheet that I'm opening up right now is pretty commonly used by a lot of industries. This is a headcount planning model here, which many organizations are performing in similar ways as, you know, headcount expenses, personnel expenses make up the majority of any company's operating expenses.
Now what you're gonna see here in these first few columns is a list of key metrics that are pertinent to something like an employee roster.
We can see things like employee IDs, employee names, hire dates, dates that they might have left. Other key metrics like their salaries, their bonuses are all listed out here. And if I scroll out to the right, you're gonna see where I'm actually starting to build out my budget for the next year.
I'm going to start applying those assumptions and metrics to my projected salary expenses or potentially to my taxes, maybe bonuses or benefits.
Now without Cube, in order to get all of this employee level information, I would have had to manually export an employee roster from my HRIS. Maybe it's ADP. Maybe it's Bamboo. And then I would have to massage that data in this spreadsheet, get it into the proper format, and start manually applying that to my budget.
But since I have access to Qube's dynamic data tables, what I can do here is in my Qube sidebar, simply fetch down that table of data.
Cube is now going to collect all of my employee level details that were applied to my budget for twenty twenty six. It's gonna drop in all of that information regardless of whether it's financial information or text based information like employee titles.
And then when I start scrolling out to the right, you're gonna see that that information is helping me build up my budget for that next year.
Now we have assigned this, information to an existing budget already. This was our initial kind of first pass at our budget.
But today, what I wanna do is plan for hiring a chief marketing officer in this next budget cycle.
So in order to do that, I'm just gonna go into my driver based planning model. I'm gonna go ahead and insert a new row into this template here in this marketing section. This could be really anywhere in the spreadsheet, though. And just in the interest of time today, I'm gonna copy this employee's details from the row below, but, of course, I wanna change a few of these key assumptions.
We're gonna say that this employee will get hired on the first of February of next year. We're gonna flag them as a new hire. We're gonna update that employee ID. We don't know who we're gonna hire yet, so we'll say TBD for now. And then for their title, we'll say CMO, and we'll give them that nice exact level salary here out to the right and give them a bonus of ten percent.
And now when I start scrolling out to the right, you'll see that this newly added hire is now baked into my budget model for this next year. Their salary is starting in February. All of these other metrics and assumptions are calculating appropriately as well.
And now in order to actually see the outcome of this and see the financial impact, what I wanna do is first assign this updated data to a second pass at my budget.
So what I'm gonna do is pick my budget v two here. We're gonna update that budget v two's data table so that now this CMO is part of that roster for this second copy of my budget.
And now what I'm gonna do is actually publish that data into that budget v two. So we can see here that I've selected that as my current plan. This data is now getting populated into that scenario within Q. And now if I were to decide to go to a consolidated report view that analyzes the difference between my first budget and that updated budget, I don't have to use a bunch of VLOOKUPs to compile that data from my employee roster or from that headcount planning template. I can use the power of Cube to simply fetch my data, and Cube is gonna show me that I now have about a two hundred k variance between my two budgets as a result of hiring that CMO.
So the financial impacts of tweaking a driver or a metric or an assumption are immediately retrieved via Cube, and that's all because we have those dynamic tables storing our data for us and that power of queue hosted scenarios collecting the data in the cloud.
And what I really wanna show here too is that if I wanted to revert those changes for whatever reason, maybe I want to go back and just reapply the original budget into that copy, I can scroll down here and pick that original budget as my scenario. I can fetch down the data table that's associated with that budget, and you're gonna see that CMO line just disappeared. So we're back to that original set of data. I could go ahead and update the data for my budget v two with wiping out that added row, and now we're gonna have those two scenarios in sync again.
Now what I wanna show everybody next is how I actually got here and how I built up this template in the first place.
So what I'm gonna do here is just add a copy of this head count planning template into this workbook. We're just gonna add it right after that original version.
And right now, this template isn't yet connected to Qube. This is just a spreadsheet driven model.
What I wanna do first, though, is connect this to Cube by setting up my Cube range. So we're just gonna close out of the sidebar for now. We're gonna select starting where I have my Cube dimensions and scroll all the way out to the right wherever I have all my data.
And we're gonna go ahead and scroll down to make sure that we're capturing each and every row of our employees that we have built out a plan for.
And now we're gonna go ahead and reopen that Qube sidebar so that we can start accessing that Qube database and connecting all this information to the Qube cloud.
We're gonna make sure that I'm in the right cube first, of course. I'm a member of fifty different cubes here as a member of the the cube team, but you, of course, would likely only have one cube in your case.
And now what I'm gonna do is select that range to essentially activate this model and get it connected to that cube system.
Now what I wanna do is make sure that I can ultimately drill into the underlying details that are making up all of my plans. So I'm gonna go ahead and highlight things like my employee IDs, employee names, and titles, and this is gonna give me that drill down access to that information later on, which we'll demonstrate in a minute.
And then finally, if I wanna make sure that this employee roster is refreshable over time and that I can start actually assigning this data to different scenarios, what I'm gonna do is highlight my table area of this template.
We're gonna go ahead and scroll all the way down here. We're gonna collect all of that employee level information, and we're gonna go ahead and create that dynamic data table. We can name that whatever we want. I'll call this employee roster August budget take one, whatever you wanna name it, and we'll select that range.
This is now a queue hosted data table. We can apply all those assumptions to specific scenarios like our budgets. We can set permissions on this to make this either private or available to all users or just specific groups. And then we're just gonna go ahead and create that data table.
Now that this data table has been created, this is now an activated model linked back to Qube. If I wipe out a section of this data here, I'm gonna be able to refresh that information and collect that data back again and see how that applies to my budget.
Now lastly, I mentioned that we would take a peek at drilling into those underlying details. So as I was starting to push information into queue, we were updating employee headcount, updating information related to our budgets. We can also analyze reports that look at our salary details, our payroll taxes, and other information here.
And if we wanna get a deeper insight into what's making up our headcount for the year, the month, or the quarter, we can navigate to the Qube sidebar and drill down into that data.
This is going to open up a detailed view for us of all of that employee level information, giving us not only the account, the department name, and all of our cube dimensionality, but we're also gonna be able to retrieve information like employee salaries, four zero one k, employee titles, and benefits.
And now we can start to filter this. If we were investigating a variance, I could filter on the marketing department. Maybe I wanna filter just on, you know, one month at a time, like February, and I could see any newly added hires or raises that I've given people that I wanna analyze.
So that's the headcount planning use case when it comes to driver based planning. Again, the big concepts here is that Qube is making it easier to collect and refresh important assumptions like your employee roster.
It enables you to apply that data right into a budget or to a forecast and then analyze the impacts later on.
Now we're gonna quickly run through some other use cases here as well now that we've kinda set the foundation for what tables are doing and what driver based planning looks like within Qube. So moving into this next use case, we're gonna take a peek at something like CapEx planning.
Now this model that I've set up here is assigned to the engineering department for the twenty twenty six budget again, and this department has a few key items that they're planning on purchasing. They've already budgeted for some software that they're gonna purchase, laptops, leasehold improvements, more software.
And all of these assumptions and metrics that you see here, like the category, the useful life, the, you know, priority of the item, these are also stored in a CapEx details table as well and assigned to specific budget versions.
And as we start scrolling out to the right, you're gonna see that that data is informing our budgeted depreciation expenses as well as our budgeted accounts payable. We could have, you know, fifty other accounts being impacted here as well if we want to.
But to show an example of this here, what I'm gonna do is plan for a new asset that we're planning on purchasing that's maybe a medium priority asset.
Maybe we're gonna be building out a lounge in our office. So we'll call this office lounge. And we have to purchase some furniture for that lounge, so we're gonna go ahead and select office furniture.
I've added in some logic to my model to auto populate that useful life based on that category.
And now I can decide when I'm gonna purchase that. Let's say we're gonna buy this in May of twenty twenty six. The purchase price of this furniture is five thousand dollars, and we're gonna be purchasing three items.
As we start to scroll out to the right, you'll see that this row where I added in that office furniture is auto populating for those depreciation expenses and for that accounts payable in May.
And now I can make sure to update that data in my budget version two. We're gonna hit update. My budget v two is storing that added assumption here. I just wanna make sure that we're refreshing that. And now we can publish that output back into When we publish that data back into Qube, our budget v two will now be impacted at the depreciation expense account and that accounts payable so that we can go back to a report like this that's analyzing those two accounts. We'll make sure that we're picking the month of May so that we can actually see that accounts payable get applied.
And now when I go ahead and refresh this report, you're gonna see that we'll have a variance between our original budget and our budget v two as a result.
So, again, these driver based planning solutions that Qube offers can really be applied to any use case, whether it's something like headcount planning, CapEx modeling, or pipeline planning, as we'll see here in a moment.
So last use case that I'll pull up here is gonna be in a different model.
And this is going to be applicable to maybe any SaaS companies that are on the webinar today, maybe anybody who's forecasting sales or has, you know, a large sales team that's often collecting and updating data across their CRMs like Salesforce.
And as I'm sure many of you know, it can often be really tricky to gather that updated information when you have a team of twenty sales reps that are updating data every single week. If you have to manually export that data out of your CRM and push it into your models, there's a huge risk of that data being out of date or incorrect or misaligned in your templates.
But, again, with Qube, we have the capability to apply any opportunity level details like account names, project start and end dates, the source of the deals to those dynamic tables, and we can now immediately refresh that information in our spreadsheets. I'm gonna go ahead and fetch my data table here that's gonna populate a list of all of my outstanding opportunities, when those opportunities might close, the start and end dates, all of that other great information we're collecting from our CRM, like stage of deals. And as I start scrolling out to the right, you're gonna see that I'm applying all of those assumptions to a quarterly reforecast scenario.
So this is all of my projected sales. This is kind of a twelve month rolling forecast starting in the month of August this year going out to July of next year.
And, again, if I wanna now change one of these drivers or metrics, I can easily do so within this spreadsheet and update my models accordingly.
Let's say that this Monsters Inc. Deal is actually gonna move out a few months. The AE isn't expecting to close that in September anymore. They're thinking this will likely close in maybe January of next year. So we're gonna go ahead and input that date for the close date. Of course, we need to push out that project start date as well. So maybe the project will start in February of next year, and the project end date is going to conclude in maybe, April of next year.
So now that we've made those changes here, you're going to see that that deal is being pushed out in our forecast. So we're not gonna see any revenue until that project has actually started in February.
And now we can go ahead and sync that data into that reforecast template if we want to. So we're gonna first update that data table to our quarterly reforecast. We're gonna also go ahead and publish that result back to that scenario as well.
And now if we go into any variance analysis reports that are looking at comparisons of our initial quarter three forecast and that reforecast scenario, we're gonna be able to refetch that data. And I believe Betty Suarez was the sales rep who had that deal, and she now has about a seven thousand dollar variance between the projected sales that she's expecting in that forecast.
And, again, if we ever need to go back to that dataset that we had for that original forecast, we can always pick that here. So we're gonna select our q three forecast. We're gonna fetch out that data table, and we're gonna see that those numbers have reverted back to those original start and end dates, keeping that information preserved in one specific scenario.
So we've covered a lot of different use cases today, so I wanna make sure we do a bit of a recap here before we start diving into questions. So flipping back to these, slides here, we're gonna go ahead and walk through kind of what I, walked through today in this webinar.
So, firstly, the really important solution that Cube offers here is the ability to store your assumptions, your metrics, and your drivers that are informing your budgets and forecasts into one source of truth. And those are gonna be stored in those Qube tables. Those Qube tables and those details within them can be assigned to specific scenarios, whether you're just establishing your historical actuals in one scenario or maybe you're spinning up multiple copies of your budgets or your forecasts. Qube is going to keep all of that data aligned to those specific plans.
Then you can start incorporating those details into your model logic. So if we're pulling, you know, a project start date into our projected sales or an expected hire into our forecasted expenses for personnel, that's how you're gonna kind of configure that within your spreadsheet models.
And then you can push those financial outcomes back into Qube using that spreadsheet sidebar, and that is going to ultimately enable Qube to start collecting those results and give you better, more accurate reports that can digest variances between different scenarios.
And finally, you'll have that capability to now immediately drill into the details that are making up any of those numbers in your forecast, your budgets, and your plans, which ultimately is going to save teams tons of time and give you more transparent answers anytime c suite members or board members are asking questions about your data.
So I hope this was a really helpful overview of what driver based planning looks like within Qube, just to cover again some of the resources that we'll be sharing after today's webinar. As Jasmine mentioned, we're gonna be sharing the recording of today's session as well as the slides that I have here, and we'll be sending those out to the full group who attended today.
That FP and AM New York event is also coming up as well, so we'll pass along some information about how to sign up for that and what that looks like.
And then finally, for any prospects who are on the call today, we can also share a link as well to book a more custom demo with us if you want to dive deeper into something like tables, driver based planning, or something else within Cube.
So thank you everybody for your time today. I think we will move into some q and a next.
Yeah. Absolutely. Okay. Let's get started. It looks like we've got a variety of questions, including a question on our music choice. It was really good. So Taylor was the DJ for that.
Maybe we need some playlist recommendations, Taylor, in the next in the next webinar.
Looks like we've also got a couple of questions on templates.
Things like, are these templates that you've been working on in this demo provided by Cube? Does Cube provide these templates? Are they available for use? Basically, the same ones you're showing in this demo.
Yeah. That's a great question. So we do have a ton of downloadable templates available on our website as well.
Additionally, if you like what you saw today and you want to start incorporating that into your own financial planning models, we are happy to share the exact templates that I had today as well if you want to repurpose those. And if you are a Qube customer, I would also really recommend reaching out to your account manager because they can really help you get set up with some of these templates and help you apply it to your specific business.
Awesome. Okay. Looks like we've got another one. Is there an audit trail for who tweaked the headcount budget and why?
Yes. Yeah. Really great question. There absolutely is an audit trail. I can have actually just pop that open right now. I've got my queue model up and ready.
You know, the audit trail is gonna be in the queue workspace here, but you can get to it from the spreadsheet models that you're working in as well. But that audit trail is going to display tons of great information for you. You can see the date and time that somebody made a change. You'll see the team member's name. It says Qube staff for me, but you would actually see all of your individual team members in your case. And then if you click into the view changes section here, you're also gonna get more information as well, like which values were impacted by that publish, which dimensions were impacted by that change.
You can see, you know, even the specific spreadsheet that somebody was on. If they were working in Google Sheets, this URL would actually be a clickable link as well.
And that user can also add a change message anytime they're pushing in data too, so that can really get to the why behind the changes that they made.
Thanks, Taylor. Another question. Can you do CapEx planning based on project dates that are plan year agnostic? Something like building construction that lasts multiple years.
Yeah. That is a really great question. Yes. You absolutely can.
The idea behind that would be you would just bake in those assumptions into that CapEx model. So like what I have in my model, such as purchase month, you would have maybe project start date. And that could be regardless of year, regardless of time period. If you wanted to say, you know, just starts in q three, for example, you would just configure your templates to incorporate that logic correctly.
And something I wanna mention too is that all of the planning work that I've been showing today has really been heavily focused in our spreadsheet applications, but this can also be done in the Qube workspace as well.
So if you have users from maybe the sales or the marketing department who really prefer not to be in Excel or in Google Sheets, you can just set up specific workflows for them in Cube, and they can do all of their planning work and their reporting work there as well.
Awesome. Okay. Another question. In the example of the pipeline forecast, they're wondering where the data originally came from. Was the data table first, manually assembled into that format and then uploaded into Cube? In the demo, lot of people are seeing that it was already available in Cube as a fetch. So they're asking, did the demo skip the initial step of building the original table?
Yeah. That's a good question. And, yeah, not something that we had time to dig too deep into today, but to give you an explanation, there's a few ways that you can populate these data tables. The first way would just be, you know, exporting the opportunities details from your CRM, like Salesforce maybe, dropping it into a spreadsheet. It can be in any format as well. There isn't a specific structure to these tables. So as long as it's, you know, something like a column based structure, you can easily set that up as a table and assign that to scenarios.
Or what you can also do is set up an automated data sync from your CRM to a Cube data table. So just like Cube is able to sync with something like NetSuite to load in your historical actuals, we can also sync with other data sources as well and push those two tables specifically. And that way, you would just open up your spreadsheets, you'd hit fetch, the data would automatically be there, and there would be no manual, you know, dropping of data into the templates.
Thanks, Taylor. Another question. In the third example related to sales planning, is the variance reporting only available based on set dimensions, or can it actually be done by attributes as well?
Yeah. That's a good question. So when it comes to reporting and variance reporting, this is typically going to be constructed around your cube dimensions.
Because when we're constructing reports in cube, we're selecting ranges of dimensions in the rows and in the columns, and that's what Kube is going to be designed to fetch. However, if you do want to investigate those attribute level details, those granular assumptions, you can easily click into any cell on that Kube connected report and drill down into that. And this is going to pull up all of that granular data, like, in my case, project start dates, you know, close dates, opportunity names, and whatnot.
Something to call out as well is that we also have AI powered variance analysis available in the Cube workspace.
So you can easily say, you know, pull my budget and my budget v two or forecast and reforecast, filter by x department, and Cube is going to generate results and visualizations for you and give you prompted responses and explanations as to why you might have variances in certain areas.
So that is going to be a complete digestion of all of your cube data as well, incorporating attribute level metrics, all of the roll up data as well. So that can also be a really quick way to perform any variance analysis.
Awesome. Kind of in the same thread of thinking. Are the values in the cells for the dynamic data table still being calculated via Excel formulas?
That's a good question. They can be. They don't have to be, though. But if I did have, you know, a specific assumption, I don't think I have any in this model here, but maybe in the CapEx model, I do.
If I had an assumption, like, you know, I wanna populate this useful life column based off of whatever category I've selected, you can set up Excel driven functions to do that, and those can be applied to those cube tables. You don't have to just have a static number that you're applying or a static, you know, text based field.
Something that I want to mention as well that is on our product team's road map is the ability to program those types of calculations, maybe dimension based formulas into the back end of Qube so that you don't necessarily have to do any logic in Excel. You could have all of that preprogrammed in the system. And then within Qube, you're simply retrieving the outputs and the results, and you're only working with that kind of condensed data. So that's something that is on the product road map to really help with driver based planning and any other use case that uses more, you know, comprehensive or complex logic.
Very cool. Can you actually revert to a previous version of a budget kind of like an undo function on a data publish?
Yeah. So that's also something our product team is working on is the ability to just click a button in the sidebar and say, undo publish, and it would just wipe back to the original version.
But an easy way to do that as well is simply fetching out your data from that prior version. So if I have this data table with that extra item that I applied to my budget v two, but I wanna revert back to that original budget, I can fetch that data table and that row is going to get wiped out. And then I could republish over my budget v two to essentially reset the data and unwind those changes that I've made before.
Awesome. In regards to assumptions, folks are wondering where in Cube the assumptions are saved.
Yeah. So for assumptions, they can either just be stored in Cube data tables if you are really just applying them to that one use case and you don't have a need to, let's say, design an OpEx variance report that says, you know, the difference between my purchase price of all CapEx items, for example.
However, you can also go into Cube and store assumptions as dimensions or metrics in our system as well. So one example that I have here is if I go into my Cube model, we'll go to my cube dimensions. We'll go to my accounts. I've got, you know, typical financial accounts like my income statement here, my balance sheet, but I also have some other assumptions down below that pertain to other more operational use cases.
So, for example, I have assumptions around my FTEs, and these assumptions can be filtered by my actual FTEs, my budgeted headcount, my forecasted headcount. I can have metrics like my, you know, projected bookings, my customer count.
So as long as it's a value based data point, you can store assumptions in cube as dimensions. When it's more text based free form data, that's where tables are really gonna come in handy.
Awesome. Another question for headcount budgeting. Does it use department level security? Kind of like in your example, the head of marketing can only see their marketing employees and not employees from, let's say, other departments.
Yeah. Excellent question. So, absolutely, any use case, whether it's headcount planning, you know, driver based pipeline planning, will have specific user based security assigned to it. And I can give you a brief snapshot into that here.
If we go to user management, this is where that security gets established, and it gets applied across any dataset in your cube. You can set specific user types in your cube, like admins, maybe department collaborators who are able to sync data back to Cube, department heads who maybe have a little bit more admin access to the system. And then for data access, you can also set specific data access groups as well. So, for example, if I want to add Jasmine to my Australian marketing team, I can assign her to that user group.
And if we open up that data access set, you're going to be able to see what that permission looks like. This is access to only the marketing department, not sales, not product, nothing else, access only to the Australian department. So if Jasmine goes into a model and tries to push data into the US entity or into the sales department, she'll get errors in the cube sidebar that says she can't do that, and she also won't be able to retrieve data for anything outside of this dimension slice.
Awesome. Thanks, Taylor. Looks like we don't have any more questions in the chat. So, I suppose it's a good time.
Oh, wait. We have one more. We have one more. To confirm, can one file be used by multiple people and only show data that each person has access to?
A thousand percent. Yeah. I would say the best way to handle that would be, you know, sharing out that singular file with everybody in your company with the data first blanked out. So I would, you know, just delete whatever's in my data table so that I don't have the full comprehensive data there.
I would share this with Jasmine, with ten other people in my organization. They would all open their Qube sidebar. And depending on their security access to Qube, when they click fetch table, they're gonna get different slices of data.
Jasmine would only see, you know, the first few marketing rows. Somebody else might get all of the sales rows, but they won't see any of the marketing rows. And they're all working off of the same template, but they're getting their specific lens and their view into the data applied.
Great question.
Thanks, Taylor. Okay. I understand that we're out of time, and I don't see any more last minute questions in the chat. But as always, like we said before, I'll be sending out this recording, the slides, other resources, as well as information on if you have any more questions about what you've seen today, or just wanna chat about your use case to somebody, I'll be sending out more information on where you can go for that.
And just wanted to thank everybody for taking time out of their day to watch this webinar. And, yeah, hope you all have an amazing day. Thank you so much for coming.
Thanks, everybody.
.png)
.png)
