Greenroom is where that knowledge lives. Every procedure, article, file, and handbook has an owner and a review date, so nobody has to text the one person who knows.
No credit card. Same day sites.
Every church runs on a few people who know how everything works. They built most of it themselves and they've carried it since, mostly without writing it down.
Then a campus opens and the same check-in procedure has to run in two buildings at once. Your production lead takes a job somewhere else. The volunteer who runs the switcher serves once every six weeks and asks you the same question every time. None of that knowledge got worse. It's just sitting in a few people's heads, and in a folder somebody built three years ago and never told anyone about.
Greenroom gives it somewhere to live that works at 7am on a Sunday, and tells you when it's gone stale.
The steps for running check-in and the answer to "where do I park" don't belong in the same file, so Greenroom keeps them apart. Each piece stays short enough to read in one go. Documents link to each other instead of swelling into the forty-page handbook nobody opens.
The correct way to perform a task. Every SOP names an owner who is accountable for keeping it accurate, and carries a review cadence. How to open the building, how to run check-in, how to shut the stage down after the last service. Written as steps, because someone is reading it standing up.
Answers to the questions that come up in the group chat every week. Where to park, who approves a facility request, what the dress code means in practice. Articles carry no owner and never expire, because most of them don't need to.
Stage plots, slide templates, printable signage, input lists. Upload them, or link out to wherever they already live (Drive, Dropbox, a video host) and attach them to the ministry they belong to.
An ordered set of documents, assembled into one page you can hand to someone. A guest services handbook is a collection: articles and SOPs that already exist, put in reading order with a note on which ones to read first. The originals stay where they are.
The one staff-side tool here. Assign a set of SOPs, articles, and plain tasks to a staff member with a due date. Greenroom records what they acknowledged and tells you when one of those documents has changed since. Volunteers are never assigned anything, because volunteers never have an account.
Applies to answers who a document is for. Church-wide, or one ministry. How a facility request gets approved is church-wide. The check-in procedure belongs to Kids.
Category answers what kind of thing it is: Safety & Security, Service Operations, Facilities. Categories cut across ministries, and they carry the review schedule. Set Safety & Security to review yearly and every document in it inherits that, so you decide the cadence once instead of on every page.
That's it. No folder tree, no taxonomy meeting.
Every document carries the same five facts, on the page, where anyone reading can see them.
2 documents have changed since Sam acknowledged them.
An out-of-date procedure gets followed just as faithfully as a current one. Nobody skips it. They do the old thing correctly. The handbook someone worked hard on two years ago is still training new volunteers, and it's training them wrong.
When an SOP passes its review date it says so at the top of its own page, names the person accountable, and offers one button to confirm it's still right. It also surfaces on the dashboard, so nobody has to remember to audit anything.
The same applies to staff. If a staff member worked through an onboarding checklist in March and two of those documents changed in June, Greenroom will tell you which ones. Otherwise you have a signature against a document that no longer says what it said.
Every document starts staff-only. Nothing is public because someone forgot to check a box.
When a document is ready to go out, switch it to anyone with the link and it opens for whoever is holding that link. No account, no app. Collections work the same way, which is how a whole handbook reaches a new volunteer in one text message.
Staff have logins, so what a staff member acknowledges on a checklist is on the record. Volunteers don't, so there's nothing to record. No volunteer list, no read receipts, no analytics, nothing to breach. That makes for a much shorter conversation with whoever approves software at your church.
Only people with a login for this church. This is the default on everything.
No login needed. Set per document, deliberately, one at a time.
yourchurch.greenroomapp.church, with your church name on it, live from day one.
Not every church says SOP. Some say playbooks, some say standards, some say protocols, and plenty say departments rather than ministries. Nobody wants to learn a vendor's vocabulary on top of everything else.
Rename any of it in settings and the change runs everywhere: navigation, headings, buttons, every menu. Your team never has to translate.
Leave a box empty and you keep ours.
Drive is good at holding files and bad at answering questions. It has no opinion about whether a document is current, who is accountable for it, which ministry it belongs to, or whether a volunteer with a link can read it on a phone without signing into a Google account.
Keep Drive. Greenroom links straight out to files that already live there. What changes is that the answers now have owners, review dates, and one address.
Then keep running on it. Planning Center schedules people and plans services. It isn't where you go to learn how something is done. Greenroom sits next to it and holds the reference material, and doesn't ask you to connect anything or sync anything.
You probably could. Rock has content channels, page-level security, and an LMS, and a church with a Rock developer can assemble something shaped like this in a few weeks.
The question is the second year. The thing you'd be maintaining isn't the pages. It's owners, review cadence inherited from categories, staleness that announces itself, and knowing which documents changed after someone acknowledged them. On Rock, the person maintaining all of that is your developer, forever, competing against every other thing the church needs built.
Greenroom sits beside Rock and doesn't ask you to connect or sync anything. But if your team would rather build it, build it. I'd rather that than have you pay me and resent it.
Keep it. MxU trains worship and production volunteers with a video library that isn't worth trying to match.
Greenroom holds the rest of the church: kids, guest services, facilities, safety, finance. And the things no video library can know, because they're specific to your building and your Sunday. Which door is unlocked at 7am. Which breaker. Plenty of teams will want both.
Then don't. Procedures, articles, collections, and ministries can all be renamed in settings, and the new words appear everywhere in the interface. It takes about two minutes and it's the first thing worth doing.
Some will read ahead of a Sunday. Most will reach for it in the moment they need it, which is the harder case to build for. That's why anything you share opens without a login, why pages are short, and why a whole handbook fits in one link.
Team leads are the ones it's really built for. Instead of answering the same five questions in the group chat each week, they send a link.
An afternoon to stand up the structure: ministries, campuses, categories, staff. Filling it takes as long as writing takes.
The sane way to start is with the six or seven documents you already have in a shared folder somewhere, then add one a week. Send them over and I'll load them for you before you ever log in.
Your site goes offline and nothing is deleted. Come back later and it's all still there. No exit fee, no retention call, cancel from settings.
Anything you linked from Drive or Dropbox was never held here, so it stays yours regardless. Documents written inside Greenroom live here, and there's no bulk export yet. If that's a condition of buying for your church, ask before you sign up rather than after and I'll tell you honestly where it stands.
I run the multisite switcher on Sunday mornings. Nothing about it is written down. It lives in my head, some of it changes week to week, and if I got sick on a Saturday night the person covering would be guessing.
That's why this exists. I built the first version for my brother-in-law, who leads worship at a church big enough that this is a real problem, and it turned out every ministry in the building had its own version of the same thing.
I'm the only person working on Greenroom. If you email, I'm who answers.
Grant · Greenville, South Carolina
Start with the five documents you already wish existed. Add the rest when you have time.