Sebenta Ops: AI Back-Office for Tutoring Centres

The Challenge

Dona Sebenta (donasebenta.com) is a family-run tutoring and study-support business in Braga, Portugal. It has two centres, Lamaçães and São Vicente. Each centre keeps its own student database, called Cognitia, in Microsoft Access, and Sync.com keeps the databases in sync with the reception computers at both centres.

Two recurring admin tasks take a lot of manual work:

1. Enrolment forms (Fichas de Inscrição). Parents and guardians fill in an online form on the website (WordPress/WPForms). Each submission arrives as an HTML email in a dedicated mailbox for the school year. For 2026/2027 that mailbox held about 270 forms between 1 September and 25 October. Every one had to be read, matched to the right centre and student, and typed into the right Access database. The data is messy:
   • about 23 students sent the form two or more times, sometimes with different details;
   • names are shortened or spelled differently from the database;
   • schools are missing from the reference list;
   • postcodes and birth dates are malformed (wrong years, missing digits);
   • the guardian's and the student's phone numbers are swapped;
   • some forms come from students who are not in the database yet.
2. Parent payments. Parents pay into several different bank accounts. All receipts go into one Excel workbook with one sheet per school year (352 movements so far in 2026/27). Each bank line then has to be matched to a centre, a student and a student ID before it can be posted to the database. Bank descriptions often show only the payer's name. Some parents have more than one child, and some pay one amount for several children, so the amounts still owed have to be checked to work out who a payment is for.

These tasks need care, because student names, guardian emails and guardian phone numbers are business-critical. They are also repetitive, slow and easy to get wrong.

The Solution

We built two AI agents on Grok Bot. Each one has a single job and follows the owner's rules.

FI (Ficha de Inscrição): enrolment-form agent

• Reads the enrolment-form mailbox and extracts the question/answer pairs from every form.
• Works out which centre each student belongs to by searching both databases. It updates the existing student record, and never creates a new student without permission.
• Uses the first form a student sent and compares any later forms. Where data differs, the form's data wins, and real conflicts go to the owner as questions.
• Fills in the fields, sets the FI = Sim flag on the student record, and files the processed email into a folder for the right centre (LAM or SVIC). The Inbox therefore only ever contains forms that have not been entered yet.
• Checks the data against rules, for example that a birth year fits the student's school year. Incomplete values are never guessed: they are left empty and reported.
• Learns from the owner's answers. For example: when the form has the fuller name, use it; when the school is unknown, use "Z Outra" and put the school name in Observações; a phone number with the wrong number of digits is saved exactly as written. Each batch therefore raises fewer questions.
• Runs on its own schedule: a routine checks the mailbox every day at 9:00 and 18:00 (Lisbon time), weekends included. Forms with no doubt are entered straight away; anything new or unclear becomes a numbered question for the owner. After each run, every form still in the Inbox is marked unread, so it is clear what is still waiting.

TB (Transferências Bancárias): payments agent

• Reads the payments workbook. It reads the existing VBA macros, which used to post receipts to the Recebimentos table of each centre's database, only as a reference for how the owner did the work. TB replaces the macros: it never runs them and writes to the databases and the workbook directly.
• Works in four phases:
  1. Finds the student and centre for each bank movement that is not yet posted (no "SIM" in the Cognitia column), using each payer's history from earlier school years, the enrolment data and the Alunos table. For guardians with several children, it uses the amounts owed to split or assign the payment.
  2. Searches the right centre's database and fills in Centro, Aluno and ID. The Centro column decides which database a payment goes to.
  3. Sends the owner a list (centre, student, ID, amount to post, amount owed) and flags every case where the amounts don't match.
  4. Only after the owner's go-ahead and after a backup: posts each payment to the database (Descrição = "Pagamento - TB", amount in Pago), reads it back to check it, marks the row "SIM", and highlights the student in yellow if a balance is still owed, just as the old macro did.
• Edits only the current school-year sheet. The sheet is protected, so TB unlocks it first and locks it again afterwards.

How it works

• Inputs: the school-year enrolment mailbox (read through the hosting provider's Roundcube webmail), the two Cognitia Access databases, and the payments Excel workbook on the owner's PC.
• Execution: each agent runs on its own cloud workspace. It reaches the owner's Windows PC only through approved commands to read and write the Access databases and the workbook. No data is moved to new platforms, and the existing tools stay in place.
• Human in the loop:
  • FI first worked in batches of 20 emails. Every batch ended with a summary of what changed (old → new) and numbered questions the owner could answer in one line (e.g. "1a, 2b, 3a").
  • Once the owner trusted the rules, he gave FI a standing approval for the clear cases. In the daily routine FI enters forms with no doubt by itself, and asks the owner only about the doubtful ones, with numbered options and a summary of every overwrite (old → new).
  • TB runs the first three phases by itself, and waits for the owner's approval before posting anything to the databases.
• Safety:
  • A timestamped backup of the databases (and, for TB, of the workbook) is made before every write and checked with a SHA-256 hash, into a backups folder next to each database.
  • Each student or payment is written in its own transaction and read back to check it.
  • Agents stop if Microsoft Access is open on any synced machine.
  • Destructive saved queries are never run.
  • If the owner's PC is off at a scheduled time, the routine does nothing, tells the owner in one line, and waits for the next slot.
  • Credentials are kept as secure secrets and never appear in chat.
• Test first, then production: both agents were first tested on copies of the databases. FI went to the real synced databases once the owner was confident it had learned his rules. TB has passed its full test on copies and is waiting for the owner to move it to the real files.

Impact / Results (actual, from the first day)

• FI was set up on 26 October 2026 and tested on database copies. It then went live on the real databases and processed the whole 2026/2027 enrolment mailbox (273 emails), in 14 batches with numbered questions after each batch.
  • 270 forms were entered or recognised as repeats. On 27 October they were filed into the centre folders: 101 in Lamaçães and 169 in São Vicente.
  • Only 3 emails were left on purpose for the owner: one student not found, and two siblings not yet in the database. They stay in the Inbox until the owner adds the students.
  • No new students were created without permission.
  • Every change was backed up and checked by reading it back. The owner also caught a mistake in the birth-year check, and it was fixed and audited the same day. This is why the rules and the human review matter.
  • On 27 October the owner moved FI to a fixed schedule (9:00 and 18:00 every day) and organised the mailbox by centre. A new form that arrived on the evening of 26 October is still waiting. The 9:00 run on 27 October did not check the mailbox because the owner's computer was off, so the check was left for the 18:00 run. In that case the agent does nothing and waits for the next slot, instead of writing blind.
• TB analysed the payments workbook and the existing macros and recorded the owner's rules for matching and posting. On 27 October it ran its full four-phase cycle on test copies of the databases and the workbook:
  • 12 bank movements were not yet posted. TB found the student, centre and ID for 11 and left the 1 with an unknown payer open for follow-up.
  • It flagged 3 of the 11 payments whose amount did not match the amount owed (two paid less, one paid more).
  • After the owner's go-ahead, it posted all 11 payments, each read back from the database before and after commit. It marked the rows "SIM" and highlighted the 2 students who still owe money in yellow. 8 of the 11 ended with a zero balance.
  • Before writing, it made verified backups of both databases and the workbook, and only the expected cells changed.
  • The owner's verdict: "Impecável" ("flawless"). The run on the real files is the next step.
• Qualitative impact (expected):
  • Manual typing of enrolment and payment data disappears.
  • Errors in critical contact data (guardian emails and phones) go down.
  • Each student record is complete and flagged (FI = Sim) once their form is in.
  • The owner moves from data entry to reviewing and deciding.
  • We have not yet measured exact time savings.

Next steps

• Watch the first successful scheduled FI runs, so that new forms arrive already entered and the owner only answers the open questions.
• Move TB from the test copies to the real databases and workbook, then give it a regular schedule like FI's.
• Extend the agents to the remaining admin tasks at both centres, such as payment reminders and monthly reports.
• Create new students from forms, with the owner's approval.
• Keep the same rules: a backup before every write, a human approving unclear changes, and existing tools staying in place.

Team

• Daniel Rebelo, co-owner of Dona Sebenta. Sole team member.