Podcast Episode 202: Episode 175: Rock Tips and Recommendations

Description

If you're looking for a collection of Rock RMS tips and tricks from the core team, this is the RockCast episode for you. Join Emily Forman, Jon Edmiston and Nick Airdo in discussing classifying people data, how to approach structured content and the content library, the impact of server size on performance, tips for lightning fast workflows and more.

Transcribed Content

This episode of Rockcast is brought to you by Rock partner Triumph Tech, a full service specialist partner. Rock partners provide crucial support for Spark Development Network and important services for the Rock community. Connect with Triumph Tech today at rockrms.com/partners. Welcome to Rockcast, the podcast dedicated to the Rock community. Join us as we dive into behind the scenes happenings, offer insights into our community, and explore leadership dynamics. I'm Emily Forman, and I have here today Jon Edmiston and Nick Airdo. Welcome to Rockcast. Nick, we have been rocking and rolling around here. No pun intended. Where are we at? Tell us what's the latest with our Rock version update. We are working on version 16.6. So 16.5 is sailed and that's out there in fact, help my church get their system upgraded. That was fun. But 16.6, we're just putting in as many fixes as we can until we get the green light to start the next phase, which will be alpha testing. But I don't have a date quite yet. Okay. Well, lot of irons in the fire, lot of moving parts. Yes. So what triggers that to go to alpha? I know the answer, but I feel this is something that'd be interesting for people to know more about. Yeah, I think there's a number of things certainly critical, a bug fix. If we uncovered something critical, we would race to, and possibly even do some maneuvering to give a much, much smaller targeted fix. But short of that, I don't know, John, what's your favorite reason? Favorite? There's so many. It's usually when someone needs something that is urgent. Mean, or we get enough items piled up that it's , okay, this makes sense to now release. Yeah. That's the more relaxed version. But a lot of times something you said, an urgent bug will come up that will push out the release. Enough smaller things stacking up will push out the release or maybe a new feature that someone just really needs to move their ministry forward on a specific need. they need this for a specific date or a specific event, then sometimes that can push it out too. And we just don't constantly move to issue alphas because that wears out the alpha and beta team. So instead of continuously releasing alphas in 16.6, 16 point seven, 16 point eight, we kind of let try to pile them up and batch them up and then of then move on to V17, which we're still working on too. It's rare that a needed feature for one church is gonna push out a release. It's usually a critical bug fix or a stack of bug fixes that we just wanna get out the door. Yeah, mail, the one click stuff that happened earlier this year. Mhmm. , that was kinda one of those things that we Yeah. Needed to get that feature out so that everybody could move and start using it. Yeah. It does make me wonder how a product team that's less responsive and efficient could move as quickly as those announcements were coming out to accommodate that. Yeah, I don't think most products, , especially products I mean their SaaS products are a little easier because they control the whole stack and they control the whole release process. You don't even know when it's updated. That's a little easier, but especially when you have a distributed product, it's way more difficult to do that. And I think from Rock's perspective, there's pros and cons to SaaS versus distributed. I think distributed in some ways is really nice because the privacy is almost ensured. Ultimate privacy. Spark doesn't have access to your database. We don't have access to anything. And I think sometimes that's good. Now there are some churches who do have a SaaS version of Rock and that's good too because they don't have to worry about all these things, but they have their own instance too. So even whatever partner they're using for that shouldn't be looking at that data. Right. And there's no need for them to. We're in the SaaS model, you kinda have to because everything's intermixed. Well, is a very interesting point. Alright, John, what are our topics today? Well, we asked the community what topics are you guys interested in. So some of the ones that we kinda came up with, and some of them are ones that you asked for, some of the ones we added, because one of the things that people have been asking for is what are some best practices? Now, best practices are difficult because some of them are objectively a best practice, and some of them are subjectively a best practice, so we can only do our best. So one of the things that I've been thinking about, and in our work with churches we see is, what is it about a person? How do we categorize a person? What are the major attributes about a person that we look at? Now one is connection status, and I think we've kind of touched on that in the previous podcast is , hey, it's an underutilized tool, you should use it more. And we hope to in an upcoming podcast to even give some more ideas about how you might use it. So that's obviously one aspect about a person that you're commonly looking at. And if you're not, you're probably not using connection status, right? But I think another one that's undervalued is active or inactive. Mean, that's a huge classification. That is putting people in a very big bucket of , they don't appear to be doing anything or they do appear to be doing something. If done right, that's an amazing bit of data to know. And I think some churches do that really well. But I think there's a lot of churches who are not doing it well. And there's a couple or occasionally there are some churches who don't use it at all. You can literally go into their instance and there's very few if almost no inactive records. And so in a sense, they're just ignoring that feature, that aspect, that categorization opportunity of a person. I get that it can be difficult, but it's important. And we have tools built on the Rock that can really help the automation of that. There's inside of data integrity, there's a whole bunch of rules that you can put in place to inactivate and activate people. I really would highly recommend that you do that. And that you really kind of think through that, , what is your strategy? Do you want to be a little bit on the aggressive side of inactivating records? Or do you want to be a little bit more the timid side? And I don't think there's a right or wrong answer to that. I think the only wrong answer is not knowing and not having a thought, plan about that. My opinion is it's okay to inactivate. You're not making a judgment call on them, you're not condemning them to a lower level of heaven or anything. It's okay. So don't be too shy about it, especially if you have those reactivation rules running. It's not a problem. Because we work with so many churches, we have some data about inactive records. So we've worked with about 75 churches who've really asked us to look at their data and to help them understand it better and to look for things that perhaps are doing well and some things that perhaps that they have some areas of improvement. So 75 churches have asked us to go in and look at their records. And so we have some data around a metric that we look at, which is the number of active records versus the average weekend attendance. Okay? Now, so keep in mind, people who come to your church don't come every day. So your active records should be higher than the number of Or your average weekend attendance, right? You would expect that. So in our evaluation of the 75 churches, on average, it's about nine active records for every regular attender, basically on a weekend. So roughly nine. So if yours is higher, that could be something about your demographic, but it could also be your data. you might have a lot of inactive people actually marked active. Now, when you're looking at that, be careful because the spread of that data that we have amongst that 75 churches is pretty wide. So the standard deviation for that was about seven point one Wow, yes. So yeah, the standard deviation is quite large on that. So now, why would we say that the standard deviation large? Well, ministries are different, but I don't think the standard deviation necessarily comes from that. I believe the standard deviation, the spread comes from data hygiene. Some churches have really good data hygiene and some churches have really poor data hygiene. So I would say a majority of that comes from hygiene. So you might go do the little math yourself and figure out where you land on that. And then try to figure out what does that tell you about your church or your data? But I probably hedge to think that it's probably your hygiene. We've also done some research on that too, to see what percentage of the records are active versus inactive. And of the 75 on average, 52% of the records are active. But the standard deviation on that is about 30%. Oh, wow. Yikes. There's a wide range of people all over. Now this metric's a little bit different though, because it could be churches that have a very large historical record of people, they've done a good job of tracking people over a long period of time, would tend to have a lower percentage of active records because they've seen more people come in and people leave. So that one's a little bit harder to attribute it to just hygiene. I think it's just an interesting metric. But I think when the metric, can then create your own hypothesis about why yours is that way. If you don't have a lot of historical data, and it's quite high, then maybe that explains it. But if you have what you feel is decades worth of historical data and you feel the hygiene's right, and you're at 60%, your hygiene may not be as good as you think it is. Look at that inactive records, using it, consider maybe being a little bit more aggressive than you think you should be. If you're not using it, I'd probably say , Wow, you're missing a really important aspect of Rock. Not only does Rock help search people by looking at inactive, sorting them a little bit lower, But it's just a really good flag for your people to do that. Another good aspect that I think we talked about in the past, won't talk a lot about today, because I think we've really hammered it as photos, reminder, connection status, inactive status and photos. Get the photos in there. It really does make a substantial difference in the ministry when you see their picture and you can build that connection with them. It's transforming your data into people. Right. And it makes a big difference. Yeah, especially when you have to go make a personal contact. Yes. It definitely Especially if perhaps that contact is maybe not going to be You're perceiving it as to be a positive conversation to remind yourself that that is a person you're about to talk to and that person, seeing them helps relay that. Yes. They're not just a number and not just data. Another thing I thought we'd talk about too is the content library. Some people had some questions about the content library. Remember, what we do is not just about data, it's not just about church management, it's really about digital discipleship, digital strategy. And we don't want to be Sunday churches. We don't want Sunday Christians, all of our churches say that. But then in a way we model Sunday churches, Sunday Christianity our own. So how do we get people content? Now recognizing when you want to get people content, it's big task because you feel you have to make all that content. And simply put, you don't. The church should be a curator of content and maybe a creator of a little bit of content. But basically, curation is There's tons of content out there in the world. And the content library is a great source of basically using content that's already existing. So get out there, use it. You can use it in big ways, you can use it in small ways. I would say, just get started by doing something simple. Just grab a couple articles and maybe make a quick email and send out some articles to those emails or emails to those articles, or maybe just put one of the articles on your homepage, or do something small. Don't feel you have to , , do something big in order to use it. Now some people are asking, because it comes down to structured content. So the, there's two types of content in Rock. There's structured content, which is very JSON based, very structured, which is what gave its name. And then there's HTML content, which is just basically HTML that has really no structure because it's all over the map in terms of that markup. So some people have questions , well, I don't use structured content yet, but I know the content library is primarily structured content. So what do I do? The good news is we thought of that. And the good news is if you're gonna push content into the content library, you can just push your HTML, we'll fix it. We'll convert it to structured content, no problem. So don't worry about sharing your content to library, we got that. And also when you bring content down, we're smart enough to know, Oh, that content channel is not using structured content. So we're actually gonna convert the structured content into HTML markup for you. So good thinking about structured content, but you don't really need to worry about that. We've taken care of it on both sending and receiving of that content. There is more content coming soon. So we're just getting started with the content library, kind of where our vision of where that is going is gonna be much bigger than what's there now. But I would say too, yeah, just get in there, start using it and push on it. Another thing that is a hot topic always is the performance of Rock. And I think this is a lot of We need to do a lot better job of talking about performance and about your responsibility in performance. And the biggest thing I would probably tell people is, don't forget, Rock is powering your church, right? It's not this little thing. It might've started out that way. In fact, for many of you, did start out that way. Rock was just a small aspect of your church. But what happens over time is it starts to get used more and more and more, and we start adding more and more features. And in every release we have more features, but we also have made it more efficient and we've optimized it. So we're doing our part to make it faster. But unfortunately, we're also adding more features which get used and take more capacity in your servers. And we forget about that. And we forget about how much our churches rely on that. And then we stuff Rock on this little teeny server and then wonder why maybe sometimes it feels slow. I see it a lot of times in the community where we appear to be We talk a lot about how we're trying to save , $10.20, $30.40, dollars 50 a month, maybe a hundred dollars a month on a server that's empowering our church. It's at certain point, don't care. you want to have extra capacity on that because there's gonna be some time when someone needs that. Now, yeah, don't go burning $20,000 a month on your hosting bill, if you don't need it. There's some churches that are big enough that maybe even they need that, but for most of us, that's not the case. But if you're overly cautious about that hosting bill, I think you're doing a disservice to your church. It's almost you have the dog on the leash and it started as a puppy and now it's a full grown dog, but you have that collar around their neck the same setting as when it was a puppy and you're choking it. It can't get the air it needs. And it's a great investment to have that capacity. And there's been a few anecdotal reports of people who maybe upgraded their server just for one event, and then they forgot to bring it back down and their staff was , Woah, Rock 's really flying today. It's , okay, that's the exact example of someone who had the collar too tight on their puppy. And that tells you, that's how fast Rock should be. Right. Right. That's how it should operate every day. So don't stifle it, right? Give it the resources that it needs. But at the same time, once you do that, you also have to make sure that you're taking good care of it. For example, I think one of the biggest performing impacts to to Rock is is a lot of times is workflows, right? So how do you keep them from really suffocating? And there's a lot of settings that people often ignore. One is don't persist your workflow unless you absolutely have to. a lot of times you don't have to. In testing you might, because you wanna see it work and you wanna see it go, but a lot times you don't need to persist it. And you might say, well, need, I kinda wanna have a record that it happened. Well, there's a lot of other things your workflow could do to write the fact that that workflow happened. you might write an interaction. Writing one interaction is very quick. Don't forget when you say persist my workflow, you're thinking, we'll just save my workflow and that's not what's happening. You're saving the workflow, yes. But then you're saving every activity of the workflow. You're saving every action of the workflow. So when you say save work flow, you're actually calling save on a ten, twenty, 30, maybe 50 different things. And so don't be surprised when, Rock takes a What is a very short amount of time, but it all adds up when there's a whole bunch of them out there doing the same thing. So don't persist if you don't have to. Turn off your logging once it's not needed anymore, that's a really slow one. And then there's a lot of settings inside of workflow you should be using. For example, the processing interval. So that's how often you're saying, Hey, Rock, occasionally I want you to wake up and I want you to wake up every single workflow, shake it and say, Are you needing to be doing anything right now? So that's what that processing interval is. It's basically saying, How often should Rock wake up your workflow, shake it and say, Should you be doing something? Now most of our workflows don't really need that at all. They just take the user, the user is what's really kind of pushing it. User interaction is what's pushing it through its little cycle. And some of them literally don't need to ever be woken up and and saying, Are you supposed to do something right now? It's , No, someone will come tell me when it's time to do something. So in that case, wanna turn that processing interval really high. But even when you do need Rock to do that, it's often once a day would be fine, or maybe even once a week would be fine. And oftentimes the default processing interval is kind of lower because we need to make sure , well, if you don't tell us what should we do, we're gonna be a little bit more aggressive. And that's a big one, processing interval, I don't see people changing that as often as they should. Now it's often the case too that some of these workflows get started and they're just not needed over time. the person abandoned them, maybe they got a half started and it's they just left. Those will stay around forever, unless you start setting some of these settings that we've put in place. So one is the maximum workflow age. So at that point, when you set that, Rock will say, Okay, well at this point, if it's this many days old, I'm just gonna assume it's not needed anymore, market complete. And so again, look at the use case of your workflows, and many times simply aren't needed anymore. That person obviously, if it's two weeks old, they're not coming back. And that. So market complete and then that basically says, Rock, I'm gonna stop shaking this workflow every X number of minutes and see if it needs to do anything because it's been abandoned. And so we can't set that for you because we don't know your business requirements, only you can set that. And there's other ones too, settings that will delete a completed workflow after a certain period of time. That one doesn't really necessarily affect performance, but it can affect how much space we're storing in a database and the fewer things that we have to shuffle through to get the workflow you want, the faster that can be too. So back through that. So just to summarize on your workflows, make sure you don't persist them unless you have to. That processing interval is super important. Make sure you set your processing interval. And then look at the maximum workflow age and consider being able to close those automagically if you give that setting. So just a little tip there, best practice on workflow performance. There's also some pretty great videos out there I'd recommend. There's one that talks about the proper use case of workflows. Because I think when people first see them, they're , Oh cool, I can build applications with this. And you can, but you shouldn't. That's building a house of cards. This is a whole video out there that talks about how flows. If you think of an application as a body, as your body, workflows are really the muscles, right? They move things, but they're not really supposed to be bones. Imagine if you didn't have any bones and your muscles had to be the bones. You'd be a blob on the floor and that wouldn't be a very good application. And I think that analogy really holds true with workflows, is that they're really should be used as muscles and verbs to move things from different states or different types of entities. But the other entities really are the bones, connection requests, interactions, groups, people, those are the bones of it. And where we have seen people go wrong is people who's really develop a whole new feature and a whole new major feature just using a workflow. And sometimes it might be okay for the prototyping phase where you're just sculpting with clay, but you wouldn't wanna set that now out in the sun because it will melt. The danger is that someone sees it and they're , that works, go with that. Try to explain that to your ministry leader. Well, works right there, just do that. Well, that has 90 activities each with four actions. It's clay. It's gonna be unsupportable and probably has five bugs in it because how would you get all that working? Right. So I think sometimes this technology is we can get a little We can see how something works and we can get a little overzealous in how we use it. But they are great, not bashing workflows, love workflows. But we've seen a lot of people who built that and tower of cards and then realized it. And then when we recommended, Oh, really should have used a connection request and then have workflows move the connection request through those things. Then they redo it and they're , Oh my gosh, this is so much better and so much easier to maintain and to support. Sometimes it's not, the answer is not always connection requests, sometimes it's a different entity, but yeah. So John, a lot of times, we all work in dynamic environments and thinking about cleaning up this or checking that or auditing something, it just doesn't hit the top of our priority list. But you made a great list right here that if someone were to take and just say, hey, I'm gonna dedicate, , one morning a quarter to checking through these items on my on my Rock instance. There's enough quantity there. You could make a little block of time and make a big impact. Yeah, they always say, if you want to see what someone values, look at their calendar and look at their checkbook. And so what you're just mentioning is talking about looking at your calendar. And so in a sense, if you don't book the time, if you don't block the time, then you don't care. Mean, you may not wanna admit to it, there's a lot things I have to admit to that I care about, but I don't block the time. So I mean, do I care? So if you care about performance, yeah, you do need to block the time. Would probably say even once a month, should have a checklist of things you go check and then it might What you do that month might vary by I already did that last quarter, so I'll do this one instead. So yeah. Sounds a great discipline. Yeah, maybe once a year you have someone else come in and evaluate. I know there's different partners who can do that for you, kinda look into your instance and give you advice based on what they've seen and that's how some of this data comes available because some of those partners aggregate that data so that they can go, well, what is the right answer? Because when we started, what is the right answer on active records? Who knows? Until we go runs a few queries. But I think then having that data is really helpful. And someday we would hope to be able to kind of do that across instances that that's a feature, but right now we got 100x more feature ideas than we have resources in terms of funding and people to actually do it. So And that's a whole topic for another time. Yeah, man. You could fill That's an ongoing topic. A couple podcasts with that. But I think that the big thing is for the community to know, it's not we don't think about these things we do, but we have a very limited amount of funding and resources, people resources to actually get We can only get so much done every month. And so, how do we prioritize? How do we use that? I think to date we've been, this year especially, we've been prioritizing a lot of bug fixes. And I think that shows in a lot of things that we do. But it is a finite resource and I think that's what doesn't often, I think it considered by the community is that we are dealing with these finite resources and we have to It's almost a board game that you have to You can only spend so much money on each thing and we're limited by that. And honestly, you might think, well, do we get more say into that? And here's what I would say is , we're spending the resources more about More the way the community wants to spend it, we want to spend it. I mean, if it was up to me, I would be spending almost all on new ministry features. That's all I would do. But that's actually what we don't do very much of, because we're listening, trying to listen to the community. So don't, I don't want people to think that we get to decide and we just do whatever we feel it's actually, I guess we do get to decide, but we don't do it that way. we're listening to the community, even when we don't the answer sometimes. It's not we don't the answer, that's too strong, but would prefer to do it a different way. So, yeah. And you speak through the idea board. Very much so. But again, there, guys have so many more ideas than we can afford to do. So if you see the percentages of completed requests versus inputted requests, just know , yeah, that's reality. We don't have enough money to do all the requests. And some of the requests honestly, I've been there for a long time. Some of them are a little bit, we don't do them because it's literally almost some of them are black magic. Don't know how else to describe it. Are we supposed to do that? You get to step four and then wave magic wand and then happens. We're still trying to figure out how to make it happen. And so don't feel some of the older ones that maybe have some boats. A lot of them we've done, Most of them we do, but there's a couple of them I'm , I get it. I just don't know how to do it. I don't know how we would do that. Because I think another thing that's a challenge for us is , I kind of pine for the days where I only had to solve the problems for one church, right? Cause we could do things, we could go, Well, I know that's the way we want it done. I know that this data here is hinged on this. So I can go do this very quickly. for instance, I was thinking about it, I kinda to be able to build Rock this whole metric of number of active records over weekend attendance. Yeah. I don't know what your weekend attendance is in Rock. I don't know. there's no place in Rock for us to know that. So we're actually working on a project to kind of address that. So we wanna build in more metrics that. But if I just worked for one church, would go, well, yeah, know my It's this. It's ID 22. And I'd write a SQL statement that would say, divide count of active records divided by whatever it is, 5,000. Okay, there, I'm done. It took me thirty seconds, but for us to do it, it's , Oh, no. First, we need to figure out , how do we get that data to know the average weekend attendance? Then we have to go through and consider everything someone might consider active and active , and then we have to find a place to put it. Then it's, I mean, it's the orders of magnitude harder, a hundred times harder. Because the other one I would just made a quick little metric and then done. Right? And the answer is we can make a metric, but then what is the intent of the metric? Because we don't know. So that's actually a little bit of a clue. There's something called metric intents coming that basically can help you tell us what the intent of this metric is. And then we'll ship some out of the box that say, okay, well, we kinda to know some of these intents so we could do some cool things. Could you just help us label this? But we still don't even have that all figured out yet. It's way harder than it sounds. So those are some of the unique challenges to working in a community where it's very open and very flexible. Some of the benefits of working in this kind of community are the incredible people and the ways that they're using Rock to Power Ministry. And guess what? Once a year we get together to celebrate that in that time of year is coming very quickly now. So I did the math. We are just under nine weeks out from the conference right And I know I why'd you say that? I just anchored this podcast in time too, but it's coming quickly. And so if you're the kind of person that has put off getting your ticket, don't be that person any longer. We're having to finalize head counts and things and we need to know. And you need to be there. This happens once a year. If you have not been to Rx, you have not yet really experienced this community in action collaboration, vision casting, education experience. It's just impossible to describe. And it really does power your Rock experience and knowledge and connections all year. So make this the year that you're there. Join us for our tenth Rock Conference ever. And we'd love to have you, but hurry and get that registration and help us get our head counts. So we know how to plan to make this event great for everyone. Couple of exciting things at the conference we can pre talk about one, we're bringing back the community gold circle awards. So if you remember, that is where we get to celebrate the hard work and accomplishments of the community. And those are looked at by a panel of community judges, right? Not Spark, it's people in the community that are familiar with Rock and that are qualified to look at the design elements of projects as well as the ministry impact. And they're helping rank those and then the leaders in each of those spaces will receive what we call a Gold Circle Award. So that will be discussed at the conference. The awards will be handed out. What does that mean? That means we need your projects. Make sure to send those in. We have some communications going out with links to the submission form, and we'll put that in the show notes here as well. Let us know what have you been working on this year that has just a really elegant design element to it and that's making an incredible ministry impact for your church. Submit those, and let's give us the opportunity to look at them. We're very excited to be able to celebrate those. And remember the intent is not necessarily to get an award for yourself. The intent of the whole thing is to share those best practices and ideas. So it's almost we do this just so we can get better visibility to these projects. So don't feel you're going around tooting your own horn. Mean, it's really basically when you put that entry in, you're saying, I think I have something here that I think the community would to know about, because they might be inspired by it. And there's so much interactivity in the community as people are learning and growing and sharing, it's just another incredible way to get some visibility behind that. So please do submit again. You're not John said, you're not saying, hey, look at me over here. You're sharing something that has community value. Also, if the Rock experience isn't enough education for you, you can double your training. We have a master class that is directly before the conference the week right before. Also here in Phoenix, so you can extend your trip, have a little weekend to get away in between the two, do something fun and take in all the masterclass information that's going to really empower you to use Rockwell, then tune in for the inspiration and ideas that you can apply that knowledge to. So get that one two punch. If you haven't taken master class, sign up for it and and return back to your church really ready to go and powered up. Be a new person. You would absolutely be a new person. Two weeks, you did maybe make some brain bibs because your brain's gonna be leaking out. We always get excellent feedback from people about this particular masterclass every year and that combination of the class and the conference. So it's an excellent route to go if you've taken it and someone who hasn't, maybe they're not aware or thinking about this as an opportunity to do both, suggest it. It's a really great suggestion. All right. Now we have always built this as a two day event, but lately the past few years we've had a pre day. And so we want to make sure we're actually talking about that as well. So you can plan your travel around it. Our conference event is Wednesday and Thursday, August. But on the thirteenth, so that would be on a Tuesday of that week, we are going to have a completely free all day technical training content day. And this is really important. You don't wanna miss this. There's gonna be incredible content. And as we get a little closer to the event and publish the sessions, those will also be available for you to view. I would say just plan to come in and be there for that. Additionally, we have a kickoff event in the evening and more information will be coming out about that soon as well. But definitely plan not to miss this. This is going to have some important content and parts of the conference, even though it's kind of a pre evening. You'll want to make sure and build in the time to get there for this. Because it's gonna be way different than last It's gonna be incredibly different. It's not Dave and Lusters. Right. So don't miss it. This is gonna be something that just assume this is part of the conference for you. You'll want to be there. Okay. How do we do all of this? Go directly to the conference website, which of course will be in the show notes if you don't know where to find it and make sure you get your spot registered. We need to hear from you. We need to do it pretty soon. We're getting close. Those nine weeks are counting down. All right. Thank you so much for tuning in and and joining us as we share a little bit about what we're doing. We do it for you and we love to be able to share that information so you can see a little bit more behind the scenes of what it looks . Thanks for joining us. Make sure to subscribe so you get the next podcast episode when Rockcast is produced. Do a church that loves the idea of using Rock but hasn't taken that leap yet? With managed hosting, churches of any size can get access to Rock's amazing technology, hassle free. With just one click, Rock's managed hosting removes the roadblocks that might stop a church from switching to Rock by making the process simple. Churches get the ease of a SaaS church management system without losing any of Rock's powerful features. Are you ready to take the next step or share with another local church? Visit rockrms.com/hosting today.