Administrative automation: follow a case from start to finish

Following an administrative case means knowing at any moment what has been received, what is missing, who must decide and what has already been sent to the supplier. This article walks through a complete fictional case: onboarding a new supplier by email, with attachments, completeness checks, controlled reminders and human validation. No payment or accounting entry is automated here: the goal is to structure the follow-up, not to delegate financial commitments.

The fictional case: supplier onboarding by email

Imagine an SME that receives supplier onboarding requests in a dedicated mailbox. Each request must contain five items: a completed information form, a bank details document, an insurance certificate, a company registration extract (or the local equivalent) and a signed onboarding form. As long as one item is missing, the case is incomplete and no internal department may use it.

Our hypothetical scenario: the supplier "Ateliers Rivage" sends the form and bank details in a first email, then the insurance certificate in reply to a reminder. The registration extract and the signed form are still missing after two reminders. This case will serve as the example throughout the article, with fictional values you will adapt to your own rules.

Map the journey before automating

Before writing a single rule, list the possible states of the case: received, incomplete, awaiting reminder, awaiting validation, approved, rejected. This mapping avoids blind spots: an "incomplete" case with no associated reminder state will produce endless reminders, or silent omissions. The guide on business process automation and mapping the work first covers this often-neglected step.

In our fictional case, the map is simple but complete:

1. Receipt of the initial email with attachments.
2. Completeness check of the five expected items.
3. If incomplete: controlled reminder email, with a delay before the next reminder.
4. If complete: hand-off to human validation.
5. Explicit decision: approved or rejected, with a reason.
6. Logging of every transition.

Each arrow in this diagram must have a designated owner: a rule, an AI, or a person. That is the subject of the section on role allocation.

Checking attachments and extracted data

The first automatable task is the completeness check: the assistant identifies attachments, attempts to match each one to an expected type (bank details, insurance, registration extract, signed form) and flags anomalies. A three-page PDF named "various documents" proves nothing: you must check the content, not just the file name. The article on document automation: extraction, evidence and validation explains how to keep a trace of what was extracted and verified.

Three checks deserve to be systematic:

• Name matching: the bank account holder must match the declared company name. A discrepancy is not necessarily fraudulent, but it must block the move to validation until a human clarifies it.
• Readability and integrity: a corrupted or unreadable file must be flagged, not ignored. A case never moves to "complete" with an unreadable attachment.
• Form consistency: mandatory fields filled in, plausible dates, contact email consistent with the sender's address.

AI-assisted extraction helps read the documents, but the decision to consider an attachment compliant remains human as long as the rules are unproven. The guide on automating emails with attachments covers this point in detail.

Complete and incomplete states: a definition with no ambiguity

A case is complete only if all five expected items are present, readable and matched to the right supplier. A case is incomplete as soon as one item is missing or invalid. This binary distinction avoids vague intermediate states like "almost complete", which lead to premature validations.

In our example, after the first email, the Ateliers Rivage case is incomplete: form received, bank details received, insurance missing, registration extract missing, signed form missing. After the first reminder, the insurance arrives: still incomplete, two items missing (the registration extract and the signed form). After the second reminder with no reply, the case remains incomplete and moves to human review for a closure or alternative follow-up decision. No state contradicts another: that is the essential property of the tracking.

Controlled reminders: follow up without pestering

The reminder is the step where poorly controlled automation does the most damage. Three design rules are enough to keep it in check:

• Maximum number of reminders: for example two reminders spaced ten business days apart (a hypothetical value to adjust). Beyond that, the case goes to human review instead of receiving a third automatic reminder.
• Content verified before sending: the reminder lists precisely which items are missing. A message asking for "the remaining documents" when everything has been received destroys trust in the system.
• Traceability: every reminder is recorded with its date, content and trigger.

One technical point deserves your attention if you use Gmail. The gmail.compose and gmail.modify scopes can also authorize sending messages: restricting behavior to drafts therefore requires application-level controls, not just a scope choice. A label is not a Gmail permission boundary. The official documentation on Gmail API scopes describes these authorizations. In practice, the safest design has reminders prepared as drafts and reviewed by a human before sending, at least initially. The guide on an AI agent for email drafts develops this mode of operation.

Validation: a human decision, not a checkbox

When the case is complete, it moves to validation. The responsible person receives a summary: the five items, the checks passed, any alerts (a name mismatch on the bank details, for instance). They decide: approve, reject, or request further clarification.

This step is not automated, for one simple reason: onboarding a supplier creates a relationship that commits the company. Even without automated payment, an approved supplier can receive orders. The decision to open that door must remain human, with a written reason. If validation is refused, the reason is recorded and a closing message is prepared, also reviewable before sending.

Matching: associating every reply with the right case

The supplier replies to your reminders, sometimes from a different address, sometimes with a modified subject line. Matching means associating each incoming email with the right case. Two robust rules:

• Primary key: the case identifier, present in the reminder subject line (for example "[Case FR-2026-0147]" in our fictional example). If the supplier replies to it, matching is direct.
• Secondary check: the sender's address and the supplier's name. A reply from an unknown address is not automatically attached: it is flagged for human verification.

Automatic matching is limited to certain cases. Any ambiguous case goes into a human queue. This is less impressive than AI matching on every input, but it prevents an insurance certificate meant for another supplier from completing a case by mistake.

Humans, AI and rules: who decides what

A table helps fix responsibilities for this kind of follow-up:

Task	Performed by	Rationale
Identify attachments	AI + rules	Repetitive reading, errors possible but detectable
Declare the case complete	Rule	Objective criteria, no interpretation
Draft the reminder	AI as draft	Reliable substance, wording to review
Send the reminder	Human (initially)	Check before engaging with the supplier
Match an ambiguous reply	Human	Context needed, low volume
Approve the onboarding	Human	Committed decision, reason required
Log transitions	Rule	Traceability with no exceptions

The guiding principle: AI prepares, rules settle objective cases, humans decide anything that commits the company. This split tightens or loosens with experience, never all at once.

The decision log: your evidence of follow-up

Every state transition is recorded with four pieces of information: the date, the previous state, the new state and the actor (rule, AI or named person). Fictional example for Ateliers Rivage:

• 12/03/2026 9:14am — received → incomplete (rule): form and bank details received, three items missing.
• 12/03/2026 9:15am — reminder no. 1 drafted (AI), reviewed and sent by C. Diallo on 12/03 at 11:02am.
• 24/03/2026 2:37pm — reply matched, insurance certificate received (rule): case still incomplete.
• 26/03/2026 10:20am — reminder no. 2 sent after human review (C. Diallo).
• 09/04/2026 9:00am — threshold of two reminders reached, moved to human review (rule).

This log answers the question any audit or dispute will ask: what happened, when, and who decided. It also distinguishes three things often confused: the connection to the messaging service, the authorization granted to the provider, and the evidence that an operation actually took place. A clean operations log documents the third, not the first two.

Operational procedure: setting up this follow-up

Here is a starting procedure, to be adapted:

1. Define the list of expected items and the compliance criteria for each (readability, name matching, mandatory fields).
2. Create the dedicated inbox and the subject-line convention with a case identifier.
3. Write the allowed states and transitions, with a single path between any two states.
4. Set up the completeness check: a rule declaring complete/incomplete, alerts on unreadable or inconsistent attachments.
5. Configure reminders as drafts: maximum number, interval between reminders, content listing the missing items, human review before sending.
6. Define the validation queue: who receives the summary, what indicative deadline, what reason is required in case of rejection.
7. Switch on the decision log from the very first case, not after the first incident.
8. Review the settings after ten processed cases (a hypothetical benchmark): reminders too frequent? false "complete" states? adjust.

Limits, common mistakes and what to do

Three mistakes come up regularly. First mistake: sending reminders automatically from day one. A typical outcome, seen in fictional setups like this one: a reminder sent although the supplier has just replied, because matching failed. What to do: drafts first, automatic sending only once matching is reliable.

Second mistake: confusing a complete case with an approved supplier. A complete case triggers human validation, not automatic onboarding. The log must show the human decision between the two.

Third mistake: an incomplete log. If only validations are recorded, you cannot prove a reminder was reviewed before sending. Every action that changes the case state or engages an exchange with the supplier leaves a trace.

Finally, if you consider channels other than email for reminders, check each platform's own rules: response windows, approved templates, permissions. These constraints are design and good-usage rules, not guarantees of regulatory compliance: responsibility for data protection remains yours.

Frequently asked questions

Can reminder sending be automated without risk?

It can, but not immediately. The prudent path is to have reminders prepared as drafts reviewed by a human, then automate sending only once reply matching and the completeness check have proven reliable over several consecutive cases. Note that with Gmail, the scope used is not enough to restrict behavior: application-level controls are necessary.

Why not automate the validation itself?

Because validation commits the company toward a third party. A complete case is a factual finding; validation is a decision. Even without automated payment, an approved supplier can receive orders, and opening that door deserves a person who owns the decision with a written reason.

What if the supplier replies from a different address?

Automatic matching happens only if the case identifier appears in the reply's subject line. Otherwise, the email goes to a human queue for verification. This is deliberately conservative: a few minutes of checking is better than an attachment attached to the wrong case.

How many reminders before giving up on a case?

There is no universal threshold. In our fictional example, two reminders spaced ten business days apart are enough, after which the case goes to human review for a closure, out-of-channel follow-up or waiting decision. Choose a threshold suited to your sector and how urgently you need suppliers onboarded, then document it.

Does the decision log replace a written procedure?

No, it complements it. The procedure describes what should happen: states, deadlines, responsibilities. The log proves what actually happened, transition by transition. Both are needed: without a procedure, the log has no reference; without a log, the procedure cannot be verified.