Temple Guest Services System: Managing Membership at Scale

A day in the life of a temple with thousands of devotees

This temple is a well-known Buddhist institution in Taiwan with devotees spread across the country. Day-to-day operations are coordinated centrally by the reception hall: registering visiting residents, arranging memorial tablets for ceremonies, greeting devotees at check-in, and planning meditation-room assignments — all of this, without an integrated system, ran entirely on manual cross-checking between different forms and systems.

The devotee records accumulated in the old system already exceeded 300,000 entries — the trace of many years of service, and also a heavy management burden. The data was scattered across systems operated by different vendors with no way to connect them, so if staff wanted to look up a devotee’s history, tablet status, or lodging arrangements, they had to open separate interfaces and cross-check each one individually.

---

Untangling the management logic into just 7 modules

After in-depth requirements interviews, Estab-Zenith helped the client break down the reception hall’s day-to-day operations into seven core modules.

Tiered permissions form the foundation of the system. Staff in different departments (halls) see and operate on different scopes of data. Administrators, department managers, and general staff each have a corresponding permission tier, with token-based identity verification ensuring secure login.

Member management is the core of the data. Every devotee has an independent member profile page, including basic information, merit records, and payment history — plus a dedicated QR code. Devotees can display the code on their phone without needing an internet connection, and temple staff can scan it to pull up their record directly, dramatically cutting down on-site manual verification time.

Family relationships is one of the designs that best captures the temple’s actual business logic. When searching for a devotee, if that person has family relationships with other members, those related members’ records surface automatically. This means staff no longer need to remember “who is related to whom” — the system surfaces the connections on its own.

Memorial tablet management deals with the most complex data structure. A single tablet record covers a number, category, primary dedicatee, positional coordinates (floor, zone, row, slot), and issue date, and maps to different print templates — annual tablets, event-specific tablets, offering strips, and pilgrimage lantern tablets each carry their own strict layout rules. During the interview phase, Estab-Zenith catalogued every template format one by one, making sure the system’s print function could fully reproduce the existing paper-based process.

Lodging arrangements manages the registration and assignment of meditation rooms. Each room has a bed count, gender restriction, and availability status. Lodging registration supports time-range settings and includes conflict detection — if the same room ends up with a double booking, the system flags it automatically. Assignment logic also varies depending on resident type (volunteer, monastic, general devotee).

Dharma ceremony management lets every ceremony’s schedule be viewed at a glance in a calendar interface, with each ceremony recording its name, location, time, organizer, and participant list, all linked to member records.

Data export lets staff export data from any module in Excel format, matching existing reporting and administrative workflows.

---

300,000 historical records: no need to start from scratch

The devotee data in the old system is a core asset built up over the temple’s many years of operation, with staff already performing regular manual backups.

During the planning phase, migrating this historical data was factored directly into the architecture: the new database’s field design needed to stay compatible with the old system’s format, so that when data was migrated, the full merit records and tablet history could be preserved rather than rebuilt from zero. These 300,000 records aren’t just a number — each one represents a devotee’s years-long relationship with the temple.

---

The core challenge of requirements gathering: understanding cross-domain business logic

The difficulty in this project wasn’t technical — it was understanding.

Temple management logic has its own particular character; many conventions and rules developed over years of practice, and they don’t necessarily map onto a typical business-system framework. Tablet layout rules, lodging tier assignments, how family relationships should surface in search — all of these details had to be worked out step by step in interviews before they could be translated into concrete system specifications.

Throughout the interview process, Estab-Zenith helped the client’s staff turn business logic that had long relied on experience and memory into requirement specs that could actually be written into a system. That process itself is the hardest — and most valuable — step in going digital.

---

Technical planning overview

• Architecture: decoupled front end and back end, with account-role mechanisms dynamically adjusting visible scope and operating permissions
• Member QR code: displayable offline, scan for instant lookup, supporting both phone and printed membership card use
• Tablet printing: PDF template output, supporting annual, event-specific, offering-strip, lantern-tablet, and other formats
• Deployment environment: Google Cloud Platform (GCP) server in Taiwan
• Database: cloud database, with a regular backup mechanism

---

The core lesson from this project

This temple’s reception hall runs on a large number of conventions and rules formed over many years — which tablet template goes with which category, which resident tier gets assigned to which meditation-room zone, how far down the family tree a relationship search should display — rules that live in the heads of experienced staff, not in any document.

The work of requirements gathering was to take that tacit institutional knowledge and turn it into specifications a system could actually execute. In projects like this, the requirements-gathering process is itself a valuable deliverable. Turning business logic that has run on human memory for years into written form is often harder — and more lasting — than the system itself.