communiZate
The system your team relies on shouldn't make their work harder.
communiZate finds where your processes break down, then fixes the workflows, systems, and handoffs that keep your people from getting work done.
The problem
You bought the CRM.
You rolled out the service desk.
You set up Planning Center.
You built the forms, the workflows, the automations, the reports.
And your people are still using spreadsheets.
Requests still get lost.
Approvals still live in someone's inbox.
People still ask, "Who's supposed to do this?"
Your system has become something your team works around instead of something that helps them work.
That's not a software problem. It's a process problem.
communiZate finds the friction between how work is supposed to happen, how the system is set up, and how your people actually get it done. Then we fix it.
What I fix
Your CRM, ITSM, ESM, PCO, or other operational system with a new acronym no one knows has turned into something your team has to fight just to get work done. I find what's creating the friction and rebuild the system around the work.
Too many steps. Too many handoffs. Duplicate entries. Manual work. Unclear ownership. Approvals stuck in someone's inbox. I map how the work actually happens and cut what doesn't need to be there.
The old process wasn't wrong. It worked when it was built, and then the work changed. Now it runs on spreadsheets, sticky notes, and "just ask Bob." I help your team move to what works now, and make the system usable again.
The approach
You don't need a report telling you what's wrong. You need someone to help fix it. The assessment and the cleanup happen in the same project, because a system doesn't get better from a document. It gets better from doing the work.
Before I change anything, I sit down with the people who actually do the work, not just the people who own the system, and ask why it's built the way it is. Data tells you what's broken. People tell you why it broke, and what will break it again.
If something obvious can be fixed now, I fix it now, while I'm still figuring out the rest. Nothing gets parked for a phase two that never gets funded.
The bigger rebuild happens in the same project, built around how your team actually works. The goal isn't a prettier system. It's one that holds after I'm gone, not just while I'm in the room.
Most people only ever enter their own business through the back door - the staff entrance, the admin login, the internal ticket queue. They've never experienced it the way a customer does. That's the first thing I ask you to do: walk through the front door, not the back.
Who this is for
Same process. Two tracks.
Service managers · Operations leaders · Founders
Your systems grew faster than your processes did. I find where the work stalls and fix what's underneath it.
Pastors · Administrators · Volunteers
You don't need another platform. You need the ones you already have to actually work. Giving, check-in, follow-up, and the handoffs between them, fixed at the process level, not just the database.
Track record
Owned and rebuilt service management systems across multiple organizations and industries - Remedy, Cherwell, Zendesk, Freshservice. The platforms, places, and people changed. The underlying problems never did.
Built procurement, hardware lifecycle, ticket handling, documentation, employee lifecycle, and service management processes when there wasn't a usable process in place - and rebuilt them when the existing one stopped working.
Took a large organization's support operations from paper, email, and tribal knowledge to a unified enterprise service management platform spanning multiple departments.
Directed multiple organization-wide Microsoft 365 rollouts and owned the communication, documentation, training, process, and adoption work that made the technology usable - not just implemented.
More than 100 people led across multiple organizations and industries - students, contractors, and career professionals. For more than two decades I've been translating between executives, developers, administrators, and the people actually doing the work.
Different industries · different systems · same problems
Speaking & coaching
These aren't slide-deck frameworks built for a stage. They're what I've taught every team I've led for most of twenty years, worked out in real service desks and real churches first.
Keynotes · Team workshops · Ongoing coaching · In person or remote
The "Three Jobs" framework: get in your hours, take care of your team, take care of your customer - in that order.
Why chasing SLA and CSAT numbers produces worse service than teaching people to focus.
Mining your own customer reviews to find what people already say you're good at, instead of guessing at your own pitch.
How passive-aggressive habits creep into remote and hybrid teams, and what actually fixes it.
Questions
Start with the process, not the platform. Most broken workflows come from how the system was set up and how the work changed after, not from the software itself. Map how the work actually happens, talk to the people doing it, then rebuild the workflow inside the system you already own.
Usually because the system was built around how work was supposed to happen, not how it actually happens. When a system adds steps instead of removing them, people go back to spreadsheets and email. Fix the process underneath it, and the system becomes the easier way to work again.
communiZate works with churches and ministries to fix the processes behind Planning Center - giving, check-in, volunteer scheduling, follow-up, and the handoffs between them. The problem usually isn't the database. It's how the work moves between people, and that's where the fix starts.
A system problem is when the software can't do what you need. A process problem is when it can, but the way work moves through it doesn't match how your people actually work. Most organizations that think they have the first one actually have the second.
Not if the process underneath it stays the same. Most organizations introduce new systems but never fix the processes behind them. A new system with an old process is still the old process, and if that process was already broken, the new system won't work any better.