Every Friday, over 100 workers across 14 service units come for prayers and meetings. Every week, team leaders took attendance manually. I built a Telegram bot that handles the entire thing automatically. Nobody takes a screenshot anymore.
Workers tap one button. The bot handles registration, reminders, closing, and reporting automatically.
I was one of those team leaders. Every week I took attendance manually, screenshots of who was present, then going to Google Sheets to mark each person. It was not hard. It was just a weekly tax on my time that added nothing.
The problem was not complicated: people already had Telegram open. The meeting was already happening in a group. All I needed was a button. So I built one.
The problem is not unique to this church. Any team leader responsible for tracking attendance in a recurring group setting — a community organisation, a volunteer unit, a weekly class — faces the same manual overhead. The system is built for CCI Akure but the problem it solves is everywhere.
Who it is built for
The product serves two distinct users with completely different needs. Getting this right meant designing two separate experiences that share the same underlying data.
Success metrics
These were written into the PRD before a single line of code. Each one points to a real behaviour, not just a number.
System architecture
The system has four distinct layers. The Telegram bot is the only thing workers ever touch. Google Sheets is the source of truth that any coordinator can open and read directly. Apps Script turns that data into a JSON feed for the dashboard. And the React dashboard gives leadership a visual view of everything.
Four-layer architecture: Telegram bot handles all interactions, Google Sheets is the source of truth, Apps Script serves data to the dashboard.
User flow
Whether a worker has registered before or not, they end up in the same place: attendance marked. An unregistered worker who taps the button gets taken through a quick setup in DM and then marked present automatically. No worker misses attendance just because they had not registered yet.
Registered workers check in instantly. Unregistered workers go through a one-time setup in DM, then get marked present automatically.
Attendance lifecycle
The entire Friday attendance cycle runs without anyone doing anything. The bot opens attendance, sends reminders, and closes the window — all automatically and all relative to when attendance opened, not a fixed clock time.
The entire lifecycle runs automatically. Leaders only need to intervene if the meeting runs late.
How it works
The public dashboard shows unit leaderboards, personal attendance records, and trends across all time periods.
Design decisions
Each decision came from understanding the context deeply enough to know what the right call was.
Retention design
Attendance systems usually feel like surveillance. This one needed to feel like something workers actually wanted to engage with. The answer was /mystats, a private command that shows each worker their own record, streak, and any badges they have earned.
Badges are not decorative. Each one represents a real pattern of behaviour worth recognising.
Known limitations
Good product work means being honest about constraints. These are documented and known before anyone encounters them.
What comes next
The core system is solid and running. These are the things worth building next, in order of impact.
What I learned