Since April 2025, I have been handling IT operations for our PTA. The PTA uses Google Workspace, and there was a volunteer position called “Account Administrator” that required PC skills. Thinking it would involve managing accounts and working with spreadsheets, I applied for the role. However, the reality turned out to be quite different.
While Google Sheets was indeed being used, most of the work relied heavily on manual processes, which was honestly discouraging. A thick operations manual had been prepared, covering everything from monthly tasks to procedures performed only once a year. Some of the original documentation referenced throughout this article remains in Japanese as it was created for local PTA operations.
Over time, I started building small tools to gradually reduce the monthly workload.
Reading through handover documents was difficult. Distributing information to individual classes was tedious. Tracking the status of inquiries was cumbersome. I wanted to eliminate as many of these repetitive manual tasks as possible. Fortunately, I had some experience with cloud technologies and databases, which allowed me to experiment and gradually build a collection of cloud-based tools centered around the Google ecosystem.
In this article, I will look back on what I built over the course of a year, the order in which I built it, and the reasoning behind the overall architecture. Originally, I intended to write this retrospective at the end of my term in late March, but as often happens, I kept putting it off. Eventually, I found myself publishing it at this somewhat unexpected time.
Timeline
- April 2025
- Started developing a suite of PTA operational tools
- Consolidated handover documents and operational knowledge using NotebookLM
- Built a bulk Google Drive distribution tool
- May 2025
- Implemented a workflow that automatically adds users to Google Groups from a mailing list registration form and sends confirmation emails
- Added automatic ticket numbering, acknowledgment emails, and Google Chat notifications to the inquiry form
- Created a simple ticket management interface to track inquiries and their resolution status
- June 2025
- Established the core PTA registration workflow, including parent registration, new entry processing, and notification delivery
- Built the data management foundation using BigQuery tables, views, and stored procedures for membership and role information
- Developed a web application for browsing the PTA directory, including search, filtering, and export functionality
- Officially adopted Google Chat as the primary organizational communication platform
- July 2025
- Evaluated the effectiveness of a volunteer assignment preparation tool for library duty scheduling
- Improved the process for synchronizing Google Group memberships based on BigQuery data changes
- Developed a tool that automatically generates cultural material loan request forms and distributes them as Excel files
- August 2025
- Added support for PTA role changes and various response-processing workflows
- Automated the parent information update pipeline
- Migrated and launched the PTA website within Google Workspace
- Added automated Google Analytics 4 reporting and aggregation
- September 2025
- Established a local development workflow using Apps Script and clasp
- Improved user-facing directory update notifications and export functionality
- Began designing and implementing a PTA membership fee collection system
- Created BigQuery tables for billing and payment tracking and started the initial Stripe integration
- October 2025
- Completed the core implementation of the payment collection system
- Added Stripe Checkout, webhooks, payment verification, signed payment links, billing emails, and payment reminder workflows
- Refined the BigQuery schema and improved deployment and operations with Cloud Run and Docker
- Continued improving parent information updates and directory synchronization accuracy
- November 2025
- Focused primarily on ongoing operations and minor enhancements
- December 2025
- Implemented a volunteer recruitment form for library duty assignments
- Added support for multi-slot selection, instructional messaging, and volunteer notification emails
- January 2026
- Developed selection logic for next year's officer nomination process
- Created SQL queries and Google Apps Script tools to support officer selection
- February 2026
- Built the full library duty assignment system
- Implemented a family ID–based registration interface, first-come-first-served and lottery assignment logic, recruitment period controls, directory views, and shift replacement workflows
- Enhanced the membership fee system with additional interfaces, including payment completion reports and billing email logs
- March 2026
- Improved the library duty replacement workflow
- Refined replacement requests, candidate selection, user interface elements, notifications, and authentication processes
- Developed a customized email distribution tool for targeted user groups
Looking Back, the Year Fell into Three Distinct Phases
Looking back, the improvements made over the year can be broadly divided into three phases.
The first phase, from April to May 2025, was about replacing individual manual tasks. I built tools for consolidating handover documents, distributing files to class shared drives, handling inquiries through a help desk system, and managing mailing list registrations. At this stage, the goal was not to integrate data across systems but simply to eliminate recurring weekly and monthly manual work one task at a time.
The second phase, from June to October 2025, focused on building a foundation. The challenge shifted toward managing information shared across multiple business processes: membership directories, parent registrations, officer assignments, mailing list synchronization, access control, and payments. This was when BigQuery entered the picture. Google Group updates became automated, access permissions were organized, and responsibilities that spreadsheets alone could no longer support gradually moved into a separate data layer.
The final phase, from late 2025 through March 2026, was the transition toward an operational platform. Volunteer recruitment, shift scheduling, replacement requests, notifications, and campaign-style email distributions gradually evolved from simple forms into services that users actively interacted with on an ongoing basis. By this point, the collection of tools felt less like a set of convenient scripts and more like a small ecosystem of business applications.
It All Started with Eliminating Painful Manual Work Using GAS
My first impression when I took over directory administration in March 2025 was simple: this is incredibly manual.
Although the PTA had already adopted Google Workspace, nearly every operational process had been designed around manual work. To be fair, that may have been unavoidable given the nature of a PTA organization. Most positions rotate annually, and procedures are intentionally designed so that anyone can perform them regardless of technical background.
The first tool I built was a handover document consolidation tool.
Handover documents were created every year, but their quality and level of detail varied significantly depending on who wrote them. Some years were excellent; others contained only minimal information. To make the accumulated knowledge easier to access, I created a system that searched Google Drive for .docx handover documents scattered across folders organized by year and class.
The tool extracted documents whose filenames contained the Japanese term for "handover," collected the contents into a spreadsheet, and organized them by school year, grade, and class. I then used NotebookLM to generate summaries and compile frequently asked questions from the collected material.
This was not a flashy automation project, but it solved a recurring problem: every year, someone had to spend hours figuring out where information was stored and what had been done previously. Since both the source data and output destination already lived within Google Workspace, Google Apps Script (GAS) was the obvious choice. Being able to work directly with Drive, Docs, and Sheets within a single environment made development remarkably straightforward.
The next tool was a bulk distribution system for class shared drives.
The organization supported students ranging from preschool through high school, resulting in roughly forty shared folders organized by grade and class. Previously, documents were distributed manually, one folder at a time, with a surprising amount of care and effort devoted to what was essentially repetitive file copying.
It was not difficult work, but it was undeniably tedious.
The new tool allowed documents to be distributed to multiple class shared drives at once. PTA operations frequently involve sending the same file to several classes or committees, and repeating that process manually increases the risk of missed deliveries or accidental distribution to the wrong destination. To address this, I automated the entire workflow: identifying recipients, distributing files, recording logs, and archiving the distribution history afterward.
The design philosophy during this period was quite simple:
If the workflow already lives entirely inside Google Workspace, GAS is usually enough.
There was no need to provision infrastructure, Google handled the underlying platform, and future maintenance would be easier for whoever inherited the system next.
Automating Intake and Registration Workflows
By May 2025, the focus began to shift from automating tasks that I personally handled to building tools that could be used across the organization.
One example was improving visibility into inquiries.
When someone submitted a Google Form, the system would automatically generate a ticket number, copy the submission into a logging spreadsheet, send an acknowledgment email, and post a notification to Google Chat. Later, I added a simple web interface that allowed staff to track and update the status of each ticket.
It was not a full-fledged support platform by any means, but I wanted to provide three capabilities that were essential for PTA operations:
- Confirmation that an inquiry had been received
- The ability to track requests without losing anything
- Shared visibility among multiple volunteers
The volume of inquiries was not large enough to justify introducing an external SaaS solution, but relying solely on a shared email inbox was becoming difficult. This system occupied the middle ground, using forms, spreadsheets, and notifications to provide lightweight process management.
In practice, PTA inquiries are relatively infrequent. Each request tends to be small, making it tempting for a volunteer to handle it privately and move on. However, that creates a black box where nobody else knows who received the request, how it was handled, or whether it was ever resolved.
At this stage, the goal was straightforward: establish a reliable foundation through ticket numbers, activity logs, and notifications so that inquiry handling became visible and traceable.
I described the implementation details of this system in a separate article:
Around the same time, I also released an automated mailing list registration system.
The workflow took responses submitted through a form, added members to Google Groups, sent a confirmation email, and updated the processing status in a spreadsheet. As shown in the meeting document below, the previous process had surprisingly little verification. If someone requested a change, their information would often be updated without any confirmation of identity. The new system was far from perfect, but it was certainly an improvement. Looking back at the implementation, it appears I also included basic validation to check whether the requester and the registration email address matched.
Another change that proved valuable during this period was the introduction of Google Chat.
The PTA had a deeply ingrained email culture. People would send messages like "Understood, thank you!" and include everyone on CC, resulting in overflowing inboxes filled with low-value email traffic. This was the point at which we started encouraging a simple rule: internal communication should happen in chat whenever possible.
That cultural shift turned out to be important later. Once Google Chat became part of daily operations, building notification bots and automated alerts became much easier because the communication channel was already in place.
Perhaps the most important lesson during this phase was learning to separate tasks that require human judgment from tasks that can safely be delegated to software.
The content of an inquiry still requires a human to interpret and respond. However, assigning ticket numbers, sending acknowledgment emails, posting Chat notifications, and recording status updates can all be automated.
The same principle applied to mailing list registration. Exceptional cases still required human review, but receiving requests, returning processing results, and maintaining logs could be handled automatically.
I found myself constantly asking the same question:
"What kinds of exceptions can occur, and can the system handle them automatically?"
Thinking through those edge cases again and again turned out to be one of the most valuable experiences of the entire project. It shifted my focus from simply automating routine tasks to designing workflows that could remain reliable even when real-world operations became messy.
It Became Clear That Forms and Email Alone Were Not Enough for Directory Management
The development of the PTA directory registration system from June 2025 onward was one of the biggest turning points of the entire year.
For the first time, the focus shifted from building standalone automation tools to designing an end-to-end process: how parent information should be collected, updated, and ultimately reflected in communication channels and operational systems.
Before this redesign, the workflow was surprisingly fragmented. Student data changes received from the school were sent to an external vendor, which updated its own database and returned the updated records as Excel files. Mailing list updates were then performed manually using those spreadsheets.
While this approach technically worked, it came with several problems. Updates were slow, duplicate records accumulated, outdated information remained in circulation, and the operational burden on volunteers was significant. In particular, even when a new parent registration or contact information change was submitted, the update would not reach the mailing lists until the next monthly processing cycle. In the worst case, a parent could go more than a month without receiving important communications.
Frankly, that raised an obvious question:
Can you really call it a directory system if updates take over a month to become effective?
It was also one of the major sources of parent inquiries.
This was the point where I finally introduced what I had wanted from the beginning: a proper database.
The core directory management workflow was moved into BigQuery. Google Forms and Google Apps Script continued to handle data entry, but normalization, change detection, historical tracking, and mailing list eligibility calculations were all moved into BigQuery.
For new registrations, GAS performed validation checks such as UUID verification, email address matching, and confirming that identity verification had occurred within a fifteen-minute window. Rather than writing directly into the production directory, submissions were first accepted as validated data.
From there, BigQuery stored procedures updated tables such as students, guardians, and ml_member_current, with the final step synchronizing eligible members to Google Groups.
One of the most important components introduced during this transition was the mailing list uploader.
This was the first time I was able to automate Google Groups management itself.
Saving form responses and sending notifications had always been possible with GAS, but automating the addition and removal of group members required Google Workspace administrative privileges. Once those permissions were incorporated into the workflow, the system moved beyond merely automating record-keeping and into automating actual administrative operations.
For the first time, the entire process—from registration to mailing list synchronization—became a single connected workflow.
As a result, registrations could be accepted immediately, and mailing list updates could typically be completed the next day. A process that previously had a lead time of up to a month was reduced to roughly one day.
That was the point where the system finally began to feel like a real system rather than a collection of helper scripts.
The reasons for adopting BigQuery were equally straightforward.
Spreadsheets alone had reached their limits for managing change detection and historical records. Comparing student data received from the school against form submissions, recalculating enrollment status and validity flags, and deriving mailing list membership from those results are all tasks that are dramatically easier to understand and maintain in SQL.
Equally important, BigQuery integrates naturally with the rest of the Google ecosystem. It connected smoothly with GAS, Google Forms, Google Cloud Storage, and Google Groups, making it a particularly practical foundation for this type of operational workflow.
Even within the Git repository, I established naming conventions such as load_, refresh_, and update_ to distinguish between ingestion, recalculation, and synchronization processes. This was not driven by technical necessity so much as maintainability. Months later, anyone looking at the code should be able to understand what a process does simply by reading its name.
That may seem like a small detail, but it reflects one of the lessons I appreciated most from my professional experience working with data platforms and operational databases.
Another important consideration was how student data was received from the school.
From a purely technical perspective, an API integration would have been ideal. In reality, however, the school's existing workflow revolved around email, and changing that process would have created unnecessary friction for everyone involved.
Instead, I designed the system around the current operational reality. At the beginning of each month, a scheduled email request is sent automatically. The school's reply email contains an attachment, which is stored in Google Cloud Storage. The latest file is then picked up by the BigQuery pipeline and processed automatically.
It is not the most technically elegant architecture.
However, it is an architecture that people can actually continue using.
Throughout this project, that consideration consistently outweighed technical perfection.
These changes transformed a monthly process that depended on volunteers sacrificing personal time to perform repetitive manual updates into one where data pipelines handle most of the work and people primarily review the results.
New registrations, contact information changes, officer assignments, and student data updates all enter the system through different paths, but ultimately converge into the same BigQuery update pipeline. From there, updates flow outward to mailing lists, directory applications, and other downstream systems.
Looking back, one design principle made the entire system sustainable:
Many entry points, but a single source of truth.
Establishing that architecture became the foundation that allowed directory management to continue evolving throughout the year.
Making Information Accessible Across the Organization
Once the directory system was in place, the next challenge was making the information usable.
In June 2025, I released a web-based PTA Directory Viewer. The architecture was intentionally simple: the latest data was periodically exported from BigQuery views into a spreadsheet, and the cached data was then displayed through a GAS web application.
From a technical standpoint, there was nothing particularly sophisticated about the solution. One small but important design decision was implementing role-based access control. Board members could view the entire directory, transportation coordinators could see only the bus routes they managed, and class representatives could access information for their own classes. Row-level filtering and column restrictions were applied based on account identity and assigned roles.
Directories are useful, but they also become a risk if too much information is exposed. From the beginning, the principle was straightforward:
Show only the data that each person actually needs.
Although it would have been possible to connect directly to BigQuery using something like Connected Sheets, I intentionally chose a scheduled export and cache-based architecture. The reasons were simple: predictable performance, stable costs, and operational simplicity.
A directory viewer should be lightweight, reliable, and easy to explain. Unless real-time updates are essential, a cached approach is often much easier to operate.
An equally important challenge was user education.
Before this system existed, individual departments would download copies of the directory spreadsheet and maintain their own versions. As a result, nobody knew which file contained the latest information. Contact changes were sometimes communicated through unofficial channels without the directory administrator even knowing about them.
I vividly remember spending a significant amount of time encouraging people to abandon the familiar copy-and-paste workflow and use the directory viewer as the single source of truth.
Following the same philosophy, I introduced class-specific mailing lists for class representatives in September 2025.
Groups were created on a per-class, per-school-year basis, and memberships were synchronized automatically from the master directory. The key difference was that synchronization was based on the desired end state rather than simply adding new members. Enrollment and withdrawal status were continuously evaluated, and each mailing list was updated to reflect the current roster.
This marked another shift in thinking. Rather than treating mailing list management as an isolated administrative task, the communication infrastructure became something generated directly from the directory platform itself.
One immediate benefit was that class representatives no longer had to manually maintain long BCC lists every time they sent an email.
Around the same period, we also revisited the PTA website.
Historically, the organization had rented a server and maintained a WordPress installation. When we evaluated the actual communication needs of the PTA, however, the setup was clearly overengineered.
Fortunately, our communications team raised the issue as well, and we eventually migrated the site to Google Sites. This reduced both ongoing costs and operational complexity.
Once again, the primary decision criterion was not feature richness.
It was sustainability.
Could the next volunteer maintain it without specialized technical knowledge?
That question mattered far more than whether the platform supported advanced functionality.
To be honest, Google Sites lacks the flexibility of something like a static site hosted on Amazon S3. Content updates are largely performed through the graphical interface rather than code. However, when considering future maintenance, the tradeoff was worthwhile. Updating the site became something that even volunteers with no IT background could realistically manage.
As part of the website refresh, I also integrated Google Analytics and created a chatbot that automatically posted weekly traffic reports to Google Chat.
During the same period, I revisited another unique PTA process: cultural resource lending.
The PTA maintains a collection of several hundred educational and cultural materials that members can borrow. Previously, users had to download an Excel file, fill in the items they wanted to borrow, and then send the file via email. The process involved multiple steps and frequently resulted in incomplete submissions.
For reasons nobody could fully explain, requests were also being sent to a custom email address that only existed for this purpose.
The workflow was redesigned around a Google Form. Users now enter the required information once, and the system automatically generates and sends a loan request spreadsheet with the submitted information pre-filled.
The result was a simpler experience for users and a more consistent format for administrators receiving requests. By standardizing the process, we reduced procedural friction on both sides.
Another major change during this period was adopting local development with clasp.
When everything lives exclusively inside Google Apps Script, it becomes difficult to track what changed, when it changed, and why it changed. Moving the code into a Git repository allowed me to manage changes through commits and preserve the intent behind each modification.
That was the point where the project started to feel less like a collection of utility scripts and more like a maintainable software project.
In hindsight, I honestly have no idea how I managed to develop GAS applications for so long without clasp.
If you are building anything substantial with Google Apps Script, I strongly recommend using it from the beginning.
For anyone completely new to clasp, I previously wrote about my own setup struggles in the article:
The Hardest Challenge: Building a Payment System
From late September through October 2025, I built the PTA membership fee payment platform.
Of all the projects completed during the year, this was the one that required the most thought about system design rather than simple automation.
The initial implementation was straightforward. Billing records were stored in BigQuery, while Google Apps Script managed the association between invoices and Stripe Checkout URLs. On paper, the design seemed reasonable.
In practice, it failed almost immediately.
The problem was that pre-generated checkout_url values and session_ids eventually expire. Parents would sometimes open billing emails days or weeks later, only to discover that the payment link was no longer valid.
That realization forced a major redesign.
Instead of embedding Stripe URLs directly in emails, I switched to a model where emails contained only PTA-issued signed links. When a user clicked the link, the server would generate a fresh Stripe Checkout Session on demand and immediately redirect the user to Stripe.
Payment completion was treated as a separate source of truth. Rather than trusting redirects or browser behavior, the system relied on Stripe Webhooks. When a payment event arrived, the webhook updated the corresponding payment_status and paid_at fields in BigQuery.
In addition, every generated session, webhook event, and outbound transaction log was stored in separate tables to create a complete audit trail.
The resulting architecture looked much closer to a real payment platform than the simple integration I had originally envisioned.
I documented the implementation details in a separate article:
This was also the first major component where I intentionally moved away from GAS and adopted Cloud Run with Python.
The reason was simple: I had reached the practical limits of Google Apps Script.
Webhook signature verification, raw request body handling, secure secret management through Secret Manager, on-demand session generation, and idempotency controls are all technically possible with GAS if you work hard enough. However, once security, maintainability, and operational reliability become priorities, a server-side application is a much more natural fit.
One lesson from this project was learning where each technology belongs.
GAS is excellent for workflow automation inside Google Workspace.
Cloud Run is a better fit when security-sensitive integrations and external payment systems become the core of the application.
The payment system became an exercise in drawing that boundary clearly.
Around the payment platform, I also built supporting operational tools. These included email workflows for initial billing notifications, payment reminders, and escalation alerts for unpaid balances. I previously wrote about some of the challenges involved in those email processes in another article:
All outbound email activity was logged into BigQuery as well.
A payment system is not simply about whether someone can successfully pay. Just as important is being able to answer operational questions such as:
- Who received which email?
- When was it sent?
- Which step of the process is currently blocked?
- What evidence exists if someone claims they never received a notification?
Because of that, auditability became a first-class design requirement throughout the project.
Looking back, this was probably the point where the system stopped being a collection of productivity tools and started resembling an actual business application. The technical challenge was not collecting money. It was building a process that could be trusted, monitored, and explained when something inevitably went wrong.
Helping Other Departments Become More Efficient Through Technology
By November, most of the core directory and payment systems were in place. As the end of the school year approached, I shifted my attention toward building tools that supported day-to-day operational activities across the organization.
One of the first areas targeted was the library volunteer program.
Parents volunteer to help with book lending and returns, but each shift lasts four to five hours, making it a significant commitment. Every year, the PTA collected availability from a large number of parents and manually created schedules.
On the surface, it looked like a simple scheduling task.
In reality, the workload extended far beyond creating the initial schedule. Collecting preferences, assigning volunteers, handling cancellations, coordinating replacements, and communicating with the school all created a surprisingly complex operational process.
Initially, I thought about creating something similar to a SignUpGenius-style volunteer registration form. However, the requirements turned out to be much more complicated than simply allowing people to sign up for open dates.
Some slots needed to be assigned on a first-come, first-served basis. Others required lottery-based selection after the application deadline. The system also needed to handle absences, replacement requests, and notifications to school staff. In short, there were many organization-specific rules that had accumulated over the years.
As a result, beginning in February 2026, I developed a dedicated library volunteer platform using Google Apps Script. The system handled volunteer registration, assignment processing, replacement requests, and notification logging as part of a single workflow.
Part of the user manual is shown below. Unfortunately, the manual is available only in Japanese.
The platform was designed so that most day-to-day operations could be managed directly by the users themselves. Rather than relying on administrators to coordinate every step, participants could view their status, understand what actions were required, and manage their own involvement.
In that sense, it evolved beyond a simple administrative tool and became something closer to a self-service operational platform.
The system is already in production and currently supports the full process from volunteer recruitment through assignment and replacement management.
Around the same time, preparations began for selecting the following year's PTA officers.
Officer selection is far more complicated than it might initially appear. Eligibility and selection probabilities vary significantly based on bylaws, internal policies, prior service history, and numerous other conditions.
Historically, the selection process relied on externally generated spreadsheets, extensive manual filtering, email distribution, and follow-up phone calls to confirm responses. Every year, a considerable amount of effort went into producing and managing candidate lists.
I automated the entire workflow.
Candidate selection, email notifications, acceptance confirmations, and tracking were all integrated into a single process.
A task that previously consumed nearly a month of work, involving multiple volunteers and significant administrative overhead, could now be executed with essentially a single button press once the underlying rules were configured.
At the same time, I added a generalized email distribution platform.
For each project, administrators can prepare a data sheet containing the target audience. The system joins that data against the central family master using unique_id, then merges personalized information into email templates before sending messages.
This tool was only possible because several foundational pieces were already in place:
- Each family could be uniquely identified through
unique_id - Contact information had been centralized and maintained
- Target populations could be generated from the directory system as structured datasets
Because those prerequisites already existed, the email distribution platform itself was surprisingly quick to build.
Looking back, that was perhaps the most satisfying aspect of the entire year.
Each improvement made the next improvement easier.
The directory platform enabled mailing list automation. The mailing list infrastructure enabled communication tools. The communication tools enabled volunteer management and officer selection. The centralized data model enabled personalized outreach.
In other words, every project became a building block for the next one.
Viewed from that perspective, the email distribution platform was not just another tool. It was the culmination of a year's worth of accumulated infrastructure, process improvements, and architectural decisions finally coming together.
The Technology Decisions Were Driven Not by Trendiness, but by What the PTA Could Sustain
One thing I found myself thinking about repeatedly throughout the year was not whether a technology was good, but whether it was a reasonable fit for the organization.
In a typical product development environment, priorities might center around scalability, separation of concerns, reusability, type safety, deployment strategies, and other architectural considerations. Within a PTA, however, different constraints mattered more. The system needed to be manageable by a small group of volunteers, affordable to operate, easy to hand over to future administrators, and compatible with the existing Google Workspace environment.
Those requirements naturally led to extensive use of Google Apps Script.
GAS integrates closely with Forms, Sheets, Gmail, Drive, and Google Chat, allowing entire workflows to be implemented with relatively little code. Personally, I often find it more approachable than AWS Lambda for this type of operational automation.
That said, GAS is not the right solution for everything.
Complex change detection, historical data management, and cross-system data analysis are much better handled by BigQuery. Likewise, systems involving payment processing, security boundaries, and webhook-driven integrations are generally more reliable when implemented on Cloud Run.
The key was understanding where each tool fit best.
At least in my experience, staying within the Google ecosystem wherever possible reduces both implementation effort and long-term maintenance costs. The tools work well together, and the learning curve remains manageable for future volunteers.
Cost management was another factor that could not be ignored.
The decision to migrate from WordPress to Google Sites came from the same line of thinking. Likewise, whenever a solution could be implemented using existing Google Workspace services, GAS, or BigQuery, I generally preferred to keep it there rather than introduce additional platforms.
For a PTA, the most important question is not whether something is cost-effective today.
It is whether the solution will still be practical and maintainable next year.
A system that saves time but introduces significant hosting costs, licensing fees, or maintenance overhead often fails to survive leadership transitions.
In that sense, technology selection was really a form of operational design.
Building Systems That Can Survive Leadership Turnover
The idea of handover was always in the back of my mind throughout this project.
In organizations where the same people maintain systems for many years, it is sometimes acceptable for knowledge to remain concentrated in a few individuals. As long as those people understand the system, operations continue.
PTAs do not work that way.
A completely different person may inherit responsibility a year later. In some cases, the handover process begins only a few months after a system is introduced.
Because of that, I tried to avoid creating solutions that required specialized administrative interfaces or extensive training.
Most of the systems were intentionally built around tools people already knew: Google Forms, Google Sheets, email, and Google Chat.
Rather than asking every new volunteer to learn a sophisticated custom application, I preferred to extend familiar tools and workflows whenever possible.
However, an even more important lesson emerged over time:
Before automating a process, ask whether the process should exist at all.
As these systems were introduced, many responsibilities within the PTA gradually disappeared. In several cases, entire positions became unnecessary because the work they were created to perform no longer existed.
One example was the class representative role.
A major responsibility of class representatives had been collecting PTA membership fees. Across all grades, from preschool through high school, this involved roughly eighty volunteers. Once fee collection became automated, the need for that responsibility disappeared. As a consequence, several associated administrative tasks—including Google account management responsibilities assigned to those positions—also disappeared.
Ironically, that meant the original "Account Administrator" role I had volunteered for effectively eliminated itself.
Looking ahead, the biggest challenge is ensuring that the system remains maintainable.
Even during the past year, the amount of time I spent writing entirely new code gradually decreased. More and more of the work shifted toward organizing requirements, making decisions, and coordinating improvements rather than implementation itself.
My current area of interest is exploring whether future maintenance can be handled differently.
When bug reports or feature requests arrive, perhaps humans only need to decide whether the request is worthwhile. The implementation details, troubleshooting, documentation updates, and even user support responses might eventually be delegated to AI agents.
Whether that vision proves practical remains to be seen.
But after spending a year automating administrative work, it seems only natural to start asking how much of the software maintenance process itself can also be automated.
Top comments (0)