Podcast Episode 214: Episode 186: LMS, Mobile Chat, and Engagement Tools

Description

In addition to the General Release of v16.7, Jon, Emily, and Nick discuss many of the tools the Rock Core Team is currently developing including the Learning Management System, Mobile Chat, and engagement tools to spur discipleship opportunities for church members.

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 this episode of Rockcast. I'm Emily Forman and have today with me here Jon Edmiston and Nick Airdo. This is the podcast where you will learn all about Rock, the product, and the community. We're happy to share with you everything we're looking forward to here as we round the corner on 2025. So let's start with a little bit of a rundown of what we're gonna cover today. Of course, we'll discuss our product updates and that includes an update on LMS and mobile chat with a little bit more detail. Additionally, we're gonna talk through some engagement tools for churches to help their members engage with the spiritual disciplines on a daily basis, and discuss a little bit about a donation update and some additional community promos. So thanks for joining us today. We are ready to get going. Nick, kick us off with the latest on our Rock Version update. I'm excited to tell us all that we now We have released 16.7. So that patch is now out the door and it had a really, really good alpha and beta. I think it was probably one of the best alpha runs ever. Various issues were found and those are all fixed up during the alpha. And I think beta was pretty clean. So now we're onto V17 and an unlikely 16.8, but we don't have a date for sixteen point eight. That's just available should we need it? Yeah. We'll just start putting fixes in there and those will be in V17, but we'll kind of have it ready on standby. Great. So V17 then, what are we looking forward to, John? Yeah, we're starting to get the final features completed. So the big ones are LMS, which we are thinking is pretty much done. We'll probably catch some polish in the alpha and beta testing. You can actually go out there on the pre office server and kick the tires on it. The documentation for that, it's its own manual. So it's big enough that we think it warranted it its own manual. It's a little maybe small for its own manual now, but it will be adding more and more features to it. So for sure it deserves its own manual. But you can go out there and start reading about it. And I highly recommend that you read the documentation before you start playing with it. Because there are some key concepts that you have to understand, because it's actually two LMSs built into one. So I think just understanding that viewpoint and the two different types of LMSs, for most churches are only gonna be using one type, the on demand type. But for churches who have bigger residency programs, they can build out a more feature rich that comes with some complexity. So I think, probably don't wanna make that step if you don't need to, LMS also. So definitely read the directions on that one before you start tackling that. The other big feature for seventeen is the communication wizard. And we're very far along on that. We hope to finish that up here in the next three to four weeks. And then it needs a lot of shakeout and we need to do a lot of testing. If anybody's ever done HTML email, how difficult that is. And so we're gonna have to run the HTML that we create as you drag and drop things through lots of different testing using Litmus and other tools to ensure that what we let you build works on as many email clients as possible. So there's a lot of shakeout to do there, but we're making really good progress. There's other features still that we're waiting on, but they're smaller. Peer networks is pretty much done. There's just one little checkbox to check off on there. Adaptive messaging needs a little bit more work and polish, but it's almost there. Prayer automations is pretty much done. Just a few things. So there's a lot of little things that still need to be fit and finished and ready, but we're close. And so we're excited about that. So we're really, really pushing on getting that out the door. That's our main focus right now. At the same time though, you have to look ahead because if you just a % just work on 17, then it's done and then the developers have What next? To do. Because they need requirements. I think that's kind of interesting, the whole process of how a feature goes through the pipeline, because it takes a team of diverse skill sets to get a feature done. It's not the developers draw the tool, get the features, they're kind of the last piece of the pipeline. And so we have to make sure that we have the pipeline completely filled. Otherwise you get these gaps And that's not helpful. So we're already working on features for 18 in terms of working on the feature sets. A lot of those, we'll announce later. But one of the ones that is gonna be a part of the next version is chat. And so we've talked about that from a mobile project. And I think that, of course, that makes sense because a big component of it is gonna be used through Rock Mobile. But there's actually a lot that has to happen on the backside too. And I think it's surprisingly the case that actually more of the initial code will be spent writing back end integration than it will be for front end. So we're choosing to use, which is probably the obvious right thing to do, to use a chat provider. So they provide the backend infrastructure, but they also provide a lot of the UI components. That's not to say that nothing needs to be done, right? You to still do a lot of work to get the UI components all put into place, but we also have to integrate to it too. So we wanna make sure that from an integration perspective, single login should be a Rock login, person shouldn't know that this is a separate thing. So we have to get that authentication piece done. But more so, how you use Rock or chat with Rock, it has a lot to do with groups. So a lot the use cases , I want my small group to be able to have a chat feature. Okay. Well, we need to get the channel, which is what it is in chat linked to a group. So sounds kind of easy, but trying to get all that working the way you'd expect it. So if you add someone to your group, they can immediately start chatting. That takes a lot of plumbing. And so we have to get that plumbing figured out. On top of that, we have to figure out, okay, well, what about some the use cases maybe that aren't groups? So I have a public channel, how does that work? And how do we know who's in that channel? Who should be in the channel? And so we're linking all that to groups too. So there'll be a new group type of public channel. And so, even though you may not see it as a group, or consider it as a group, it will be a group in Rock, so that we can know who's in that group and do certain things with that. So that means that we have to also think about things , well, how do I measure someone's engagement with chat? I mean, it's pretty As you think about this, you're , well, of course, I'd wanna know who's engaging in chat. Well, how do we know that? Don't want How do we do it quickly and in the right way as you want it? I think it's likely that someone's going say, Well, I want to to be able to have data views. And I want data views to tell me who's been involved with chat. So how do we build that in so we get that very quick? And so every night we will have a job that goes out to the chat service and basically writes interactions for every person in every channel. And we're not gonna sink their chat data over to Rock. Would be a lot of data, it'd be very complex and probably another security issue, because now we have to protect these messages. And so we keep the messages where they belong, which is in the chat service, but we're gonna write back an interaction every day for every person in every channel. So Ted Decker in the general channel had three messages. If you wanna go see the messages, you gotta go in the chat channel. And then that's not something we're really interested in phase one. ? It would be bringing the messages into Rock. Well, we can go through API to go get the messages out of Stream. So eventually in phase two, three, whatever, we might have a block that you can go look at chat messages inside of Stream. we're not gonna bring over to Rock, but we'll make a UI that view into the chat provider. And that's more for just accountability and we're not interested in reading people's messages, but when something bad happens, ministry staff need to be able to assess what happened. In phase one, administrators can go into the chat to itself. it has a backend long term. We don't want people to kind of have to worry about that backend because it's not necessarily the most user friendly backend. It's not terrible, but if we can give them a nice UI inside of Rock, that's better. But yes, there's a lot of work that needs to happen with that. And then there's a couple churches who are pioneering this feature, who are helping to pay for the feature. But also, I think almost more importantly, are gonna help pioneer how used. I think the use cases in terms of having a small group chat, that's pretty obvious how that might work. But I think it gets a little bit more wild west when you think about public channels. How's that gonna work? What are people gonna run into there? Everything. Yeah. How do you handle that? It's almost more of a communication problem than it is a technology problem and messaging. If someone's asking for money, how are you gonna help that? You don't want your channels to turn into money ask. But at the same time, we want to help people. But that's the things that each church will be learning and sharing. And there's a lot of other great use cases. We're working churches on people who are basically saying too , Hey, we need to communicate with new people to the church who may be a little bit hesitant about sharing their SMS number, or some lay leaders who maybe want to work and help people get involved in ministry, but don't necessarily want to give out their SMS numbers to a whole bunch of lightly connected or unconnected people. That's a permanent thing, right? You can't pull your number back. And that's fair. Yeah. And I think it's really interesting how we could use this tool for much more than just the traditional just chat features. How does it become a really great communication tool? So there's some really interesting discussions going on around it. But first step is to get it written, get the syncing technology in place, get the UIs in place. Then in phase one, we will not be anywhere close to being done with a feature. It'll just be minimum viable product, but we're excited about it. So that's definitely something that we're working on right now in terms of getting the requirements nailed down, which I think they are. And soon, hopefully even next week, we'll have a developer starting on the back end syncing logic. That'll take some time. I know we're starting next week, but don't It's going be a bit. We won't be done the following. Right. Was surprised going in, just thinking, Oh, well, this won't be too bad. We've done these types of things before. It shouldn't be too bad. But the more you get into the details, the nitty gritty of, Oh yeah, right. Yeah, that has to happen almost immediately. And what about this use case? What about that use case? And then you have understand the API from the other side too. Sometimes it's well considered, it's a good API, but you run into things that maybe they didn't consider because we're doing stuff a little bit different. Definitely, would say the model of SaaS is interesting because everybody's , everything's SAS now. So the concept of having churches with their own databases is , why are you doing that? Well, churches want to own their own data. SAS model, we love it, but at the same time, doesn't fit everything. And I think a lot of people ask in hindsight, do you wish Rock was more of a SAS model? And I think from a funding perspective, yeah, that'd be great. But I do think from an extensibility, there's just no way. , if you think about the concept of defined values and define everything that you can do to to create this Lego kit, and now it's supposed to be a shared Lego kit, and you're not supposed to have someone else's new piece intersect with your piece, and , it'd be There's no way we could have the extensibility of Rock and and have a single database. So in some ways, it's , yeah, no, we we don't wish it was SaaS. But that does make it more complex. Especially when you start integrating with tools the chat providers, because they kind of look at us and go, wait, why do you want to architect it that way? It's , well, it maximizes what the capabilities are for protects the church, which I should say is our client. It was kind of interesting even just having to talk back and forth with them on how we arrange and configure and architect it. Now, the chat services is also, the way we architect is gonna help save money too. Because the way we're planning on this is not every church needs to go out and get their own account at the chat service. We're hoping to share an account so that pricing around that always deals with monthly active users. And so it's actually cheaper if you can bulk buy your monthly active users than if you all go out and there's minimums. And so most churches wouldn't even hit, come close to hitting a minimum. So they're paying for stuff they don't need. So by bulk buying, we can save the church money too. And John, the chat service is SaaS, right? Google or Yeah, but not Google. Right, right, right. Yeah. So they just do chat. And there's a lot of things we're gonna to figure out too, around moderation and it has that, but what does that mean? And how do we do that in a way that even though we're all working one account, there's this tension of everybody wants to do it their own way. Because obviously there's lots of settings, but we can't support every setting and we don't know. So we're gonna learn a lot working with the initial churches on what works, how it should work. But even picking the service has been difficult because there's a few market leaders, But there's not a clear winner of who's the best. There's best in all kinds of areas, scalability, UI, UX, maybe forward thinking, backend interface. it's just hard to It's always hard to make a decision because there's always a trade off. And we're trying to maximize the benefits. So, yeah, it's been way more difficult than It's interesting because you're giving a peek into where we are right now in the lifecycle of this feature. And we do have to run feature lifecycles differently because of our model and for various reasons. But from This is a feature that's been talked about and there's been a lot of interest in for a long time. And sometimes I think it can feel there's a slow start to getting to the development of a feature. But there's so much packed into the very early stages. It isn't just a good idea and then start coding. There's so much that comes into the R and D and the considerations and the The crock potting. Yes. Yeah. If you to redo things, go ahead and move fast. Anyway, you won't actually reach the finish line, because you have to restart over. And even just picking the service again, it's a little bit, don't if stressful is the right word, but there's this fear of when you get deeper in, what does that really mean? As much as we go deep, we're definitely reading the documentation, we've done prototypes. Have a functioning prototype, but what does that really mean? And then, I think the hard part is, it would be so much easier for only solving one person's requirements. Exactly. But already we've gotten other people who are now interested and they're asking for features that honestly, it doesn't do. And honestly, shouldn't do, right? It can't do. Because someone might highly want security. Well, security comes at a cost. If you have, say end to end encryption, you can't do moderation. It just doesn't work. But I think if you're looking at, do you want this new chat feature to support end to end encryption? We'd all wanna check that box. Yeah, that's of course we want that. That's the best that exists right now. Oh, is that okay, but you don't want moderation then? It's , well, no, I gotta have that. I have to have that. Okay, well, you have to have one or the other. So we have to live in this sticky middle where we're trying to solve as many things for churches as possible, but these requirements are in conflict. Yes. And it's not unique to chat. This happens every day where the features are in conflict with each other and we're trying to resolve that conflict. And it's not the churches resolve the conflict between themselves. We have to try to find a way to do both and, or sometimes to say, Okay, sorry, we can't do that. Now in this case, I think the community has made it pretty clear to us, at least the churches who have been involved in the chat project, that moderation is a key feature that we have to have. we have to understand what's going back and forth and we have to have tools that prevent certain types of conversations or certain words or certain images. So to me, it's this one's a little bit easy. I get the end to end encryption is always something I would love to have too. But as a trade off for moderation, I'd be , nah, we're not No. It's so public facing. You couldn't go without that. Yeah. Now if it was a bank doing transactions back and forth, well, then the moderation doesn't really matter too much because what are you gonna do? Only person who's see the bad word is you and the system that you're talking with, or the employee at the bank you're talking with. So moderation, okay, throw that out the window, because that encryption is so important. Or if I'm talking to a friend, it's a Sure. Through iMessage or something. Well, of course, I don't want Apple moderating my stuff. They shouldn't moderate that. That's none of their business. But now you're dealing with the church. Holy cow, this is a public, but no, this has to be This wouldn't replace signal or session or telegram if you're wanting to chat with your missionary in a secret state around the world. Yeah. That said, now you get into even the metadata will out you. Doesn't matter what the message is, but the metadata of you talk to someone here, that's good enough to probably send you to prison. In certain places. Yeah. But it's all those things that we have to think through that make it difficult. And again, when you're trying to maximize the impact for churches, which means you're trying to I mean, you could translate that message into, we're trying to please as many people as possible. It feels bad when you have to say, Yeah, we can't do that. Because that way we can't do this. And sometimes they're limited to the tool set too. , well, tool doesn't do that. There's ways around it. You can provide an additional layer of encryption on top of what they're sending across. But again, I go back to , we're not the bank. Much much as these conversations are sensitive, they're not state secrets and they're not financial Transactions. And and we do do financial transactions over non encrypted end to end encrypted. SMS. Text give. Text to give. Right. Oh, okay. But if I'm just talking to my wife on iMessage and then encryption, sure. Okay. We don't need moderations. My jokes aren't that bad. Okay. Moving on. I'm not bad enough to need moderation. It might be not funny, but anyways, there's just a lot of things to it. Yes. And that's what makes it so interesting is considering the life cycle that every one of these features has to go through so we can maintain extensibility, make the right selections of what to integrate with, get the right input from the people who are using it. It's very complex. Yeah. When it even goes into other things that are non technical about the vendors, have to make sure what is their viability in the market. Because if we write all this and they go to business, oops. So we have to look at their Who's investing in them? How much money do they have in the bank? All these things that you As much as you do the due diligence, can't guarantee. And depending on how emerging the technology is, can be hard to determine at sometimes. Yeah. Because even sometimes what I've learned in my career is not always the best technology wins. And not always the best and smartest people win. And not always the best organization wins. I mean, if I think back to it, when I came out of college, I'm so fortunate to have come out when I did, because it was the birth of the internet. It was such an exciting time and the best technology, the best people, and the best companies lost. Netscape, Sun. Mean, open standards. That was The whole word open standards is kind of weird now because it's back then, was a mission. It was a war. Open standards against Microsoft, against Oracle. And the good guys lost. The people who should have won lost. Now they they kinda didn't didn't, but , Marc Andreessen, you might be familiar with him from, , he's been on Joe Rogan recently and he's kinda becoming a household name more and more, but he was the original guy. He's the guy who made the first web browser. He was the guy who not necessarily started Netscape, but he was their primary technologist. He lost and he shouldn't have. So it's hard. It's , we're investing all this money that we're being asked to shepherd and steward. If we make the wrong call, it's , whoops, that doesn't look good. And in hindsight, always , why'd you make that choice? Everything's easier in hindsight. Yeah. But I remember sitting in meetings at Honeywell. These are at the top top top level of IT and watching them make the wrong call. And for political reasons. It was an evaluation that was a a terrible evaluation. Was all done in politics. And that's when I heard the phrase for the first time, in the sense I've heard a lot , well, no one ever got fired for buying IBM. No one ever got fired for buying Microsoft. they didn't care. The people, the technologists at the top of the organization did not care about the product and being, not one of the people at the top of having a seat at the table, it was very frustrating. It's , this is the way forward. But yeah, it didn't happen. So that's why it makes it even hard to make these decisions because again, I don't want to be making it the way those other people did it, which is , well, don't bet against Microsoft, don't bet against IBM, but trying to pick the best technology, but the one that will be around too. Because I guess in hindsight, even though Netscape was probably the right decision, I guess it wasn't. Because if we had picked it, we'd have been the only organization other than I think Motorola. Right. Yeah. It's not a unique thing, right? Many companies are making all the same bad decisions, but the cards you have to play. But interestingly enough, the few companies who made the quote right decision actually lost in the end. Because , yeah, Motorola, and then had to go eventually. Yeah. We had a division that was really invested into Netscape and all their products. Yeah. Yeah. So it's interesting, but fortunately, I even before that point in Honeywell, I was in a right when they came out, they put me temporarily in a commercial off the shelf packages group. They were trying to start one up and they're , Okay, we'll go help this guy start that up. Boy, I learned a lot about evaluating and making your rubrics for commercial off the shelf packages, but talking about boring. He's sitting in a lot of vendor meetings, asking questions, which is a good education, but I didn't really enjoy that too much. But it helpful to think about those rubrics and understand how to make those decisions. Wow, we got really off on that. We really did. And we talked a lot about the feature set and the product and the platform, but really where the magic comes, where churches are able to connect with their people and help drive ministry forward, requires a base of the right technology, but it also requires a great strategy. And it's been interesting the number of conversations that have been happening lately around how to engage people more on a regular daily basis outside of the weekend services. And Rock has so many incredible tools that can be used to help that, but you really need the right strategy, and then you need to combine those feature sets in a way that can help you move that forward. That's been a pretty hot topic, wouldn't you say, John? Yeah, definitely within our working with churches on digital ministry, that is a very big thing. And I think right now it's a hard not a hard thing, it's a project type that takes diligence and effort. All the best projects do. It's not easy. And I would probably just encourage everybody right now, it's the beginning of the year. So we're thinking about , well, how do we want 2025 to end up? And , don't think too much about what your plans are for improving the administration of your church using Rock. That's gonna happen. That's the easy thing. Think more about how are you gonna make the ministry happen through Rock? Because that's the hard thing. That's the tension that doesn't get as much a strategy put towards it. And I think just, we have this great tool, how do we use it? I think one the things is in creating these digital engagements. People are dying to understand how do they live their spiritual life out day to day. I think the church has been really good at talking about that. Because before we didn't really have a lot of tools you could talk about and then they'd have to go do it, right? Okay, go read your Bible. Here's a handwritten, not handwritten, but here's a printed reading plan, or here's a tool that will help you read through the Bible. It's so much more of your daily spiritual pathway has to be more than just Bible reading. Has to be one of most important things, but it has to be more than that. And now we have these tools, prayer is an important piece of that. Not only do the person praying get something out of it, I'm praying for people, but churches also have a backlog of people who need prayer. Yes. It's a perfect match. You have people who want to pray and people who need prayer. So how do you bring together these tools where you're doing Bible reading, praying for the people in your physical community, the people , and then whatever else you want to stack on top of that, in terms of praying for ministries, missionaries, events maybe going on at your church. how do we build these daily tools for them? I would say it's not technically hard, but it is difficult because it takes effort. And a lot of times the biggest problem is content. And a lot of that starts with this having to talk with your leadership about, sell the vision of this, what it could be. But then you also have to equally sell the cost and it's not always monetary, but it's gonna be effort, which comes down to resources and people, which obviously comes down to money, I guess. But I think we need to keep pushing forward on that. There's a few churches who have done it LCBC summit, they've shared that at RX. So definitely go back and watch those sessions. And just realize those are the first implementations. Those are by no means the end all be all, they are for the moment. But I think when we all look back in five years, we'll see that those were catalyst stops that really had really good thinking. And we're kind of pivotal in starting it, but I'm sure they won't be doing the same things. I mean, we're already talking with some of them about making some updates. So but I think every church should be thinking about that. How do we get our people engaged in a daily spiritual engagement and what tools can we offer them to do that? And when it comes to content, most churches have a plethora of content that's already available if you look at it creatively and in a different manner. Yeah. And that's why we're also trying to provide as much content as we can through the content library so that it doesn't have to always be. And I think that, again, what I've talked about Rx several times is curation is the only answer. There's no way you can satiate everybody's appetite for content. You have, you said, Emily, there's a lot of content there, but there's not enough to satiate a daily So you have to go find that other content and you have to be okay with it not always having your name on it. Or you have to have the resources to repurpose it, redo it in a sense. But I'm always surprised at how much good, good content is on YouTube shorts or now Twitter has it too. Some of it could be repurposed pretty easily. it's not copyrighted. For example, I found one, I'm pretty sure it was on Twitter. And I'm pretty sure I reposted it, but it was about whales and how whales die and how that relates to our spiritual lives. And so, hint, you should go watch it. It was amazing. It blew my mind. That's the kind of content, , why shouldn't we give that to people every day? Why can't we curate that content for them? Because if we leave it to them, they won't do it, most of them. Or if they do do it, they're gonna have to figure out what is good theology, what is bad theology. And that can get a little dangerous. Yeah. There's a lot out there. Yeah. And I skip over a lot that too, I'm , oof. But I don't think about it because I feel I'm able to filter that. But if it was someone brand new to their faith Mhmm. I don't know how they know that that actually isn't biblical. Yeah. I don't know. So those are the things I would work on. , I know there's just gonna be this There's always this daily draw, , to work on that report that someone's screaming for or to work on I think the key word in IT, which I've gotten some flack for is no. Because I think in some IT departments, they want to be yes. But my response is when you say yes to one thing, you're saying no to an infinite number of other things. So you might the word yes, but you actually, if you're being honest, you're saying no too. You're just not actually coming out of your mouth, but you're saying no to everything else you could be doing. So you have to be really careful what you say yes to, and you should say no more than yes. But it takes time to strategically plan for what you're gonna say yes to. I mean, we have to do that here. There's a million things I'd to be doing. And I'm guilty of it too. Have to go back to my desk and do some things that I feel I just have to do, but they're probably not the most strategic things I need to get done. But if I don't do them, ? And so it's hard to say no to things. Mhmm. So churches are kind of in the same boat we are as we're evaluating features and trying to figure out how to bring something to life. This is a good point to stop and say, how do I bring this concept to life? How do I sell my leadership on it? Where can I find the resources needed to do it? And what tools and platforms work really well? And mobile app is actually an ideal method to distribute and engage with people. Yeah. I think when we do the mobile apps, it's important that you Even if you're going to start small, because I think that's a lot of people do that and that's a good thing. It's okay to start small as long as you also start right. I think a lot of people start small and they just throw something not very well considered together. And that becomes the foundation then that you have to build off of. So we've had some people come reach out and say, Well, I wanna do all this new stuff that I keep hearing about on my current mobile app, but it wasn't created very well. And it's , well, shoot. Not much we can do with that. I mean, you could keep building on top of that foundation, but it just the little analogy, if someone didn't put a foundation in, you can keep building up, but it will eventually fall over. Or you'll see that the walls aren't straight and people will not just I mean, your people will see that the walls aren't straight. And so it's hard because , they got going a little too fast and just wanted something cheap. And then you have something that you basically have to throw away and redo. That's not, no one wants to hear that. And we don't want to say it, but I would say just , start with a good foundation. Don't always just go with , whatever's the cheapest. You get what you pay for. Yeah. I mean, that's sad. I mean, as long as you knew, and as long as you understood, because, , but it's likely if you go the cheapest route and you don't ask the right questions and it's not built right, you're going to have to redo it. And it actually sets you back because now it takes more time and sometimes it's harder to undo a mess than it is to start fresh. That's a great point. And what is really interesting about all of this? It's funded on donations. All the things we're talking about, the platform, the community engagement, the number of churches coming together and sharing the things, all of this is communally funded by the churches that are using Rock. And it's an incredible, it's really hard way to work and operate, but it's been super successful because of the churches that care so much about what's happening here that they're pouring into it and providing the avenue for the innovation and the avenue for the research and the building, the development, the community building. And we just finished up 2024 and it's just amazing to see the number of churches that made solid commitments and met those by the end of the year. We had a few where maybe something was off a little bit, but in many cases, it was an example of a payment process changed or a staff person turned over and something got accidentally missed. And nearly every church that we reach out to about that is pretty quick to fix that. And so we're just super grateful and wanna make sure the community knows that this team effort really is possible because of the generosity of each church using Rock. And we've been able to really watch expenses carefully on this side. We've had a lot of churches come through with the donation increase that started a year ago for the early access level to $4.1 per average weekend attendee per year. And so I would just encourage those churches that weren't able to get their commitment to that level in 2024 to make 2025 the year that you bring that up to the early access level. It benefits you in a lot of ways because of early access, but it also helps with keeping the donation level in the right size and the right scope for the growth and adjustment of what we need to do on this side. And there was a planned increase for 2025, but we were able to defer that for a year. So do expect a slight increase this time next year. And if you're able to get up to the 4.1 in 2025, that will help make that a little bit easier. So let us know if you have any questions about that or need help with a conversation with your leadership. That's something that we routinely do as well. I hope people see by deferring that. It was actually more work for us to defer, right? Because we've already had all this communication out about it. But I hope it shows that we're not trying to figure out how much money we can get. We're trying to figure out what do we need to get the job done? And we're willing to even do more work to undo it so that the money's always put in the right places to maximize. We realize churches are running on donations themselves, and that's important to us. I mean, we have a background of working for churches too, that stewardship is really critical. So we are partnering with churches in maintaining the highest amount of efficiency and stewardship possible. So thank you to our listeners for everything that you do to help support that. We also know that a lot of people are interested in what are we doing for our conference next year or this year. It's 2025. What are we doing this And the answer is we can't quite give you the details yet. We wanna make sure we have a contract in place before we start promoting it, but we're getting very close. And this is a top focus for us. We love bringing the community together on an annual basis, and we want to make sure we pay attention to your feedback and we incorporate that. One of those has been, can we bring the ticket prices down? So we're doing a little exploration this time around to see what we can do with a venue change and some other things to accommodate that for this year's conference. Yeah. We've been through a couple of plans. We sure we're plan C right now. Yes, we are. It's actually a pretty good plan. If we'd known about, I think from the beginning, it might've been a plan A. Yeah, so excited about that. But I think the key is for you guys right now, make sure you're already planting seeds in your leadership team to at least have one of them come. Our goal is to get more and more leadership. Those who did go, we got glowing reviews from them that they now understand this better, which what? It's a huge benefit to us when they understand it. But what? It's a bigger benefit to When they understand what you do and they get your world, oh my gosh, your life gets so much easier. So while it's very good for Spark to have your leadership there, it's actually more important for you to have your leadership there so they understand your world. And I think it'll be amazing to see the different levels of support and cooperation you'll get when they understand your world. That's so true. Nearly a % of survey feedback that came in related to bringing a leadership team member with them started with, now they get it. Yeah. And is So consider that, that could be something really helpful. And a lot of the ideas we have about changes is about making it even easier for your leadership to come. More details on that, but just realize that if you think it's gonna be just 20 or RX 24, it's not. We're going to try to keep the best of it, but there's going be a lot of changes and part of it to keep costs down, but other part of it is to help get more executives there. We're already looking at some guest speakers who I think are gonna be interesting to your executive team too. So definitely be planting seeds. Mhmm. Don't forget, while you're planting seeds, the classes are open for this year. One to two timeframes for every class that we offer. So whatever training your team needs, just go ahead and get those signed up and booked early so that you have access to the spaces. Some of our classes tend to sell out every time and you wanna make sure that you have a chance for your people to get those slots. Yeah. All right, that has been a very newsy update and peek behind the curtains at what we're doing right now. Thanks so much for joining us. We appreciate our listening audience and wanna encourage you to make sure you're up to date with the next podcast, because this is our primary way of communicating to you what we're working on and what that looks . So be sure to subscribe wherever you get your podcasts and you will get the next one automatically pushed to you. Thanks so much for joining us. And we look forward to sharing more next time. 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.