Reading an inbox to find out what matters is the least valuable half hour of most working days. This course builds a summary that arrives before you open Gmail, telling you what needs a decision, what needs a reply, and what you are still waiting on.
⏱ 4 min read
The time an inbox costs you is not the time spent replying. It is the triage — opening forty messages to find the four that need you, losing the thread twice because something urgent appeared mid-scroll, and the low-grade anxiety that something important is buried in there.
A daily summary attacks the triage specifically. Instead of reading everything to decide what matters, you read one page that already decided, then open only the messages you choose to act on. For most people that is twenty to forty minutes a day, and the compounding effect is larger than the arithmetic suggests because you stop starting the day reactively.
| Section | What it answers | Why it earns its place |
|---|---|---|
| Needs a decision | What is blocked on you | The only genuinely urgent category |
| Needs a reply | Who is waiting on an answer | Prevents the slow-drip reputation damage of silence |
| Waiting on | What you asked for and haven't received | The highest-value section, and the one nobody tracks |
| FYI | Worth knowing, no action | Lets you skip the message entirely |
| Ignored | What was filtered out | Builds trust that nothing was silently dropped |
Everyone has a mental list of things they have chased once and not received — a quote from a supplier, a client's content, a signed contract. It lives in your head, degrades over a week, and costs real money when something falls through. An AI summary that reads your sent mail alongside your inbox can reconstruct that list every morning, which is something no email client does well.
It does not reply for you, and you should not let it. It does not catch things that arrive after it runs — these tools run on a clock, not on a trigger, so a summary sent at 7:30 knows nothing about the 9:15 emergency. And it does not replace reading the important messages themselves; it tells you which ones those are.
Thirty to ninety minutes to build the first one, plus a week of tuning the prompt as you notice what it over-reports and under-reports. Running costs are usually nothing beyond a subscription you already have. If after two weeks you are still reading the full inbox anyway, the summary is not specific enough yet — that is a prompt problem, and module three fixes it.
It pays off most for people with high inbox volume and real decision authority — owners, principals, account managers, anyone whose day is interrupted by other people's requests. It pays off least for roles where every message needs a considered individual reply anyway, such as detailed technical support, because the triage was never the bottleneck.
If your inbox is under about twenty messages a day, you will probably save less than the setup costs. Build it anyway for the "waiting on" list if chasing is part of your week — that section earns its keep at any volume.
⏱ 4 min read
Three routes get you to the same place, with different trade-offs between setup effort, flexibility and cost.
| Claude + connector | Zapier / Make | Own script | |
|---|---|---|---|
| Setup time | 15 minutes | 45–90 minutes | Half a day or more |
| Running cost | Your subscription | Per task, adds up | API usage only |
| Flexibility | Prompt-level | Step-level, many destinations | Total |
| Visibility when it breaks | The run output | Run history per step | Whatever you log |
| Best for | One inbox, one person | Multi-step, multi-destination | Embedded in a product |
These are scheduled, not triggered. Claude's scheduled tasks run at a time you choose; they do not fire because a message arrived. Zapier and Make can trigger on new mail, but a summary built on a per-message trigger is just a notification — the value is in the batch. Pick a time, accept that anything arriving afterwards waits for tomorrow, and set the window so it covers everything since the last run.
In Claude, Gmail is added through the connectors list in settings and authorised with your Google account; once connected it is available to scheduled tasks as well as chats. A task that only touches connectors can run in the cloud, so your laptop does not need to be awake. In Zapier or Make, the Gmail connection is the same OAuth grant through their app directory. In all three cases, grant it to the account whose mail you want summarised and nobody else's.
If you run several addresses — a personal one, a business one, a shared info@ — resist summarising all of them in one task. The priorities differ, the exclusions differ, and a blended summary is harder to act on than either inbox alone. One task per mailbox, or one task for the mailbox that actually drives your day and nothing for the rest.
Priority Inbox, filters and labels are genuinely good and worth setting up regardless — they reduce what arrives. What they cannot do is read across messages and tell you that you asked a supplier for a quote nine days ago and never got one. Rules sort mail; a summary reasons about it. Use both: the better your filters, the cleaner the input to the summary.
⏱ 3 min read
The prompt is the whole product. A vague one produces a summary of your inbox; a specific one produces a decision list.
"Omit empty sections, do not pad." Without it you get a cheerful paragraph explaining that nothing needs a decision today, every day, and you stop reading. "Do not reply, archive or relabel anything." Read-only by default is the right posture for a summary, and stating it removes any ambiguity about what the task is allowed to do.
Asking for "a summary of my email." You will get a readable paragraph describing your inbox, which is not actionable and which you will stop opening by day four. Sections with names and rules are what make it useful.
Describing priority abstractly. "Important clients" means nothing to a system that has never met your clients. Name them. The prompt should read like a handover note to a new assistant: here are the four accounts that matter, here is the phrase that means money, here is the person whose emails always need same-day answers.
Ask for notes, not prose. Sender, one-line gist, the specific ask. No greetings, no sign-off, no summary of the summary. Four hundred words is a generous ceiling for a day's inbox — if yours regularly runs longer, tighten the exclusions rather than raising the limit, because the length is usually a filtering failure rather than a genuinely busy day.
Add a line telling it to say how confident it is when a classification was a close call: "if you were unsure whether something needed action, put it in FYI and say you were unsure." You get a short, honest hedge instead of a confident misfile, and over a few weeks those hedges show you exactly which rule in your prompt is ambiguous.
Keep the prompt in a note or doc, not only inside the task. You will revise it a dozen times in the first month, and having the previous version to fall back on saves re-deriving an instruction that was working fine until you "improved" it.
⏱ 4 min read
Twenty minutes, start to finish. Do it now rather than later — the first version only has to be better than reading everything.
Add the Gmail connector in your settings and authorise the Google account you want summarised. Granting access to the wrong account — a personal one, or a shared alias — is the most common first mistake, and it is annoying to unwind.
Paste your prompt into a normal chat and run it against this morning's mail. Do not schedule anything yet. You are checking three things: did it find the right messages, did it classify them the way you would have, and is the output short enough that you would actually read it at 7:30am?
Run it manually for three mornings and fix what annoys you each time:
| Symptom | Fix |
|---|---|
| Too long | Cap each section, and cap the word count |
| Full of newsletters | Add the specific senders to the ignore line |
| Missed something important | Name that client or keyword in the priority line |
| Vague one-liners | Ask for the specific ask or deadline in each gist |
| Nothing in "waiting on" | Tell it explicitly to search sent mail, with a lookback window |
Once three consecutive runs are useful, turn it into a scheduled task: weekdays, 20–30 minutes before you normally start. Avoid exactly 7:00 or 8:00 — scheduling systems bunch at the hour, and 7:28 arrives more reliably than 7:30.
Set the window to "since this task last ran" rather than a fixed 24 hours, so a Monday run covers the weekend. And give the task its own name you will recognise in a list six months from now.
Check that it actually fired each morning, that the window did not double-count or skip, and that a day with unusual volume did not produce something unreadable. If a run fails silently, you want to find out in week one, not in month three when you have started trusting it.
Before you trust the output, run it against a day you already know well — ideally a busy one from last week. You know what mattered that day, so you can grade the result honestly. Three questions: did it surface everything you would have flagged, did it flag anything you would not have, and did it get any fact wrong?
The third question is the important one. A summary that over-reports is annoying; a summary that quietly misstates a deadline or a number is worse than no summary, because you will act on it.
Occasionally a run comes back thinner than expected. The usual causes are a window that did not cover the gap since the last run, mail living in a label or tab the search did not include, or a permission grant on the wrong account. Check them in that order before rewriting the prompt — most "the AI missed things" reports turn out to be a scope problem rather than a reasoning one.
⏱ 3 min read
Where the summary lands decides whether you read it. The rule: deliver it to the place you open first, not the place the automation is easiest to build.
| Destination | Good for | Watch out for |
|---|---|---|
| Email to yourself | Reading on a phone before you start; searchable archive | It is a message in the inbox you were trying to escape — filter it to its own label |
| Slack DM or channel | Teams; summaries others should see | Scrolls away fast; pin or thread it |
| Todoist | Turning the "needs a reply" list into actual tasks | One task per item or it becomes an unreadable blob |
| A doc or page | A running archive you can look back through | You have to remember to open it |
Send it from the automation to yourself with a consistent subject line — "Daily brief — {date}" — and set a Gmail filter that labels it and skips the inbox if you prefer to go to it deliberately. The consistent subject is what makes six months of briefs searchable later, which is more useful than it sounds when you are trying to remember when a client first raised something.
A Slack incoming webhook is a URL that posts into one channel. Create it once in a Slack app, paste it into Zapier, Make or your script, and the summary arrives as a message. For a team, a shared channel turns a personal habit into visible coordination — though be careful about what client detail that exposes to everyone in the workspace.
The strongest version splits the output: the full summary goes to email or Slack, and only the "needs a reply" and "needs a decision" items become tasks, each with the sender in the title and a due date of today. Resist sending the whole summary as one task — a task you cannot complete in one action is a task you will keep deferring.
Two destinations is usually one too many: you end up reading neither carefully because each might be the authoritative one. Start with email, and only add a second channel when you have a specific reason, such as a team that needs the same picture.
Whatever the destination, the summary should be readable on a phone without scrolling twice. Section headings in caps or bold, one line per item, sender first. The test: can you tell within ten seconds whether this is a morning that needs rearranging? If it takes longer, it is still too long.
Whichever destination you choose, make sure the summaries are searchable afterwards. Six months of dated briefs is a quietly useful record — when a client asks when something was first raised, or you need to reconstruct a decision, it is faster than searching the inbox itself.
⏱ 3 min read
You are about to give an automated system standing access to your email, which is the single most sensitive asset most businesses have. That is a reasonable thing to do with reasonable guardrails, and an unreasonable thing to do without them.
Check your client contracts and any confidentiality terms before pointing an automation at a mailbox that contains their material. Many agency agreements contain subprocessor or confidentiality clauses that are worth reading once with this in mind. Where a client's data is genuinely restricted, the safer design is to summarise only a label you control — internal mail, or a specific project — rather than the whole inbox.
Read the provider's own documentation on how your data is handled and retained, rather than assuming. This is a legitimate due-diligence question and the answer is published; it is also the first thing a security-conscious client will ask you.
Point the task at a week of real mail and read the output line by line, asking one question: would I be comfortable if this exact text appeared in the wrong channel? If any line fails that test, tighten the exclusions before you schedule anything.
Have an answer before you need one. If a summary ever contains something it should not — a credential, a confidential client matter, a message from an excluded category — the sequence is: delete the summary from wherever it landed, revoke the connector, tighten the exclusion that failed, and only then re-enable. Treat it as you would any other data incident, including telling the client if their material was involved.
This is not a likely scenario with a read-only summary going to your own inbox. It becomes likelier the moment the destination is a shared channel, which is the strongest argument for keeping delivery private.
⏱ 3 min read
Once the inbox summary is running, the pattern transfers. Each of these is the same four pieces — a window, a filter, a prompt, a destination — pointed at a different source.
Read-only unless you have a specific reason otherwise. Explicit exclusions, named. Honest when there is nothing to report. Never invents a fact, an amount or a deadline. And one destination you actually open.
Three or four scheduled summaries is usually the ceiling for one person. Past that you are back to triaging — just triaging summaries instead of messages. If a new one does not replace an existing habit, it is probably not worth the maintenance.
The natural next step is not more summaries but a summary that drafts. Once you trust the classification, let it prepare replies for the routine categories — holding replies, scheduling confirmations, standard answers — as drafts you approve, never as sent mail. That keeps the human decision in place while removing the typing, and it is where most of the remaining time saving lives.
As you build more of these, keep every working prompt in one document with a line on what it does and when it runs. It is the thing you will copy from when a client asks for something similar, and it is what lets you rebuild quickly if a platform changes under you.
Every variation above is the same skeleton: a window, a filter, a prompt, a destination. When a new idea arrives, write those four lines first — before opening any tool — and most of the build is already decided. The ones that are hard to express in four lines are usually the ones that should be a trigger-based workflow or a report, not a scheduled summary.
Scheduled jobs accumulate quietly. Twice a year, open the list and ask of each one: did I read the last five outputs, and did any of them change what I did? Anything failing both questions should be paused rather than left running — an unread automation still holds live access to your data, which is a cost even when the output goes nowhere.
Most people start with the inbox summary and end up with three or four small scheduled jobs that collectively replace the first hour of their day. That is the realistic ceiling of this technique, and it is a genuinely good return for an afternoon of setup — provided each one stays read-only, stays narrow, and stays something you actually open.
⏱ ~6 min
Answer all ten, then score yourself. Explanations appear after scoring.
All consulted October 2026. Search, AI and platform products change fast — check the primary documentation before acting on anything time-sensitive.
We build these for clients every week — inbox summaries, calendar briefings, CRM follow-up digests, invoice chasers — wired into the tools you already pay for.
Most setups take us a day or two, including the privacy review. We set this up in days, not weeks.
CLIKT.com: Northeast Ohio web, SEO & AI since 1996.