Automate email data entry.
Keep people in control.

I proposed, built and maintain a workflow connecting school absence emails in Gmail to attendance records in eTap. It applies programmed rules, checks saved entries and prepares a morning handover for the attendance officer.

The officer estimates it saves more than an hour per school day, closer to two. That is a staff estimate, not a timed measurement. The system had been in use for around a month as of September 2026.

Read the attendance automation case study →

Start with the person doing the task. Identify the source information, the record it belongs to and the fields that must be saved. Include missing details, repeat messages and records someone has already updated.

For my attendance workflow, that means matching the student, checking dates and sessions, choosing an attendance code and preserving the parent’s comments. A doubtful match belongs in a review queue. The system needs a clear boundary around what it can decide.

I would first check whether the existing software offers a suitable API, connector or import. Where browser automation is appropriate, it needs checks around sign-in, saving and changes to the interface.

My attendance system uses the Gmail API and Playwright browser automation for eTap. Its dependence on an active session, the school computer and the vendor’s interface is part of the maintenance responsibility. A working prototype needs an owner before it becomes a daily dependency.

Repeatable decisions with explicit criteria are a good starting point for programmed rules. Less structured information may justify testing AI, with representative examples, agreed data access and a clear path for human review.

I used Gemini CLI assistance to develop the attendance software. Its operational decisions follow programmed rules; a generative AI model does not interpret the absence emails. In a different project, Just the Good News, AI selection and summarisation are part of the publishing workflow. The distinction matters when choosing and evaluating a solution.

Decide what proves completion. The attendance worker checks the saved attendance code and comment before marking the email as read. Duplicate checks and protection for existing codes are also part of the workflow.

For another process, I would agree the equivalent checks before allowing unattended updates: what to verify, when to stop and how staff will recover an incomplete task.

At 8:45am, the attendance system sends a summary of completed work and cases needing follow-up. Staff then own daytime processing. Uncertain or failed cases remain available for review.

That handover is part of the product. Someone should be able to understand what happened, what remains and whether the automation needs attention without reading its source code.

For a pilot, I would compare staff time before and after, including time spent checking exceptions and maintaining the system. I would record verified completions, items needing review and corrections separately from the number of emails received.

That gives a team a practical basis for deciding whether to extend the workflow. Order requests, bookings and other email-driven admin may involve similar steps, but each needs its own rules and checks.

Explore my work in automation and custom software →