Synthetic preview · No inbox connected

One founder's week: routine, approval, escalation

Seven requests land in a founder's inbox across one week. All people, businesses and emails are fictional. No live inbox is connected and no account is needed to read this page.

This preview explores what an email makes explicit, what MailOver extracts, and what still requires judgement.

Illustrative evaluation, not a live product demonstration.

The inbox below is the MailOver interface with synthetic content. Titles, deadlines and categories show the shape of the fields MailOver extracts today. They were written by hand for this preview, not captured from a product run.

Manual reading of the week, not a product output 7 items reached the founder
Routine action
2

Owner named in the email, no approval requested.

Approval request
3

One states the rule that requires the founder. Two do not.

Escalated
2

One lacks agreed authority; one asks the founder without stating a rule.

The week in the inbox

Select any item to read the original email and its illustrative summary side by side.

Routine, approval and escalated are labels from the manual reading. Titles, deadlines and categories are hand-written examples of MailOver fields.

Send Northstar Retail the confirmed delivery scheduleMaya Chen · Thursday, 3pmRoutine action
Approve the £7,200 equipment replacement orderNina Adeyemi · Friday, noonApproval request
Decide on Northstar’s delivery changeSam Whitlock · Before tomorrow’s 11am meetingEscalated
Sign off the £1,450 courier invoicePriya Raman · This weekApproval request
Confirm attendance at Tuesday’s 2pm interview panelTom Beckett · No response deadline statedRoutine action
Review the new pricing page copy before publishingJo Halloran · MondayApproval request
Reply on the Thursday shift swapLeo Ferreira · TodayEscalated
Manual evaluation · not current product output

Test whether it needed to reach the founder

A route is only reviewable when the protected outcome, required evidence and route-changing threshold are explicit.

Worked example · courier invoice

Should a routine £1,450 invoice need founder sign-off?

Current reading: Approval request
01

Outcome being protected

Pay valid suppliers on time while preventing unbudgeted, duplicate or exceptional spend.

02

Evidence the owner needs

Invoice amount and history are present. Budget status, purchase-order match, duplicate check and the applicable approval policy are missing.

03

Threshold that changes the route

Proposed boundary to confirm: Finance owns matched, budgeted invoices at or below £5,000. A mismatch, exception or higher amount routes to the founder.

Route test

At £1,450: route to Finance only if the missing checks pass. At £5,001, or with an exception: route to the founder. Without those checks and an agreed threshold, the page can describe the request but cannot prove its route was right.

Reviewer correction

How should this case be classified?

Choose a correction, then carry it forward as a proposed lesson for the next similar case.

Corrected classification

The manual classification is unchanged.

This interaction is illustrative. It does not save data or demonstrate an existing automatic learning feature.

What you can instruct today

MailOver's secretary takes written rules. The example rules below explore how approvals and stated reasons could be made easier to review. Their results have not been tested in this preview.

A rule does not decide who should hold the authority. That question stays with you, and the emails above show how often it is simply unstated.

Lessons Secretary settings
  • When an email asks me to approve something, flag it as an approval and keep the stated policy or threshold with the item.
  • When an email says a task sits within someone else’s remit, do not create an action item for me.
  • When a request arrives with no stated rule for why it needs me, note that no rule was given.

Example rules written for this preview. They show the kind of instruction the secretary accepts, not output from a run.

Where extraction stops

Surfacing a request can make work visible. Diagnosing decision rights also requires understanding authority, delegation and why the request reached this person. These examples keep those questions separate.

MailOver extracts requests and deadlines and organises email. Ownership, authority and root cause are not product outputs, and the recipient of a request is never treated as proof of rightful ownership.

One question

Which of these distinctions would make this useful in your founder-dependency work, and what is still missing?

A reply in our existing LinkedIn conversation is the easiest place to answer. There is nothing to sign up for on this page.