RX 24 - Top Mistakes Churches Make When Moving to Rock RMS - Austin Spooner

Transcribed Content

Welcome to the first session of the second day of Rx. Today, we have with us Austin Spooner who has been in the Rock community since it was in beta testing. He's with Veritas Church, and he has helped tons and tons of other churches and church plants establish or move to Rock. Here's Austin. Hello. Good morning, everyone. Good to see you. Quick question. How many of you are already on Rock in this room? Sweet. And the rest of you must be thinking about moving to Rock or in process? Sounds good. Sweet. Well, a little bit about me. My name's Austin. I'm at Veritas Church. We're in Cedar Rapids, Iowa. That's my family. That's Sarah and Noah. I've been at every Rx except one. Noah was born during one of the Rx conferences, and now he's almost eight, so that's a little ridiculous. But we've been using Rock for nine years. I've been at Veritas for the last six. They were using Rock since I started there. I helped them when they were planted ten years ago. So the next slides, we're just going to go over top things I've seen as I've helped churches like over the last nine to ten years move to rock and just some different pitfalls. If you have questions, we can take those probably as we go. We got a small enough group, so just ask away, raise your hand, we'll make sure we get to those. So first thing I've seen is churches making the mistake of going like, hey, we want to move to Rock because it's free. Nothing's ever actually free, and I've seen churches sell it to their leadership as free, And then they go, oh, it actually, like, we need a server or we need support or we need to do these things. And it's like, what's actually it's not free. And you've heard all this conference, like, the the community and the donations are what this what makes Rock, like, actually work and be funded and get more churches on and get more features built. So I would say, like, if you're in a meeting, you're trying to really sell the Rock to your leadership, like, don't sell it on the cost of free. One of the things we did was, like, we were paying, like, a ridiculous amount for our previous church management system, and we did need to, like, save some money. But we're, like, we're gonna commit to at least giving 75% of what we were paying before to Rock. And then we kept 25% to billing out, like, custom things, like websites or other features maybe we wanted. But seeing it not as a cost savings was really helpful to our team. And as like a senior leader in a church, a lot times when my team comes to me and says, hey, this thing's free. I go, I don't know if it's like the right thing, because nothing good is ever really usually free. But understand what it takes to use Rock and properly budget for it. Next, lack of planning. I've seen a lot of churches just go like, hey, we're just gonna install this thing on the cheapest possible server and just use it. And we don't have any buy in, but it's like, we got data in there. We're using Planning Center, plus we're using Rock. And we didn't take any time to understand where our data was or is or where we're going with it. So going too fast, not planning well usually leads to people not being bought into the platform and unsuccessful implementation. And then just getting buy in from leadership ahead of time, making sure your top leaders know, like, hey, this is where we're going. This is why we're doing it. The vision behind it's compelling. Like, there's no reason not to tell them the whole vision behind the software and the product. The next one I've seen is like, hey, inadequate training. Like there's tons of resources for training in Rock between the 101 class, the master's class, the new lava class, the check-in class. Many churches just underestimate, like, the training that's already out there. Even if you can't afford any of those classes, like, if you look at the Triumph website, the Rock You videos, you actually read the manuals, like, there's tons of training. I would say one of the pitfalls I made for like a really long time was not wanting to send my staff the documentation going, well they're just gonna discover stuff like we're not ready for them to know, or they're going to start implementing things that they don't necessarily need to. Some of our best ministry wins have come from that, where it's just like, hey, we sent a coordinator a manual, and now they're asking about a feature we haven't implemented it. But it's like now our team can help them implement it and learn something new that maybe we didn't have time for. But it's good to have our ministry staff actually know what's out there. We have a sandbox install where they can maybe where way more people have actual admin rights. So like even people who don't have admin rights in our Rock instance can go out there and be like, well, just kind of want to add a page or add this block or configure this group type after reading the manual. And we're good with that. They can't really destroy that area. And so I would say don't overlook the need for training. One of the things we've done is, like, we've sent like, I've gone to the the master's class. That was super beneficial. But then coming out of that, like, I just had highlights after highlights of things where it's like, this department should know this, and this department should know this. And a lot of times, I'll just get back and send them that excerpt of the manual or these two videos just to try to keep people in the loop of where it's going. Another thing kind of on that is like we read release notes. I think people get excited about the future of a product. So we always also try to keep our team informative. Like, hey, these are like the two or three really cool things coming out in the next year that'll really benefit your ministry, kind of tease them to stay interested, but also like, hey, this is still innovating, and people are thinking about it, and this is how that feature's going to work. And so we're talking about that often. The next one, John kind of talked about it a little bit this morning in the keynote, but like ignoring data cleanup before migration. If you're gonna migrate your data, like do the effort ahead of time to clean it up, make sure it's good. Or don't do the import. Or like, I've helped many churches who like have membership, and so they have to import like member data. So we'll just say like, hey, this data is the valuable set. So like we're gonna take all of our active members from like the last five years, and we're gonna make sure that data is good. But everything else doesn't really matter. And I've done a lot of work with churches where we've had we've emailed everybody and been like, hey. Use the new family sign up block that he mentioned to get everybody in the database. It works really well and have somebody go in and clean up that data a little bit. But I've done that with churches that are a hundred people to a church that's close to six, seven hundred people. And it's really it's really not that much work. But making sure your data is good and importable before you do it. And I would try to import your data, maybe not in your production instance if you're going try doing that yourself. Yeah. On that note, that was kind of my directive going into We're going live in November. And when I went direct to get guidance on that, I was told there's a lot more toolset in ROC to clean up data that we should just bring things over and then do it after the fact. So I don't know if you weigh in on that. Yeah, there's a lot of built in tools in Rock to clean up data, especially if your addresses aren't in the right format. Like Rock's address standardization will help you with that. If you have duplicate records, Rock's duplicates job will help you find the duplicate records and get them merged. So I think there's a lot of good tools in Rock to clean up data if you don't have that in your current system. If it's a small data set, a lot of times I've just brought it over to Excel and sort by name, look at the IDs, and just try to make sure, like, hey, these all make sense. But if it's not thousands of records, it might not be too bad to do it that way, too. The next one I've seen is like trying to implement too much, like way too fast. Like Rock does so many things, it's unbelievable. We came from Arena way back in the day, and we had a long list of like, we use this feature and this, down to like the most ridiculous feature of classified ads, which it had, which was like, oh, why would we ever do this as a church? We can use something else. Had to it forced us to prioritize like, these are the actual things we need to run our ministry, and this is the timeline we're going to do those in. And now, like, nine years later, we've implemented far more. But taking a step back and going, gosh, we need groups, we need website, we need give in, and we need check-in helped us go help us train our ministry leaders on like three to four to five things and really have them have really good experiences to make them want to do more and not get frustrated. I'm not saying there wasn't frustration. There's always the people who are like, I don't want to go to something new. I don't want to with that. And it was way better over here. I mean, maybe it was a little bit sometimes, but there's just more of like getting used to something different. But I would say trying to simplify your initial implementation and roll it out in a more slow and planned way is always helpful. One of the things we did is just go through every and I recommend this anyway from any system is go through every single feature you probably use in your current system so you don't miss them, and then just try to prioritize of like, these are the things that we need. I mean, one of the things we still use is planning center scheduling. We have been trying to move to rock scheduling for many years. It wasn't urgent. So it's like one of those, like, this will be the last year we're on planning center scheduling for anything but worship. But it wasn't like, let's go burn a bunch of bridges with our ministries to force them to use scheduling. We thought, gosh, small groups and check-in and that stuff was way more important. And data, we needed to know that data more to support our ministries than we did what volunteer was scheduled in what little tiny role somewhere. So I would say implementing too much too fast would probably be a pitfall to avoid. Along with that, just prioritize key features early on. I mentioned that a moment ago. Like just help your team really get used to a small, more limited feature set before you roll out other things. Another thing I've seen is like IT people, like we know systems and we know how they work. And we don't always like feedback. But not taking your end users and your staff and your volunteers' feedback and actually making them feel heard and doing something about it is a great way to lose trust while implementing a system. It's really tempting when somebody comes up and is like, hey, this thing's not working. Just to go, well, it does work. You're just doing it wrong. Well, maybe we just didn't implement it right. Maybe our way isn't the easiest way, and we just need to listen to them and go like, hey, if you're going to use this system every week, how would it work for you? We've made numerous documentation around check-in because of feedback for us. I love 99% of everything in Rock. I think configuring check-in for a one off class is the most difficult thing because it's here and it's here and it's here and it's here. And so we just have an online video. Like, if you're going to do a class and you need to check into work, follow these eight steps. And that's helped our staff tremendously. I don't have any great idea on how I'd make that easier, but it works great for our team. That was an area that we just felt was difficult. And our team I'd say as your team gives you feedback, encourage them to give you more. Because a lot of times if you respond incorrectly, they will not want to give you more feedback and then you will have more frustrated users. The next one is like overlooking customization needs. Rock is like a box of Legos. Like it comes with a good way to assemble it. But it can do so many things. And if your church has processes or has ways you need to do, have things you need to do, you can do all those things in Rock, but it planning ahead of time. And I've seen numerous churches go like, gosh, we're trying to shove this process into this thing, but we're using event registrations to do it because maybe that was easier than building a workflow. But then people are frustrated because it didn't go well. So I don't think, I don't know a church that like rock fits them like exactly the way it needs to out of the box every single time. So just taking time to go like, gosh, these are our processes, these are the things that like really matter to us, and these are what we need to customize. And that can seem overwhelming, but there's a ton of partners in the Rock community that can help you. There's big companies in there, there's individuals as you get to know them in the community that will freelance every once in a while and help people. The community might help you actually get it done. So I wouldn't get overwhelmed by like, gosh, we just need this little bit of thing customized. The idea board is a really good place for that. We've submitted numerous ideas where people have been like, oh, that's a good idea, and it ended up in the product and we didn't have to fund it. Or we've submitted little ones where it was like, gosh, this doesn't do maybe what we would we would want, and we funded $1,500 to get a little feature add in. So I would just say, like, don't overlook, like, the individual customized needs your ministry might have. Lead pastors don't like being told no. A lot of them like being told, not yet, but how can and then how can we get it done? We used to say on our team no to things, and we're like, actually, like, we can do anything. It just costs some money or a lot of effort. So we usually would come back. We've been amazed by the amount of times we've been like, well, that thing is $10,000 There's no way we're gonna fund it. And like the next day, the team's like, no, we'll fund that. Like, that's not a problem. Let's get some ministry win. It was just like, no, we just didn't have that in our team's budget. So bringing back like, hey, this is the vision, this is how we're going to execute it, sometimes cost kind of gets out of the picture. And this is probably one of the last ones, but installing too many plugins. I've seen this happen numerous times. There are tons of plugins in the rock shop and you think they can do everything. They're really easy to install but really difficult to remove. And you're stuck with consider every plugin a long term commitment to your church to keep updating forever even if you don't want it. Nick's laughing back there. But I just helped I helped the church remove like 58 plugins a couple months ago. And it was really painful. And there's like lots of exceptions to clean up. And I'm not 100% sure if you remove a plugin manually, you can ever install it again because I've not been able to figure that one out yet. So look at the plugin list. If you think it's what you need, install it. You can install all the free ones on the Rock sample demo server. So maybe test them out there, test them out in a sandbox. But I would say, like, don't go out and just go like, gosh, this groups thing looks fun. Let me try it out. Don't try it out in production. And that is, like, a learned lesson from experience from someone who has installed lots of things in production. So