Church Community Builder Introduces Twexting!
Oh tight! One of my favorite ChMS companies and the one I use at my home church has released a rad new feature that smashes together Twitter ans SMS text messages into one, rad communications tool! Here’s the release from their website:
CCB’s Twext™ feature combines the convenience of Text Messaging with the reach of Twitter™
COLORADO SPRINGS, CO, JANUARY 4, 2010—Church Community Builder (CCB), the pioneer of socially-based church management (ChMS), has released an innovative new communications tool that combines Text Messaging and Twitter™ - called CCB Twext™ - that will provide church and small group leaders with leading edge communications capabilities.
“Effective communication tools are critical for all churches. Because CCB highly values the interactive social nature of church communities, adding Text Messaging as a communication option was a no-brainer for us, states Steve Caton, VP of Sales and Marketing. However, we really wanted to take the next step by providing a way to seamlessly integrate texting with Twitter, thereby adding yet another communications vehicle to the mix where appropriate.”
CCB Twext™ Offers the Following Benefits:
Group Texting: In addition to email and mail merge, every Group Leader has the option to communicate with their Group participants via Text Messaging.
Twitter™ Integration: If a group within the church has its own Twitter account, the Group Leader can add that account to their CCB Group. When utilized, a Text Message sent to the group will also immediately post as a Tweet on the group Twitter™ feed. This further extends the reach of the Text Message to those who may not receive text messages but are a member of the Twitter group.
Member Controlled: Group members have full control over their ability to receive text messages. They must proactively edit their CCB profile before receiving them. This ensures people don’t end up paying for text messages they do not wish to receive.CCB Twext™ represents another major milestone and differentiator for CCB’s innovative church management solution. In addition to providing benefits to the entire congregation, CCB also offers the most robust communication tools to your leadership so they can remain connected to those they serve in the most relevant manner possible. For more information or to speak with someone at Church Community Builder about this and other valuable functionality, email sales@churchcommunitybuilder.com or call 1-866-242-1199.
OneBody: Open Source Social Network and Directory for Churches
OneBody has released an open source version of their social network and directory software for churches and I’m wicked excited about it!
<rant>
Churches spend a lot of money on church management systems (ChMS). Over the last year, I’ve had several discussions with those in the church tech sphere about the lack of a viable, open source ChMS. It seems to me that the thousands of dollars spent each year by churches on commercially available solutions like ACS, Church Community Builder, Fellowship One and the like could be better spent on stuff like feeding the poor and whatnot.
Please don’t get me wrong. I’m all for the companies mentioned above making a profit on their products (especially CCB, I love you guys). And I realize that an enterprise level ChMS coming out of the open source development community is a tall order so there will always be a place for them. However, I also think companies like Automattic (they make Wordpress) have proven that there is money to be made in the open source, web app market.
</rant>
OneBody has a load of valuable features including:
- Unlimited staff/admin logins
- Unlimited users
- Groups
- Online directory
- Data import/export (sync with your existing ChMS!)
- Social networking
- Campaign Monitor sync
- Custom themes
- and more!
OneBody also provides a variety of hosted solutions and development services to get your church up and running.
In the next week or so I’m going to install OneBody and give it a good going through. I’ll post my thoughts afterwards. In the mean time, I shot an email off to Tim Morgan at OneBody with a few questions. Here’s what he had to say:
Is OneBody meant to be used as a ChMS or work in tandem with an existing ChMS?
Originally, OneBody was built specifically to be used as a secondary,
slave database if you will, to an existing ChMS. Though in the past
year or so, I and several others have worked to make OneBody start to
become a viable ChMS in its own right. It still lacks many of the
features big ChMSs have, but could be a decent alternative for small
churches.
I hope to make that gap between a real ChMS and OneBody narrow a lot
more over the next several months.
Are there plans to release features like online giving, calendars/events, member management, etc?
- Online Giving - no plans at this time, but that’s mostly because I don’t feel like I know enough about this space to make wise choices.
- Calendars/Events - Yes. We have some integration with Google Calendar for groups, but a native calendar/event format would allow for a lot more flexibility, and churches are definitely asking for it in OneBody.
- Member Management - We have some limited functionality in this already, as I mentioned, but hope to improve it with time.
- Etc. - Yes, we have lots of plans for more stuff! 1.0 is quite milestone, but we’re not slowing down!
OneBody has a component built specifically for syncing data with an external system. We built it originally around ACS, but it is adaptable to any ChMS that can export data to CSV.
Are there plans for a plug-in type architecture for developers to add functionality to OneBody?
This is sort of a chicken-and-egg problem. We have a basic structure for plugins, but without an example of what is really needed by a real plugin, it’s hard to know what hooks and other APIs we need to provide in our code to plugin writers.
I assume the needs will become more obvious as people start to plan with OneBody more and think of things they want it to do.
In general, though, if a feature is useful to some percentage of churches over like 20%, then adding the “plugin” directly to the source code of the core product is what I usually recommend.
