Turning emails into tasks
A parser and a bit of judgement, saving twenty minutes a day.
Build time ~4 hrs
If part of your job is reading emails and creating tasks from them, that's a well-shaped automation: mechanical extraction, with a human confirming before anything is created.
1. Get the emails
An IMAP connection to a dedicated folder is the simplest reliable option — you forward or filter the relevant mail into it, and the script reads from there. No permissions beyond your own mailbox, no webhook infrastructure.
Build an email-to-task processor. Reads from <IMAP folder>. - Fetch unread messages, mark processed rather than deleting. - Extract the plain-text body, handling HTML-only mail and quoted reply chains — I want the new content, not the whole thread history. - Strip signatures and disclaimers. - Handle attachments by noting them, not by parsing them. Then, for each: a model call extracting whether this needs an action, what it is, who it's for, and any deadline mentioned. Return null rather than inventing anything not stated. Nothing is created automatically — everything goes to a review queue.
2. Quoted replies are the hard part
An email thread contains the whole history. Extracting the new content means recognising quote markers, "On [date] X wrote:" headers, and the several formats different clients use.
Get this wrong and you'll create tasks from a message someone sent three weeks ago, quoted at the bottom.
3. Review before creating
The design decision that makes this safe. The script proposes; you approve. A daily digest of "here are 6 proposed tasks, approve or dismiss" takes two minutes and prevents every category of embarrassing mistake.
Once you trust it for a specific narrow category — orders from one system, alerts from one sender — you can auto-create just those.
4. Idempotency
If the script runs twice, or you reprocess a folder, the same email must not produce two tasks. Store the message ID of everything processed and check before acting.
5. Deadlines are ambiguous
"By Friday" means different things depending on when it was sent. Resolve relative dates against the email's date, not today's, and where it's genuinely unclear, leave it null rather than guessing.
Start with one sender or one category. A processor that handles your entire inbox is a project; one that handles order confirmations is an afternoon and immediately useful.