Keep track of pending approvals.

Assign requests, track deadlines and remind people of decisions. Approval remains with the authorised person.

Example architecture, not a client project.

ARCHITECTURE: DANIEL FRANKUPDATED: 7 SEPTEMBER 2026RAW / RULE / AI / HUMAN

What is done manually today.

A request is forwarded by email. The responsible person is absent, a reminder is missed or a question refers to an old version. It is tracking the decision, rather than the decision itself, that takes time.

This example organises responsibility, status and subsequent action. As long as the details and rules are known, the workflow needs no AI. A reminder is not automatic consent.

One case.
One clear path.

Each request has a visible status, a responsible person and a deadline. Reminders apply only to open cases. A subsequent action starts only after valid approval of the current version.

RESULT

Authorised execution + verifiable decision history

A complete request is submitted through the designated form or business application. It receives a unique case and version identifier.

  • Request with required details and attachments.
  • Responsible people and authorised substitutes.
  • Deadlines, time zone and a business calendar where needed.
  • Rules for approval, rejection, changes and cancellation.

Every step has a purpose.

EXAMPLE WORKFLOW / INTERACTIVESelect a process step
  1. 05 / PROCESS STEP

    Remind

    RULE
    Input data
    Open decision and reached reminder date
    Action
    Reminds the responsible person while the case remains open.
    Checks
    A fresh status check prevents reminders after a decision.
    If something fails
    Delivery errors are logged; reminders are not repeated indefinitely.
05 / PROCESS STEP

Remind

RULE
Input data
Open decision and reached reminder date
Action
Reminds the responsible person while the case remains open.
Checks
A fresh status check prevents reminders after a decision.
If something fails
Delivery errors are logged; reminders are not repeated indefinitely.
RESULTAuthorised execution + verifiable decision history

Example architecture, not a client project. The implementation depends on your process and available system access.

What happens at each step.

01

Request

RAW
Input data
Complete request from a form or business system
Action
Opens a case with a clearly identified decision to be made.
Checks
Checks required details, applicant and object version.
If something fails
Incomplete requests are returned for completion.
02

Ownership

RULE
Input data
Request, responsibility matrix and delegation rules
Action
Assigns the case to the responsible person.
Checks
Only authorised people may decide; delegates are explicitly defined.
If something fails
Missing assignment is referred to the named process owner.
03

Approval

HUMAN
Input data
Request, attachments and basis for the decision
Action
The responsible person approves, rejects or requests changes.
Checks
Decision, identity and reviewed version are saved together.
If something fails
A subsequent change to the request resets its approval.
04

Set deadline

RULE
Input data
Case status, deadline rule and business calendar
Action
Calculates the next permitted deadline or follow-up date.
Checks
Accounts for time zone, weekends and agreed exceptions.
If something fails
Missing deadline rules create a visible task.
05

Remind

RULE
Input data
Open decision and reached reminder date
Action
Reminds the responsible person while the case remains open.
Checks
A fresh status check prevents reminders after a decision.
If something fails
Delivery errors are logged; reminders are not repeated indefinitely.
06

Escalation

HUMAN
Input data
Overdue case with previous contact attempts
Action
The designated escalation contact takes over clarification.
Checks
Escalation does not replace a substantively required approval.
If something fails
If no delegate is available either, execution remains blocked.
07

Execute

RULE
Input data
Valid approval for the current case version
Action
Triggers exactly the agreed follow-up action.
Checks
Permissions, version and any previous execution are checked again.
If something fails
If the target status is unclear, reconcile it before repeating an action.
08

Log

RULE
Input data
Decision and execution events
Action
Records the history with responsibility and outcome.
Checks
Every event belongs to a case ID; sensitive content is limited.
If something fails
Gaps in the history become visible operational errors instead of being silently ignored.

Ausnahmen

  • If responsibility is missing, the process owner receives a clarification task.
  • During absence, only an authorised substitute is assigned.
  • Significant changes require a new review.
  • When a deadline is exceeded, the agreed escalation applies, not automatic approval.

Checks

  • The deciding person’s identity and authority are checked.
  • Approval must match the current request version.
  • Before each reminder, the case is checked to see whether it is still open.
  • A subsequent action must not accidentally run more than once.

Systems involved

A form or existing business application, a notification channel and a suitable way to record decisions with identity and timestamp. A simple email link is not always sufficient for sensitive approvals.

What we measure

  • Time until a decision is made.
  • Pending and overdue requests.
  • Manual reminders and questions.
  • Rejected, changed or repeatedly executed cases.

What to clarify before operation

Responsibility also needs a way to handle absence, rejection and unresolved requests. A change after a decision must be detected.

Reminders are checked against the current status before sending. Tests include changed requests, expired deadlines and decisions already handled.

The metrics show what could be measured in a future project. They do not describe achieved client results or guaranteed savings.

Does this sound like your process?

Review my process

Describeyour project.

A workflow, a website or an internal application: I assess the possibilities.

Project enquiry