Welcome to The Feedback Loop, it’s a bit like The Twilight Zone only less weird. We put two Receptive clients (one old, one new) in a virtual room together so that the newbies can gain insights into how to make the most of Receptive from those who have been there, done it, and got the t-shirt.*
*T-shirt may not exist.
In this episode, Aly spoke with Melanie Walker of Magnus Health, and Doug Forester of Commissions Inc. Doug was hesitant to open out Receptive to his clients so Melanie helped to reassure any fears he had.
You can listen to the episode here:
Or else read the full transcript below.
Skip to:
-
What were the initial questions when you first opened up Receptive to your customers?
-
When you were getting started did you have any historical data imported into Receptive?
-
How do you respond to requests when they first come in to Receptive?
-
What do you do when you’re building things that aren’t in Receptive?
-
How do you handle requests you know you’re not going to build anytime soon?
-
Do you communicate your goals & strategies to your customers?
-
Have you had any nasty requests come in or anything you’ve had to delete?
-
What do you do with requests that have been pending for a long time?
Full transcript:
Aly: Thank you guys both so much for taking the time out to jump on this phone call! Melanie works at Magnus Health, and she’s been working on their Receptive account for Magnus for the last six to eight months. And then Doug from Commissions Inc. has been managing their Receptive account and they’ve been using it internally for the past three, four months and considering opening up to customers. So it’s going to be a good balance of back and forth.
But let’s start off with introductions. Melanie do you want to start?
Melanie: Of course! My name is Melanie Walker. I’m the product owner here at Magnus Health. We’ve been utilizing Receptive for our internal team here and also our client base. We’ve opened up the communication from there and we’re managing it through our product team. Our client base utilizing Receptive is primarily schools and their nurse teams or their help center on the line with their administration.
Aly: Perfect. Doug do you want to give a quick introduction?
Doug: Sure. Yes, so I’m Doug Forester. I’m a product manager over at Commissions Inc. So what we do day to day is provide a CRM tool for the real estate industry along with some PPC as well.
We’ve been using Receptive for about four months now. Probably getting closer to five months including the test we did. It’s all internal right now and we’re using our customer support team as the gate for requests coming in. They can import requests and then myself and other product managers will review and determine prioritization and where they go in the process.
Aly: Perfect. So do you both want to tell me a little bit about what you’re hoping to get out of the call today?
Melanie: I’m primarily curious to see if there’s anything I could improve on on my side for my team that I might have not uncovered yet. How to either manage it or, if it’s impacting their roadmap in a negative way, how to go about solving that. There’s some items that I’m not sure about, I’m hoping that there’ll be a lot of light bulbs going off to pull into our team over here at Magnus.
Aly: Perfect. What about you Doug?
Doug: I would say for me one thing I would be interested in hearing is how you guys utilize it with clients having access to it. How you answer objections there and how you manage that, especially when there are requests that might fall within scope but a long time in the future. Part of the reason we’ve been hesitant to open it up to extra clients is that we actually have a competitor who uses different software. They have it open to clients and it can often turn into a mob mentality for them. So hearing some thoughts and tips would be great.
Aly: That’s definitely a common concern that I hear all the time before people open it up. But I know Melanie will have some good tips for that. And I’ll just chime in with what I’ve heard too.
So Melanie, I know you said that there’s been some changes to your process for managing feedback and the roadmapping process over the past few months. Do you want to give us an overview of what you’re doing today and how that’s different from what you were doing a few months ago?
Melanie: So since it’s now open to our clients, once a request comes in we let it sit and wait for about a week before we review it. We see if it needs more time for other people to see if they want it as well or merge it into another request. If we know it’s already out there we like to merge it immediately so there is less of an overlap with that as well. But we really didn’t have much going on before Receptive. It’s been a 360 turnaround for our company really.
We would get questions or suggestions and they would go into a spreadsheet. Now that we have that organized and are able to utilize the searching tools, we can dive down into this area of the application of change. Are there any Receptive feature requests that overlap that, that we’re missing out on? Our client base love Receptive because they’re able to see that we’re listening to them and to their needs and wants. Being able to provide a platform for them to discuss what other people are doing in the industry that they’re in and seeing what other people need or if they have a work around that they’re actively using has been phenomenal.
Every week we take a look and see if there’s any questions that need to be asked. We do a feedback Friday style meeting. For two hours we groom it all, along with other things.
Aly: Is that meeting still every month?
Melanie: We’ve switched that. We have a Feedback Friday every single Friday now because our clients love it and so we want to see the changes.
We sent out an engagement e-mail and I think it was a 200 percent increase in traction. So we want to make sure that their needs are being addressed somehow or let them know if it’s something that already exists in the feature. That’s a number one, having someone reach out to talk to them as well. Taking the extra step to create that connection with the client so they’re more likely to utilize Receptive in the future.
Aly: What were the initial questions when you first opened up Receptive to your customers?
Melanie: Well we launched Receptive immediately after a conference that we held. So I kind of had a show and tell in that conference. I was able to have a group of clients and pitch the idea to them before it rolled out. And it really was a case of them looking at me and saying, “So we can tell you everything and see our request and follow it?”
They were a little hesitant about getting e-mails for everything but now they seem to love being notified when something’s out in the software. We’ll get people responding back saying “Thank you. Can’t wait. Looks great.” So that’s really nice.
Aly: Cool. Doug do you have any questions so far?
Doug: Yeah, one question is how many requests do you have on a weekly basis?
Melanie: It really varies depending on season. We get quite a few after an engagement e-mail or if a client suggests a really great idea.
Aly: For new requests for the last six or seven months you’ve had between anywhere from one up to eight new requests a week. But there’s a lot more happening under the surface - there’s up to 80 votes per week.
Related: What can I expect in terms of customer engagement?
Doug: We probably see the opposite and part of that could be because it’s not open to the clients. We see a higher amount of request per week but less changes or votes or people adding on to additional or features that were already out there.
Melanie: When you were getting started did you have any historical data imported into Receptive?
Doug: No, we did not.
Melanie: Okay. We actually imported historical data. So we had previous client requests and updated the status on them. That groomed them a little bit. So we had a plethora of requests already there before the clients came in.
Doug: Okay, that’s good to know.
Aly: Awesome. So Melanie, any other updates?
Melanie: We planned how we’re going through our engagement emails. Since we don’t want to crowd everyone’s e-mail all the time we’re sending them out twice a year during peak sessions where people are signed into our platform.
The other thing we started doing is highlighting internal users that were ‘super users’ during the month. So I’d send a shout out saying, “Hey, these people are in Receptive and doing all this stuff. Don’t forget to log in. Thank you for being awesome.” Pretty much.
Aly: That’s such a good idea. Do you get that data from the metrics page or do you use the weekly emails from Receptive?
Melanie: I use that from the metrics page. If there’s not a lot of traction I’ll send out something to everyone along the lines of “Feeling down today? Check out Receptive.”
Aly: That’s so great.
Melanie, can you tell us a little bit more about how you respond to requests when they first come in to Receptive? You said you wait about a week and then what do you do with them?
Melanie: So then we review them. We have our small product team all together in a room and go through them, requesting more information, moving them, or merging them. It really depends on the type of requests. If we already have something coming down the road, we’ll explain that we have something similar but not quite.
And then we’ll create a Receptive request that’s a little more tailored towards what they’re looking for and then request any feedback they have for that. I’ve also started creating more preplanned items. I’ve heard clients talk about wanting a feature that isn’t in Receptive right now. So either I’ll submit some or my product team will so they can get some kind of feedback on that report when it’s released.
Aly: Okay, so when you’re building something that’s not in Receptive you’ll add it anyway to get votes or comments on it?
Melanie: Yeah. We work more in an agile framework. So if a client brings up something that we miss, we’re able to fix that before they even see it. We have advisory boards and we have certain demographics but it’s even better to reach out to everyone who utilizes Receptive.
Aly: That’s perfect. Any questions Doug?
Doug: When you said that you were adding in things that you were already building, how do you use that and do you build out that graphical piece and allow customers or clients to see that? And what benefits do you get from it?
Melanie: So from a roadmapping perspective we didn’t put everything in from the outset because Receptive would be too large. But with our roadmap we’ve kind of done it through a different software not designed for roadmapping. So we foster it in a general document and go from there. But if we have a major change we’ll place that into Receptive. If it’s client facing it’s most likely going to be in Receptive already.
We’ve talked about tagging items that are slated for a specific quarter as well. So that we can do some quick searching on our internal team’s side. But we haven’t utilized Receptive as much for roadmapping. That’s something that’s on our agenda this year. So it’s something that I’ve been working with and the internal team as well.
Aly: That’s really good to know as we’ve got some really good updates coming on the roadmapping side. You’ll be able to create customized boards and break requests out by different goals and strategies. You could have a specific report just for a specific team. So while you’re building those internal reports keep that in mind. You’ll soon have the ability to make a bunch of different reports and roadmaps and use them in any way that you want.
Melanie: Okay, awesome. Because we’re really looking to have something that’s internal and then something else which is client facing so I feel like that would be perfect.
Aly: So, back to the triage process. Is there anything else you want to add around that? I think you called it “grooming”?
Melanie: Yes, we also have the integration set up for JIRA with Receptive and that’s come into it, it’s a lifesaver. We’re able to have the statuses in Receptive change as they go through the workflow in Jira. So it’s a lot less maintenance on our side to make sure everything is in the correct status.
Doug: One thing I’d be curious to know is how you handle responses to clients when the requests come in that either may not ever happen unless there’s a big following or maybe will happen a long way down the road. One of our competitors saw all kinds of things blow up in relation to that. That’s where part of the hesitancy comes from. So I guess if you can talk around that in this next question that would be good too.
Melanie: Sure. So with our software we do not specifically build it for a specific client. So we’re right with you guys on that. We’re not going to try to build something that will benefit a lot of people just because we want to do the vast interest of all our client base. We like to do things that are life changers for them. If we have a feature request, that’s a great idea but not something for right now, we would let it sit for a little while and get more feedback to see if anyone else wants it.
I don’t have a designated time frame. If there is something in the feature request that may actually solve other people’s problems as well I’d start to ask those questions. But if it’s something that is coming down the line, I would make sure to include a planning message that states that. For example, “While this is a great request, it’s not something that’s in scope as of right now. However we have placed this in our backlog.”
We can’t give a definite time for release but we can make sure it’s clear to them that you appreciate their information.
Aly: Melanie are your customers aware of the current strategies that you’re working towards or different goals you’re working towards? Is that something you communicate to your customers?
Melanie: We do major emails at the beginning and end of the school year that align the priorities for the upcoming months. So it comes directly from our CEO to our clients and it includes the high level items that we’ll be working on.
Aly: Do you think that helps you explain and justify the decisions you make? Do you ever pull those goals in so that they’re aware of the feature level product decisions?
Melanie: I would say it actually depends. If their feature request would make sense and if the feature request really would change something or fits into the product or the theme that we’re looking at changing, we could pull that in. It also depends on the scope of the project or what they’re looking for.
For example we have the ability to store data for something but it doesn’t show in the UI when the client’s actually using it. We have that part done but they really wanted to see that. So now we’re able to pull that into the user detail improvements that we’re making to display something like a student’s middle name if they want to.
Doug: Yeah, one thing that came up as I was looking at my notes is that you said you put some of your major changes on the roadmap or list view. Do you also tag your active clients on that so they get updates since I guess it would technically impact everyone as it moves through the process?
Melanie: I leave it open for everyone to see. If they’ve requested that feature or in passing someone on our client services team has said, “Oh this client really wants this”, we’ll add them to it. If we’re communicating with that client or if they have a scheduled call already, they’ll mention it then and we’ll send them the link for it.
Aly: And the engagement e-mail probably helps with that too. So if you do those big projects that you’re working on as they’re released they’ll be added to that list in the engagement e-mail.
Doug: Did you say you send that twice a year, monthly or what would you else process with that?
Melanie: We send it twice a year just because we have quite a bit of communication going out to our client base and we don’t want to flood them with e-mails.
Aly: Doug, do you communicate your goals and strategy to your customers, and does that help you explain your product decisions?
Doug: Yeah, we recently made some changes where some of our customers said “Well, I noticed your strategy but it doesn’t align with what I use and how I do my business well.”
Melanie: With any change-overs I would foster those relationships to pull feature requests out of those conversations. Sometimes when we have launched new areas of our applications they log in and it looks completely different. They get a little panicked but we try to identify exactly what’s missing.
So I think that would be great if you did open Receptive to those clients and included that information because they can also see that you’re listening to them as well.
Aly: Like I said Doug, I’ve definitely heard that concern a lot of times. I had somebody telling me before they opened up Receptive, that we didn’t understand their customers. They’ve actually forwarded me some of the feature requests and they’re in all caps with a long description. Some of the requests are a bit crazy but they haven’t had the negative responses that they thought they’d get. It’s such a positive thing that you’re doing after all. I would also definitely recommend keeping the names showing, it can help avoid any trolling tendencies.
Any other tips around that Melanie? Have you had any nasty requests come in or anything you had to delete?
Melanie: Actually it’s been pretty good. However we do get some clients that get impatient, saying that it’s been pending forever when it’s only been two months.
Aly: That was one of Doug’s questions. What do you do with those?
Melanie: It depends. Clearly if they’re saying that then the pending description needs to be updated. So I’d update that to be a little bit more descriptive. For example: “This isn’t a hot ticket right now and we’re looking at eventually doing this but it cannot be defined.”
Or if they are extremely nasty I would pull that conversation offline. I don’t like fostering those comments in Receptive because I don’t want to have others caught up in it. If everyone’s subscribed to it, they’ll get an email every single time.
By pulling it offline and seeing if there’s anything that we can do in the meantime, such as updating the feature request, or getting some feedback on the pending message. Now we can save customized ones so that’s something we’ve done. We’ve altered the provided statuses and enhanced them.
Then we have some for internal and external as well. For the internal one, we might ask that they do not let any clients know about this since it’s very far down the road.
Aly: Can you think of any other examples of complaints you’ve received from customers?
Melanie: We’ve never had a customer complain about Receptive itself which is fantastic to me. We have a lot of internal people requesting on behalf of external people so it’ll be good to expand and have more external clients using Receptive. The only thing I’ve had was someone getting angry because they wanted to reset their password or something but it was unrelated to Receptive. It was actually nothing that Receptive could do. I assume they wanted to reach out to our client’s services but they wound up in Receptive and didn’t really know what to do.
But not having many complaints in there is really good. It’s also useful when they say that our competitor does X and provides us with examples. I like to get that information.
Aly: Yeah, definitely. What do you do when that happens? Do you take the competitor’s name out and just leave it as a request and type it up so that internally you know or do you just leave it in there?
Melanie: We do remove the competitor’s name. We like to have it as a request and not saying you should be doing this because someone else is doing this. But we include it in a private comment and we still keep them open. We want everyone that has an interest in that to either make a comment or vote on it or even say they don’t want that.
Aly: I guess I have one more question. Do you ever say no? Do you have some custom responses set up for just saying that’s not going to happen? Do you get any pushback, and if so what do you advise in that situation?
Melanie: If it’s something that we are definitely not doing, for example, it jeopardises protected health information, then I make sure I understand the feature request and I verify that this is something that we will never do in this format. We’ll politely smooth it out as much as possible. We explain that we are declining the feature request because of such and such a reason. Then I like to ask if they have any further questions on why we declined it.
Aly: Okay. Cool. Does that help you Doug? Does that give you some tips and ideas?
Doug: Yeah it definitely does. It’s always good to hear how different people are using it, especially with a more open approach. That gives us some things to think about as we start moving down that path, which we’re eventually going to do.
Melanie: Yeah, we like to listen to our users and Receptive has really increased that. It’s provided a transparent platform to host needs and wants that aren’t always addressed by quick conversations or quick chats with our client services. But it also has opened up a platform to have our clients speak with each other and see what everyone else wants. That’s also helped them a lot as well.
But I’m very delicate when it comes to declining things. I always want to provide a reason why and not just saying it’s out of scope because that could mean only so much to the person reading it. So always providing that detailed information is very beneficial. Or if you get a nasty response I would just take it offline and see if there’s anything else you can do.
Aly: Alright, well thank you guys both so much. Is there anything else, Doug?
Doug: No nothing, I just appreciate your time and thank you Melanie.
Melanie: Of course, I would definitely give it a trial period of opening up to your clients so you can a lot of change and hopefully it’s not negative.
Aly: I swear I didn’t pay Melanie to say all that to you Doug.
Melanie: No, I really like Receptive. I recommend it to so many people.
Aly: Awesome. It’s been really great to hear both of your perspectives. And thank you both so much for your time.
That’s it for episode 1! Don’t forget to tune in next time for a brand new episode of The Feedback Loop!
