Email Tracking

Vinnie Disalvo

0:00  I'm gonna jump out and then jump back in. I think I didn't…

Katy

0:05  Okay. Yeah, it had me admit you, so I don't know if I did something.

Vinnie Disalvo

0:08  No, no, it's me. I'm just not logged in. I'm gonna jump.

Mike

0:12  Out. Okay, cool.

Katy

0:13  Cool.

Katy

0:27  Good.

Jon

0:28  Morning, Katie.

Katy

0:29  Hey, good morning, John.

Vinnie Disalvo

0:34  All right. Good morning, everybody.

Katy

0:37  Morning.

Jon

0:38  Any getting hello again? Mike?

Hank

0:40  Good morning.

Vinnie Disalvo

0:45  Yeah. So, what happens, Katy is, if you're like I'm the owner of this particular meeting and because I wasn't logged into Zoom when I joined… it didn't recognize who I was, right? So, it just said, hey… you know, Katy, you joined first, you're the defacto host. So that's why I had to drop out and drop back in.

Katy

1:11  Makes sense.

Vinnie Disalvo

1:14  Hey, Sam. All right. Well, it looks like the gangs all here. Thank you, Mike for joining. I appreciate your time today. So, I know we had talked about sort of inviting you to the meeting this week just to kind of recap some of the, at a high level, some of the stuff from our Ko and then talk about kind of next steps and where we are with that process.

Support

Vinnie Disalvo

1:43  And then really just kinda… make sure everybody feels comfortable with kind of like where we're headed and, you know, if anybody has any specific thoughts, ideas concerns, right? In general, just give the team an opportunity to also provide feedback as well, you know, to me and you overall. So I don't know if you had a specific place you wanted to start or if you want to. Maybe.

Support ends

Mike

2:14  I can just sort of summarize where I think we are, you know, on the product side, the, I guess the leading I'll call it notion or maybe the intended practice for assessment of feature requests coming in through this team or really from any customer that went into our maintenance queue, right? We've had this maintenance queue set up in JIRA, and those requests, those tickets are reviewed weekly on Fridays. The intended practice for that was to put each item into one of two buckets either will do or won't do basically not really what they were called but it's basically the premise and, you know, observations that I've had is one that wasn't really happening. It wasn't happening with much consistency. The criteria by which tickets were being assessed was also sort of inconsistent and, you know, that say highly subject to influence or, yeah, it's just sort of subjective and that most of the things that were put in the will do weren't actually will do that. I think that there were more might does or sounds like a good idea, but without any kind of commitment behind it. So it doesn't make it a very useful classification. So, so I've talked with Jimmy and I've talked with the PMS on my team and we kinda landed on this three bucket structure. But with, you know, certain criteria around it. So… you know, it's what I'm calling, you know, planned which means that it's a will do… and it's committed like we, it's not just that we wanna do it but we're planning to do it and we're planning to do it comfortably within one to two quarters. So even if it's like the best idea in the world that we fall in love with and we definitely want to do it. But it's further out than that, we're not gonna put it in the planned category because it's just too far out and it's just too subject to change. The opposite end. Is the sort of the won't do that there's no plan to do this, which is a hard… I guess position to take on some things. But that's sorta the gut check of like is this strategically aligned with, you know, what our companies trying to achieve a, do we have the capability to do this? Are we ever going to prioritize? So this above other stuff that we've got going on. And if we can't say yes to all those things that it's gotta go in there. It doesn't mean it gets deleted, right? It doesn't get thrown in the trash, it's just not put into a bin… for active consideration. And then the middle in is… the MIT address which is really kind of like it is a good idea. It does align with what we wanna do strategically. We don't know when we're going to get to it. We don't know how it's ultimately going to get prioritized against other work streams in motion. But it is something that we believe is valuable. We understand the problem that the customer is expressing that we recognize the impact it has on them. And so we want to consider, we want to continue to consider it. And then when things go in that bucket that we commit to two things that we keep that bucket sort of at a specific size. So it remains manageable and that it is reviewed regularly. So, each quarter, you know, each quarter, our team will kind of say, all right, what's our thematic direction for the next 12 months, six months, three months. And each quarter we review that because we expect it to change each quarter potentially. And so that's the time when we come in and say, all right now, given our new thematic direction, is there anything in here that will support that fits well and that we can, you know, hopefully make some customers happy at the same time? So so that's the plan in terms of structure, the near term deliverables. And I'm happy to talk about them today. Is one is that we need to sort of back backwards, apply this structure to the tickets that are already in the queue which I believe they're just about 50 in there and they're from different sources and different. I guess Pete and Cody have different levels of familiarity on them. So we're gonna do that. Cody is back Monday and Tuesday. So I'm planning to get that review done next week if at all possible. I'm a little strapped to do it this week without him and just other stuff on the plate. But that recognize it sorta the first thing needs to happen. And then the other thing the companies that is the language messaging around that. So why this structure change? What does this mean for me? What does this mean for my ticket? And I think… it's not necessarily going to be on a ticket by ticket base, but it's probably it might be a client by client based on some of these, their higher profile higher. I guess activity kinds of tickets or higher visibility tickets. So that's those are the next two things on my plate for moving forward.

Vinnie Disalvo

7:39  And I think, Mike, just so you're aware and I mean, team, keep me honest here. I think there are… three, maybe four customers that come to mind that have more than one enhancement down there. Equitable. Well, yeah, equitable as one. Actually there, most of them are John's customers. You have equitable, you have aligns Bernstein, you have next era, and then you have new Burger on from Sam's perspective that have multiple. And then I guess we do have like ZipRecruiter is another one but that's like a whole separate like you're you, you're in TUNE with what's going on with ZipRecruiter right? Like, I don't know if we're classifying ZipRecruiter in the same way, right? Since they're you know… we're building out some specific models for them, right? Like as part of… the engagement, but again, right? You know, I'll leave that to you and Phil to kinda hash out like, are we doing this? Are we not doing this? You know, we told them we were, we told them we weren't right? Like it's part of the contract. It's not part of the contract, right? You guys can figure all that out kind of thing. But for the most part, I think, I mean, are there any others that have like a lot of enhancement requests? Just any other customers I'm missing?

Hank

9:12  Vinnie, I've I have one that has to enhancement requests, but they actually piggy back onto ones you just mentioned. So.

Vinnie Disalvo

9:20  Yeah.

Hank

9:21  Not isolated from the.

Vinnie Disalvo

9:25  And the only reason why I bring that up, Mike, is because I know that you and I have, you know, conceptually talked about this, right? Like the idea that a lot of the customer enhancement requests, for the most part, right? They are like let's say we have 50 of them, right? 22 of them, I'm gonna make that number up, right? Probably come from that small group that I just described, right? And so, and I just want to sort of put like voice to right what we're talking about. So, yeah. Well, you know, I don't think we want to get into the, you know, potentially into the, you know, having to respond to every single ticket. I think somebody's going to have to respond to every single ticket just because right? Where every ticket has a Salesforce case and we need to, if there won't do we're going to have to close those out, right? And we're going to have to provide some commentary to customers about that. But I do think it might be worth just because of the nature of how large those couple of customers that I just mentioned are. If there are things that fall into that, you know, certainly if they fall into the won't do category… that we may have to potentially have some specific conversations. Maybe, I mean, there might be, there might be a back and forth, right? I'm just sort of preparing the group for.

Mike

10:49  I would expect that some of those might be multiple touch points, right? Like it's like we've reclassified your thing and don't worry about it now, yeah.

Vinnie Disalvo

10:59  Yeah, yeah. Yeah. And it's just sort of preparing everyone for like, hey, when we tell this customer that this is just doesn't align with our current road map. And it's not something that we're gonna pick up or plan to pick up at any point, you know, a customer may ask well, you know, why and have some, you know, have some follow up questions and potentially push back, which is not gonna necessarily change the answer, right? But just providing some context for additional context for some of that stuff as a result the.

Mike

11:30  And I think that it also opens the door potentially for a, hey, maybe we're misunderstanding your problem like maybe.

Vinnie Disalvo

11:40  Sure.

Mike

11:41  Our interpretation of this is that it's significantly lower value than it might actually be. And, you know, we talked about sort of the criteria that we would use to assess these. The bottom line is that, you know, product management works at market level, right? Not customer level, not client by client. We have to work at market level. We have to look for commonalities, and, you know, solving problems in mass. So, it may be the case that for one particular client, they may have a unique problem that is solved or potentially solved, who knows, but potentially solved by the suggestion, the feature they're requesting and we may not understand it the way that they understand it, the way they feel it because it is unique to them.

Pricing

Mike

12:33  So, you know, it's I think there's an opportunity for kind of, you know, adding that in there, saying like, yeah, this is where this stands right now. But maybe we're misunderstanding it. Please help us make sure that we…

Vinnie Disalvo

12:46  100 percent. Yeah, I agree with you 100 percent. I think the only other question I was gonna have around any of this was.

Pricing ends

Vinnie Disalvo

12:58  And maybe you just answered it or maybe it's the same answer for this question. So what if a customer wants to engage around an enhancement requests and wants to put dollars to that? Is this, does the same model apply? Like, you know, if it's a one off, it, if it's a one off thing, we're still not gonna do it.

Pricing

Vinnie Disalvo

13:24  I don't care if the customer wants to pay us 100,000 dollars, right? Like it doesn't matter. We're just not gonna do it period. It has to be broadly applicable, you know, at the market level, for us to even consider engaging that it doesn't mean that we might not have a conversation to verify, right?

Pricing ends

Vinnie Disalvo

13:41  Like you just said that we understand the use case and the value and so on and so forth. But in general, right? It's not one of these situations where we're just not gonna do it for free anymore. But if you pay us, we will do it, right? It's more of a no, this is our new posture.

Pricing

Vinnie Disalvo

13:59  This is our new stand. This is how we're moving forward. We'll engage to make sure that, you know, we are aligned. But other than that, right there, there is no kind of pay to play scenario.

Mike

14:14  Well, so this is where I would say that then jumps to a new tier consideration, right?

Pricing ends

Mike

14:20  So the like the first pass of this would be the normal, you know, sort of product management lens that we talked about. And so the product team will make a classification decision. And then if it, you know, and I think what I just described to, if this is like a customer who's feeling a significant amount of pain for this even though they might say, yeah, we recognize that it's unique to us but it's really important to us. What other options do we have? I think that's when that opens the door to that conversation. And like the product engineering team wouldn't spearhead that conversation, like I think that, that's that needs to go through, you know, Cam and Phil really. And if there is going to be a diversion of resources that, you know, and it could, if it's 100,000 dollars, right? That's strategic, maybe that, that's very meaningful to the business that could come back to product and engineering and say, well, this needs to be prioritized up. But that would, I think that would need to happen there rather than, you know, like I can't put Pete and Cody in a position of judging dollar amounts, you know, like that's the product team just wouldn't do that.

Vinnie Disalvo

15:32  Sure. So, so, you know, and I guess that would be the, I think some clarity we need, right? As a team is if we're engaging, if the expectation is that this team is engaging in those conversations right around, you know, sort of business requirements gathering and speaking out and essentially, you know, put, you know, selling right? That we're identifying it as an opportunity to sell it. We probably need to… put some guardrails around that, right? Like because we don't like, I wouldn't want this team to just start offering that up, right? And just being like, hey, well, you know, if you want it money to.

Hank

16:18  Talks.

Vinnie Disalvo

16:19  Right? Like we don't want to have that kind of conversation for sure. And so, we need to put some guardrails around like, hey, what is this process look like? Right? If there, if a customer does come back and does push back hard enough, where we think that, you know, this requires some deeper investigation right here's, what that process looks like, right? Open a case, right? Create a case and, you know, on behalf of the customer or if the case already exists, right? Gather this information or set up a meeting and to discuss like we just need a process by which to sort of, you know, handle that unless we want to just handle those things kind of one off. And then we still need a process by which like just reach out in the whatever product slack channel, right? I don't know, I'm making that up but whatever it happens to be, just so that way, right? Because again, like I'm not 100 percent sure you may be aware of this, but like this team collectively manages half the revenue of the organization, right?

Mike

17:23  Yeah.

Vinnie Disalvo

17:25  So, so as a result, we wanna make sure that… we keep the risk to that revenue, right? As minimal as possible and make the, make it, make the processes as frictionless as possible. So, I don't want to create a scenario where like, and again, I'm just trying to think both ahead as well as reflect on my experience coming in, right? So, you know, what are the things that you might not be aware of? Mike? Is that like I took over this role from someone who's previously in this role? Some of these customers obviously have been around for quite some time. And over the last year and a half have had four or five main points of time contact. And every single time they've had that new point of contact, they've had to re, explain and repitch right their desire for these enhancements. And so, you know, when I know when I came in and I was like the third person, right? That they had to explain this to, you know, there was a level of frustration around, hey, I've already gone through this process like four times already or three, two other times already. And we've talked about this and I've I provided this information to this person. I've provided this information to this person. And so, you know… by delaying that conversation potentially if we need to, right, in order to, you know, figure out what the process needs to be, right? Like I just don't want to create more, you know, negative energy around that particular customer. So that's not to say that we don't need to put right these processes in place. I just want to be sort of mindful right? And very intentional about what should the process be for this team? Because right? This team's responsibility is to build right, cohesive collaborative relationships, right? And we don't wanna, we don't want this team to have to, you know, as much as we can avoid it, right? Damage those relationships. Because, right, we need to deliver this customer, right? You know, bad news that, you know, something that we have told them for the last three years, right? Is going to be something that is going to happen but just hold on, right? It's coming and again, like we may have to deliver that message that's fine, we will. And, you know, we'll do it with elegance and grace as we always do. But at the same time, you know, I just want to process in place. So that way we can, if we have to re, engage with the customer, right? They feel like we're to your point, re engaging at a higher level to really deeply understand and make sure that, hey, this is what this is what this is. So do you think it's just a, you know, slack message, a case by case basis or do we think we?

Mike

20:31  Or custom requests. Now, in fact, I would say specifically don't slack the product team for big ticket custom requests like they're like that. We should define a process for what that is like if, you know, if a request has come in through the regular process and it's been classified. And then the customer pushes back and says no, look, this is really important and I'm willing to throw some money at it. Then I think that is a separate process that doesn't go back to product. Okay? But we should yeah to your point that it needs to be clear and we need to define that. I, you know, I would just general sort of perspective. We don't really want to invite that stuff. I know that if there's a significant revenue opportunity tied to it, it's gonna be tempting and we'll want to have the conversation but just generally right, just remember that we're trying to build a market level and not client, you know, custom stuff. We do want to understand the problems that they're having, right? So because so like you know, equitable might request something and credential might request something and whoever else, and they might request different things, but they might actually have the same poor problem. Well, that's what product wants to understand. So we can solve for all of them. But even when these tickets come in, this is another change. I think it's probably worth pointing out what the product management team has been doing is just taking the ticket as it comes into JIRA, and using that as the work ticket to go through the rest of the development process to, you know, and what we'll start doing is rewriting those. So like that becomes that request becomes an artifact, becomes a supporting document for the ticket. But we're going to be, we're writing the ticket in terms of addressing a market problem. If that makes sense. So it may be tied to, right? New Burger is asking for this and there's a revenue amount, you know, applicable. But what we're building is a feature to solve a problem. And there a data point, right? So it'll stay connected. It'll stay attached but it's gonna be it's not going to be, it's not going to be worked against… from specifically from that one voice of customer. If that makes sense. It's got the product management it. I don't say filtering or interpretation, but it's like… the synthesis, right?

Vinnie Disalvo

22:57  Yeah. Yeah. And again, right? Like I think, you know what I would like, you know, I think we covered sort of the… stuff that's in the queue, right? Like that's going to get addressed and we'll have to wait, you know, well, you know, in a couple of weeks, we'll have sort of the output of that process from the product team and we'll talk about, you know, so maybe we'll get… another sort of longer form meeting on the books or maybe not. I don't know if I, to discuss this to discuss again the outputs for at least the customer facing the ones that the CSM owned accounts stuff. But then, you know, on a go forward basis, when the team has information, gets a recent custom, a customer or something comes in, you know, we are constantly, you know, iterating on how we intake that information, right? Like, so when something comes up like we learned at ro, about, you know, really diving into the, who, what, why, and… you know, when of it all and the importance of really understanding, you know, again the why specifically as well. I think from my perspective, one of the things that will be helpful is, are we going to continue the same process? So, so I'm just, I'm going to be very tactical here with the team, right? And just say, okay, you're on the phone with the customer says, hey, you know, as a result of something right there's, gonna be an insighting incident, right? Something that the customer is trying to do and can't do something they reported as a bug that was not a bug and it was expected behavior, right? Like, so there's gonna be an insiting incident, right? Whatever that insighting incident is regardless, right? Customer is gonna say, hey, Hank, I really wish that your product did X, right? So we're you know, we're gonna take that information be like, well, you know, thanks for telling us that. Help me understand why that's important to you? Who's affective, what's the user case, right? Gather as much information as we possibly can once we've done that first iteration of data collection, what's that, what's the next step in that process?

Mike

25:27  So, so when you do that, you're creating today, right? You're creating a JIRA ticket?

Vinnie Disalvo

25:32  Now, we're creating a Salesforce case.

Mike

25:34  Salesforce case?

Vinnie Disalvo

25:35  Yeah, we don't create jury tickets. Yeah, that's good.

Mike

25:38  Yeah.

Vinnie Disalvo

25:39  Yeah, no, no, no, we don't so typically, the way it works today, I apologize, I should have sort of explained that typically the way it works today. And I say typically because it could vary typically if it's depending on the scenario, if it's brand net new, it never has come up before we'll take that. We'll create the ticket. Either we, this team or Tyler, if Tyler sometimes is connected from a support perspective, he'll create the Salesforce ticket. And then what will happen is somebody in support will validate like that. We don't do this, we do this or what the problem, whatever the case might be.

Mike

26:21  Bare, right? It goes the per process?

Katy

26:24  Not neces.

Vinnie Disalvo

26:25  If it's an enhancement requests, not necessarily usually it'll just go to product review, right? Like it needs if somebody on the support side will create a JIRA ticket, right? If one is required, put all the information in and then it'll go to get, gets put into product review, okay? Right? In that bucket. And then usually, there's some back and forth that happens. But that's essentially the process, right? We get the information Salesforce case created. Then somebody else, you know, creates the actual JIRA ticket that then gets sent to product for review. And then, right? Like to your point, there's been about 100 different ways that has happened or things have happened from there. But I think, you know, moving forward, I mean, we're happy to continue that process, right? If we think that, okay, let's go ahead and just open a Salesforce case. So we have a place to document it because prior to documenting it there, we were documenting it in confluence and Microsoft excel and Google sheets. And, you know, I mean, you know, email in slack and, right? Like a 1,000 different places. And so that's why we sort of consolidated and said, no, everything is gonna go through Salesforce first, right? So, I'm happy to, you know, we're happy to sort of follow whatever process, you know, you guys all deem, you know, appropriate, but we just need to understand like, okay, what is that process? And I don't know if you've had an opportunity, feel free to say like we haven't really sort of discussed that. We're gonna, you know, we'll take that back. But if you have thought about it like we'd love to hear your comments on.

Mike

28:11  No, I guess so we've been focused on what happens once the items show up in the maintenance queue, right? The front end of that, I agree warrant some, you know, taking a look at that too, because the timeline around that I guess is what interests me if that is, you know, very quick or if it.

Katy

28:31  From, from…

Vinnie Disalvo

28:33  From, from customer to JIRA, ticket generally is a fairly quick process. Could be 24 to 72 hours sometimes.

Katy

28:43  Might take a little bit longer, but.

Vinnie Disalvo

28:44  Like within a week, let's say now that ticket, will, you know how long that sits in the waiting for review, right? That varies on, you know, amount of push that comes from the customer, if they, if in their request, they not only emailed us but they also emailed Phil and Jason and you and 100 other people, right? Like, you know, because this is something that is, you know, urgently needed, right? Sometimes those things get looked at quicker versus, hey, this is a request. Whenever you get a chance to look at it, you know, that's fine. Sometimes those things take a couple of weeks, months to get looked at.

Mike

29:25  So… out of bounds escalations or out of, you know, normal process escalations aside, what would happen is, so we, we'll do the reviews on Fridays every Friday. So, if a ticket comes into the maintenance queue on a Monday, it'll get reviewed Friday if it comes in on a Friday or in a, it will get reviewed Friday, right? If it comes in Friday night, it'll be the following Friday. So, so that's sort of a week right there, and we are going to do everything to make a classification… in the review on the spot with the exception of if there are cases that need more information and I think those.

Vinnie Disalvo

30:08  Yeah, that's good.

Mike

30:09  Could be that well to your point. Maybe it's working as designed. Maybe it's a defect. Maybe we don't know that and we're going to have to consult with engineering. So if that's the case, that would happen the following week and we'll try to get, you know, probably 24 to 72 hour turnaround on that. If that's the case. And then a classification would be made if it is, if it's client side information that's when we would immediately following. So I'd say Monday, you know, we'd reach back out to your team and say, hey, we think we understand this but maybe we don't get everything quite right. So is there a way for us to communicate with the customer? And that could be, I mean, it depends really on the nature of the question, if it's really simple. Maybe you guys as would know the answer off hand. But if it's something that warrants a conversation, then we would just look to do that as the next step. But either way, I think from start to finish or looking at less than two weeks or maybe sort of set about two weeks turnaround time for or classification. And I would also say maybe there's really kind of two different there's probably multiple more than two. But at least the two high level kinds of feature requests where, you know, one would be, hey, it wouldn't it be a neat idea if this happened or if this, you know, worked this way, we absolutely still want to hear those, right? And those will go through the same process versus something like my, gosh, this is critical.

Vinnie Disalvo

31:39  Right.

Mike

31:40  To have that. And I would also say like, you know, the accounts that you manage and the half of our company revenue that you manage really important and the other half of which is a far greater number of just scale. We don't really ever hear from as much. There's not really a good system in place for that too, but it really kinda needs to go through, I'll say an identical process but a similar.

Vinnie Disalvo

32:08  And…

Mike

32:09  We want to make sure let's say even with the 100 or so accounts that your team manages that we're hearing from the bottom third, you know, as that's I'm sorry that it's as easy for them to be able to submit ideas and communicate problems as it would be for the top 10 percent sure even though it comes through a slightly different vehicle in.

Vinnie Disalvo

32:32  Makes sense. You know, to that end, I'm in the process of working with Jason and Amy on couple of customer satisfaction surveys that we're gonna start implementing like for example, after, you know, onboarding as an example. I mean, if you'd like we can drop in a question around, you know, would you like to participate in on? I don't know whatever however you want to phrase it product, you know, feedback sessions or whatever. I don't know whatever you wanna say, like happy to add something like that as a sort of identifier. So that way you guys can at least see the pool of folks that you have, you can choose from.

Mike

33:21  I would love that. I mean, just so you know, that it is, every person on my team has a minimum quota now for…

Vinnie Disalvo

33:29  Customer.

Mike

33:30  Customer conversations. And the idea is that and don't take this personally at all. But the idea is that they're sort of outbound and driven that they're unsolicited, they're not, it's the client. It's not the client telling us they wanna talk to us necessarily, it's the client being willing to talk to us, right? And we kind of go in with, without a sales or revenue, you know, kind of agenda at all, like literally just we wanna understand how you use our product. We want, understand what's working and what's not. Those kinds of things are hard to set up and facilitate sometimes, but they're so valuable there. Valuable. And then we can offer stuff that people aren't asking that people aren't screaming about, right? Make the product better before they feel pain.

Vinnie Disalvo

34:17  Yeah. I'll also share I'm actually in addition to the customer satisfaction, like after onboarding, we're also gonna do one like after six months and I'm also going, I'm also creating one that is a quote unquote catch up survey that at least we're going to send to the CSM owned accounts where we're gonna try to answer the simple question of like why did you buy from us to begin with and ask some of those kinds of questions in an effort to kinda classify some of our customers and some of the use cases and things of that nature.

Support

Vinnie Disalvo

34:53  So I'll share that with you. Just, so that way I'll share the questionnaire before we send it out as well. Like, so that way if you want, you know, you can sort of put eyes on it and provide feedback. But then, you know, obviously I'll share any of the feedback we get. And if we want to send it out to more than just the CSM owned accounts, right? Like we can talk about that.

Mike

35:13  Yeah, that's great. Yeah, I mean, I think, and you bring up a good point that, you know, the clients that we're talking about here, the CSM managed accounts.

Support ends

Mike

35:25  We're in this wonderful position where they've already actually purchased us, right? Like they've already bought us, they've implemented us, they're using us. And so, you know, it begs the, I guess the position or the understanding that at some point they saw value in the product and made the purchase decision to go ahead and buy it. So when they decide to move away from it, that's really important to us too. And it's like, I know we've talked about a bunch of different reasons why that happens. But if you start with the premise that they saw value in and they got value at it at the point of original purchase that well, it's like, well, what's changed and something change in the product is, or is there functionality it's not working as designed or as promised? Then that's a problem, right? Like that's, product needs to fix that is their needs have changed their environment, their business models. Like then it's important for us to understand that too to accommodate for that. If it's something else like… the thing I struggle with our previous model here was trust, right? Like I think if we're saying, yeah, we're gonna take your feature request and we'll get, you know, we're gonna do it. And then we didn't ever have the ability to do it. That undermines the trust. And I feel like that does more damage to the relationship than not having whatever the functionality was ever could. So, and that's really hard to build back. So even though this is sort of like maybe bad news and sort of negative messaging around it and maybe not what they wanna hear.

Vinnie Disalvo

37:02  Ability level set.

Mike

37:04  Exactly like we are, we're being upfront about it.

Vinnie Disalvo

37:07  And we're calibrating expectations. Yeah. So one thing I do wanna kinda just call back to for the team as sort of a incredibly important point that, you know, we need to make sure on our end when we're first capturing requests, I'm just gonna classify them as requests from customers, right? It is incredibly important that we dive as deep as we possibly can and the customers willing to, at that particular moment in time, you know, depending on the scenario, right? To get as much information. So that means that even if like it's at the tail end of a conversation and the customer has to go, right, we set up a meeting to follow up on that before we submit anything before we do anything. Because the more information we can provide in that initial request, right? Via the let's say, Salesforce case before it gets to whatever that process. I say, Salesforce case now because that's what the process we're using, right? If that changes, well, you know, but whatever we can provide in that initial scenario, right? The quicker the time we'll get a classification on that request, right? And so that's not just good for us, that's good for the customer. And so, right? I just encourage you guys to really think about all the work we talked, all the work we talked about and did at our K, I would really understand sort of the, who, what, why, when and how of the processes of the atomic selling or, you know, just, you know, call it, you know, sort of discovery processes. Yeah. There's another process called the five wise, right? I think, you know, Mike talked about it in his presentation during this town hall. I believe, you know, I think those are the kinds of things that we really need to do, right? You know, from a root cause analysis perspective, we need to really understand what is it? What, you know, why is the customer specifically asking for it? And sometimes that is going to be difficult, right? Like I've been in conversations with customers where, you know, they don't want to over, they don't want to share more information, right? It's like, listen, I just need a button that does this, right?

Support

Vinnie Disalvo

39:19  Like, and that's all they're gonna say, right? They're not that like don't, you understand, like I'm telling you what I need, right? What I need is a button that does this, right? Like, stop asking me questions, right? But that's where I think we have to get a little bit more nuanced around things and really help them understand, hey, listen, you know, I'm, not trying to be difficult, I'm trying to gather as much information as possible for this specific reason, right?

Support ends

Vinnie Disalvo

39:44  Because you know, one of the things that our product team is gonna look at, right? Is how applicable, right? This specific use case overall, right? Are there other customers that have this that might have this problem? Is this, you know, systemic, you know, to not just our system but is it endemic to, you know, the solutions that, you know, are similar to ours? Is this something that we can, you know, provide a, you know, a more, you know, more value driven solution to not just you for that particular button but maybe there's a better way to handle this overall, you know, so I think we need to sorta have those conversations and be comfortable having those conversations if you are not comfortable.

Support

Vinnie Disalvo

40:27  Let me know. Certainly we can work on it during our one on ones and, you know, and if need be even in the first couple of those conversations, if you get a request, you know, and you not comfortable sort of diving deeper into it, we can set up a follow on conversation with the customer and you can invite me and I can help sort of discover, you know, help you learn how to ask the right questions and how to get at the right, you know, the right information. And I don't know, maybe Mike, maybe one of the things that we might wanna do is at a, in a future session, maybe you can help, you know, train, write the team a little bit on like a couple of examples like let's say a customer asked about this right here's. A good example. Like here's, how we would, I would ask those questions to get at some of that information. Just so that way the team can, you know, be better versed and have some good like concrete real life examples. And maybe we even now, I'm thinking about it, we take some of the existing scenarios and kind of role play them. I don't know just the thought.

Support ends

Mike

41:30  Yeah, no, I would love to do that. I'd be happy to do that. I think I'm trying to remember if we talked about this in the K or not because I know we ran short on time but I'm trying to pull together some resources as well, right? So there's a confluence page that I'm building out which will be for a customer requests, right?

Support

Mike

41:50  And that it could include CSM requests and include everything else. But basically, there are, there's a very short set of problem oriented questions that we ask ourselves if we understand them. And I 100 percent, you know, you guys have a job that's different than products job is trying to understand the stuff. So if you can help to facilitate the process, great. And if not like we just, you know, if we have questions that's we'll ask to come back and talk to the customer. But just it's the mindset of understanding, yeah, sure. The five wise, it's you know, everybody will ask for a button but, you know, nobody really wants a button, right?

Support ends

Mike

42:34  They want something at the end of a path that they see the button is being a critical step in. But there's probably other solutions. And anyway, just having that mentality, the other thing that is really important is what they're what we call the next best alternative which isn't necessarily a competitive solution, right? It's just, it just means like, well, what do they do if we don't have this? Like what's their work around? You know, do they write something on a posted note and give it to their assistant to file it like, you know, what is the actual thing in practice that we're doing? Because that is the measure of pain that they're feeling by not having… the feature, if that makes any sense. So just an example from my last company, one of the we didn't you know, we didn't know this till we started talking to customers but we were running a data integrity scanning service and we're doing the, we built one. We were doing their initial research to get the feel for it. And we talked to these customers that were like, yeah, we come into the office on Thursday nights every week to run the data integrity scan locally because otherwise that's the like that's the only time that people are off line. And this other one was like, I come in Saturday morning that I haven't seen one of my kids soccer games in, you know, in three years. And I'm like that's painful and personal, right? And… that's what we mean by the next best alternative. It's not like we just accept, you know, untrustable data. No, they find a work around, they find a way to make it work. And that's going to be the measure of pain. So, if you can understand that and, you know, and then, I know a lot of times the requests that we get aren't from the people who are actually gonna benefit from the feature, right? Like they may be. But is that button for our point of contact or is a button for the sales people, right? And if the sales people aren't really asking for the button, but the point of contact thinks it's a good idea, then we wanna talk to the sales people to say, all right. Well, what's your next best alternative? I'm like, well, we just hit this button instead, it's no big deal. Well, then, all right. Maybe the person making the request sees it as a bigger deal than it actually is for them. That makes sense?

Vinnie Disalvo

44:54  For sure. Yeah, I think a great example of this is to just take five minutes to drive the point home.

Attachments

Vinnie Disalvo

45:00  A great example of this is a new Burger request, right? So they instituted a process in their Salesforce, where when they upload attachments or when they load attachments into Salesforce, they ask the teams to classify those attachments in categories. So, you know, they're a financial services company, right?

Attachments ends

Vinnie Disalvo

45:23  So, like this is a portfolio, this is a, you know, whatever annual report, this is, whatever it happens to be, right? They classify them in different ways. And so, you know, the teams that do not utilize Cirrus insight, you know, they're going, they're in Salesforce and they're adding, they're adding the attachments in Salesforce directly. And so that classification, you know, as a custom lightning component. And so it's really easy. They hit upload, and then they hit a couple of drop Downs and hit save. And then now that document is forever classified, you know, the teams that use Cirrus insight to load attachments through the sidebar, right? Don't have the ability to utilize… that custom component. It can't you know, we don't have the ability to do that. Our system just doesn't work that way. It doesn't allow for that. And so, one of the requests from… the sales enablement or sales ops teams or the Salesforce teams was like, we can, you build this, you know, for us, I can, you know, build a way to just show those particular drop down. So when somebody files something, right? It can go ahead and there's actually a JIRA ticket on this already and, you know, on this particular request. But the point I'm trying to make here is like what Mike is really talking about is the request is from the sales ops to say, hey, listen, I want to be able to do, I want to be able to sort of have these two additional buttons or drop Downs in the side bar, right? That's what they want. Can you give me two additional side bar? You know, surface these two drop Downs, but the reality is that, you know, there's a couple of different pain points, number one, the organization, right? Has a bunch of organized data and then a bunch of unorganized data, right? And then, you know, who does, so that's pain point number one, right? Pain. And it even goes further than that because there's like what are they trying to do with that? Why is it classified? Right? It's creating, you know, additional problem sets there. But then there's the end user pain point, which is everybody that's using Cirrus insight now has to do double work.

Reminders

Vinnie Disalvo

47:39  They have to file it first from Cirrus insight, and then they have to, at a later date, they have to go into Salesforce, open up Salesforce and reclassify it. And two things are happening in that workflow. One, right? They're doing it at a later date. It's creating, you know, they're spending more time doing it.

Reminders ends

Vinnie Disalvo

48:00  And number two, some people are not doing it at all. And so see the first problem which was a bunch of unorganized data. And so just understanding those kinds of things, right? And drawing that information out help like we…

Katy

48:13  Still…

Vinnie Disalvo

48:14  Might not do this thing, right? Like we still might decide, hey listen, this is a very unique bespoke, you know, feature set. We're gonna choose not to do it, but we still need to understand like we can't make that decision until we really understand kind of all of the components. So, you know, I just think it's a good example of, you know, really kinda getting at the core of like the, okay. Well, why do you need these two drop Downs to be surfaced in the side bar? It's not as simple as just saying, okay, yeah, they just want us to surface. These two drop Downs. There's more to it than that as well. So I don't know, I don't know if you'd add anything else to that, Mike, but I think that's a good example of.

Mike

48:57  I think that's a perfect example, you know, duplicative work, loss of time or, you know, opportunity costs where sales people could be otherwise selling, you know, instead of doing things twice, but also like this overarching risk of like the data being incorrect, right?

Vinnie Disalvo

49:17  Right. This is.

Mike

49:18  Maybe we're getting into us stuff here. But like any time you're dependent upon a manual step, a manual intervention that's an opportunity for something I want to try to solve in the product because that requires time. It's subjective to people's you know, disciplined to actually do it and it introduces risk. So those kinds of things, you know, might not seem like big deals in surface and surface level. But like we can create a lot of value by tackling those kinds of things sure through automation. But yeah, no, it's a good example.

Vinnie Disalvo

49:53  Awesome. Well, anything else? I know, I think when we originally talked about this, I think, I don't know that you signed up for a full hour worth of conversation.

Support

Vinnie Disalvo

50:02  So I want to be cognizant of your time here and maybe give you back 10 minutes. Is there anything else you wanted to cover that we haven't yet or talked to?

Mike

50:11  Yeah. I mean, what I'd like, I mean, I feel like I feel like you and I are doing a lot of talking which is great.

Support ends

Mike

50:18  I would definitely, you know, I'll get the confluence page up with artifacts and hopefully tools. I would say if there's any feedback that you guys have on like well, something some other kind of tool would be useful or whatever we can put there to sort of help facilitate the process.

Support

Mike

50:36  Just let me know and I'll get that up there. I would love to do if you're open for a, you know, a brief training on sort of how we look for problems and I'd probably include are okay with that? I'd probably include other folks in there too or maybe, yeah, like I think that would be wonderful.

Support ends

Mike

50:57  But then also, I would love to do a, I don't know if there's more like kind of round table forums where I'd love to hear from you guys what you're hearing and seeing that's not necessarily coming in a JIRA ticket, like what are the, what are the big challenges that your clients are facing? Just on an ongoing basis that we're trying to help them solve with Cirrus insight. You know, I'd love to have that kind of feedback too.

Vinnie Disalvo

51:29  Yeah, sure. Yeah. I mean maybe we'll set up a separate sort of product roundtable conversation for something like that that's a good idea.

Support

Vinnie Disalvo

51:39  Is there any, are there any questions or thoughts, I mean from the team on what we discussed there? I know I've tried to sorta summarize what I've heard from… you know, all both independently and as part of, you know, sort of group conversations. But is there anything specific that you wanna, you know, kinda point out or that we may be missed?

Support ends

Mike

52:03  No, I'm sorry, I'm just thinking too, like I would, no, I mean, I think, right? I like that. I guess where do we see Sirius inside doing really well? Like what are the things that, you know, where are the winds that we're seeing and hearing from our clients?

Support

Mike

52:20  I honestly think it would be great for we get together like, you know, quarterly and I'll bring in the product teams and I'll mail, bring in the architects to like, I think it would be really useful to hear what you guys see every day, you know, so.

Vinnie Disalvo

52:38  No, I think we do that. So, I don't know Katie, John, Hank, Sam, any other thoughts on your side?

Book Meetings

Jon

52:49  I like that we were actually talking about this as a group instead of in silos in the past. It's been very siloed conversations around these things. So I definitely appreciate talking across departmentally for sure.

Vinnie Disalvo

53:05  Awesome. Great. Well, Mike. Thank you very much. I really appreciate you carving out some time for the team and talking through this recapping and even talking about new stuff.

Book Meetings ends

Vinnie Disalvo

53:18  I think is takeaways… also share some of that stuff that we talked about with regard to some of the surveys. And, you know, we'll you know, maybe set up a… round table, you know, we'll take the first one and sort a set up the we'll, find a time in the future, maybe in March potentially to do a round table for. And then we can, you know, include just this team or others as well. You know, I'll leave it open to you to do kind of a product round table for some feedback but yeah, otherwise, I'll look, we'll wait to hear from you on some of the other things as well.

Book Meetings

Mike

53:59  Okay. Yeah, that'll be great. I'll let you know as soon as we get through this review process in the next week or.

Vinnie Disalvo

54:06  Awesome. Thanks, Mike. Appreciate it.

Mike

54:08  Thank you guys. I appreciate the invite.

Vinnie Disalvo

54:10  Yeah, I…

Jon

54:11  I…

Vinnie Disalvo

54:12  All… right. Well, I appreciate it. I know we don't have a ton of time left here, but I appreciate you guys, you know, sort of paying attention and being part of that conversation.

Book Meetings ends

Vinnie Disalvo

54:27  I think it was a good recap overall. And as I said, at the end there, I was trying to give voice to a lot of the things that I've heard from you at different points but, you know, certainly if there are other things that you think we should be bringing up or we didn't cover, just let me know. I don't know quick reactions, good, bad and different. I know John, you said you thought it was a positive sorta step forward potentially?

Jon

54:59  Yeah. I know Hank has seen it having been at Cirrus for a while that, you know, we get told, yeah, sure. We'll do something and then nothing ever happens from it and there's never any conversation. It's just, no, we decided not to go that direction. So I really appreciate having conversations like this and actually listening to the CSM feedback or anybody's feedback for that matter. Not just ours. Yeah.

Hank

55:27  Our last Cirrus Insight 19 feature release was a, hey here's. What we're doing and it was not asked for by any of our customers but the CSM can managed.

Book Meetings

Vinnie Disalvo

55:37  Nice.

Hank

55:38  Just, yeah, background on that. So I definitely appreciate this, you know, the willingness to like, hey, what are we doing? Right? What are we doing wrong? And, you know, where could we like get everything on the same page? I like that approach to it makes sense.

Vinnie Disalvo

55:56  Very cool. Hey, Sam, thoughts on your side?

Book Meetings ends

Katy

56:03  Yeah, I think the biggest thing that stuck out to me is just visibility and communication. So it sounds like, you know, I don't have a lot of background in the process before, but it sounds like we were just taking these and then not really able to have visibility into where it went from there, what the feedback was, and that can be detrimental to relationships. And I think sometimes a hard know up front of like, hey, this isn't in line with our road map. No, we're not going to take this into consideration is a lot easier than join it out for six, nine months or, you know, they're not getting an update. So, yeah, it sounds like really good plan and process in place for that. So that's yeah, I thought that was really good to hear.

Vinnie Disalvo

56:46  Awesome. All right, Sam, anything or just another thumbs up? Yeah, I mean, basically, okay. Do you said I, I'm excited to have more visibility into everything and it seems like the process is going to be a lot more streamlined now, so.

Katy

57:02  How do you?

Vinnie Disalvo

57:02  All feel about the three bucket system?

Hank

57:10  I like that. It's upfront and it kinda tells us what it means. So, it's like, you know, hey, if something goes into that third bucket which is basically a black hole that's fine.

Vinnie Disalvo

57:20  One thing that he didn't call out that I just wanna make sure you guys are aware, right? Like the idea is that it's gonna get classified in those first two weeks, let's say, and then that's it, there are no more updates. That is the classification period into story. And if there is a, if it, if something were to change, right? Like we'll let you know, but don't come asking for us for an update.

Hank

57:46  So, one follow up to that, maybe we can ask for our next call, let's say something gets classified into one of those three buckets.

Vinnie Disalvo

57:53  Yep.

Hank

57:54  But then there's like… 100,000 dollar customer comes in. Hey, I want the thing or I would.

Vinnie Disalvo

58:02  So…

Hank

58:03  Similar to bucket to what's in bucket to or bucket three, then at that point, does, do we had a system in the play in place in the past word, it's like revenue bucket or the revenue tied to a request affects the ranking. And then the team would rank those requests depending on how many lashed onto each request. So.

Vinnie Disalvo

58:26  Yeah. I don't know how they're he didn't share, like how they're specifically ranking the requests. So, I don't know about that, but I guess I should clarify, right? Like the idea is basically pretty, you know, pretty simple, right? Like it's either won't do and it just falls off our radar, right? That's that third bucket. This the will do is what you described like in the next two quarters, right? And we'll update you like when it's done or if it gets put, she or whatever the case might be, but we're not going to give you updates every week on it, right? It's just, it's gonna get done at some point in the next six months. And then there's that middle bucket where it's kinda like we might do this. And if we pull it forward, we'll let you know. But other than that, like don't ask us about it because it may never happen, right? Even though we might do, it may never happen. So… that's the, that's what he's proposing as the communication kinda component there.

Jon

59:34  He mentioned the reevaluating where the team gets together every, you know, and looks at it, you know, six months, three months, 12 months out. Do they ever, is there any mechanism for them to go back and reevaluate those things that were in the won't do, or maybe we'll…

Vinnie Disalvo

59:54  I don't think won't do will ever be reevaluated. I think the might do will get reevaluated that's what's going to get reevaluated. Okay? That'll get reevaluated every quarter, right? And so it'll either stay in that bucket or it'll actually, it'll get essentially what they're doing is they're reclassifying every quarter, right? So everything that's open, right? That hasn't been actually done yet and is in the, sorry, let me start again. Anything that's in the will do that hasn't been done, and anything that's in the might do is going to get reclassified again. And it's either gonna get put into the will do again in stay in the might do or get pushed for whatever reason into the won't do. And if there is a change in status that will get communicated obviously, right? Like if something was in the will do, and then for some reason we decided nope this is a won't do now, right? For whatever reason. And I can think of a couple of good reasons why that could happen. Like, you know, if you think about the stuff with next error that we decided that we were going to try to do with regard to reducing the permissions, and then we realized by reducing the permissions, it actually screwed up Sync to not work. And so we decided, okay, we're not going to reduce the permissions of the application. So we had to roll those back, right? That was a will do, gonna get it done in the next three months. And then eventually quickly we realized nope, sorry, this is a won't do. So there could be like that kind of a scenario that does happen. I'm sure that, you know, that'll be… you know, an exception, let's call it, right?

Book Meetings

Vinnie Disalvo

1:01:40  So, I know we're over anything else. I don't know if anybody has to jump for another call by all means jump, but I'll stay on for a couple more minutes. Any other thoughts, anything there? Is there anything urgent that you guys are waiting on me for?

Book Meetings ends

Vinnie Disalvo

1:01:52  I wanted to ask that question. I think I've I think I've gotten everything. I think the only thing that's potentially I mean, there's a couple of outstanding things that we have for like Cam or Phil or whatever, but nothing specific to me, right? Okay. All right. Well, well.

Book Meetings

Mike

1:02:14  Yeah.

Vinnie Disalvo

1:02:15  Obviously, we'll talk the rest of this week, but I appreciate you guys jumping on. If you have any other thoughts, let me know, Hank. I might ask you to just take the lead on setting up that product route, round table. Just pick a date sometime in March that may work and just set it up for the whole team and… kinda take it from there. All right?

Hank

1:02:38  Do you want me to invite Mike to that? Just.

Jon

1:02:42  Yeah, we…

Hank

1:02:42  Have they been created?

Vinnie Disalvo

1:02:44  Just just find a time, you know, set it for the, you know, the six of us and then, you know, Mike can invite whoever he wants. Cool beans. All right, thanks, brother, be.

Hank

1:02:59  Hi.

Jon

1:03:00  Everybody.

Vinnie Disalvo

1:03:01  Have a good one.