Automatic task creation from email no customer request stays buried in a thread
An email lands in the shared inbox and within minutes becomes a task in Asana, ClickUp, Jira or Notion: a one sentence subject, an owner, a deadline, the original message in the description and a link back to the thread. The notification goes to the person who has to act on it, in Slack or Teams. Nobody retypes email into the task system and nobody has to remember what was still outstanding.
- 28%of the working week goes on reading and answering email for people whose job is contact with others. McKinsey Global Institute report, The social economy, 2012
- 4 task systemsAsana, ClickUp, Jira and Notion; in each one the task is built from the same template and carries the same context
- 2 to 6 weeksfrom the workshop to a working workflow, tested on your own inbox and on your own email from the past few weeks
The problem
Why does a customer request get lost in the inbox?
The customer writes to a shared address. Three people see the message and each of them assumes one of the other two will reply. Somebody answers the first question in the thread, and the request in the third paragraph reaches nobody. The case comes back a week later, in the same thread, this time as a question about whether anything is happening.
An inbox will never be a task system. It has no owner, no deadline and no status, and the only trace that something needs doing is a bold font and the memory of one person. When that person takes a holiday or spends a day on the road, the knowledge of the case leaves with them.
The cost is countable. According to the McKinsey Global Institute report The social economy from 2012, a worker whose job is contact with people spends 28 percent of the working week reading and answering email, close to 13 hours. Part of that time is pure copying into the task system: subject, owner, deadline, a pasted link to the thread.
- A request stays in the thread, because nobody marked the email as work
- The task enters the system a week late and nobody knows why
- Two people do the same job, because both replied to the same email
- Only the author of the reply knows the state of the case, and today they are out
Why now
What changed, so that email turns into a task without retyping?
Business email now exposes an interface that lets a workflow watch one named mailbox or one label. Gmail and Google Workspace report a new message a second after delivery, and Microsoft 365 with Outlook do the same. The rule works on a shared inbox or on a label you create yourself, and it never touches the private mail of the team.
The second change is the language model. Before, you had to guess from a keyword in the subject line; now the model reads the body and pulls out what a person used to retype by hand: the task subject in one sentence, the priority, a suggested deadline, the customer and the type of case. That is a proposal, not a decision. In the workshop we agree what the model may close on its own and what goes to one person for approval. The connector layer sits in n8n, Make or a direct API integration, so nothing in the mailbox has to be replaced.
The third change is the AI agent. A workflow will create the task, but it will not answer a manager asking how many email requests have been waiting longer than two days, or which tasks from this week have no deadline. BOND, our company AI agent, answers that in a plain sentence in 5 to 10 seconds, with no login to the task system.
What changes
What does the customer service team get?
A task instead of a bold email
A message that meets the entry criteria lands in the task system within minutes of delivery. It has an owner, a deadline and a status, so it is visible on the board rather than in somebody else's inbox.
A task in Asana, ClickUp, Jira or Notion from the same template, whoever happens to be reading the mail
Context in the task, not just a subject line
The description holds the original body of the email, the sender, the attachments and a link that opens exactly that thread. Whoever picks the case up does not go hunting through their colleagues' mailboxes.
Body, sender, attachments and a link to the thread in one place
The model proposes priority and deadline, a person approves
The model reads the body and suggests a priority and a deadline, and a rule adds what follows from the contract: a customer with an SLA gets a shorter clock. How much the model decides on its own is agreed in the workshop and can be narrowed at any moment.
Three priority levels and a deadline counted from the delivery time of the email, not from the moment somebody noticed it
Nothing lands twice
A reply in a thread that already has a task is appended to it as a comment. A new email from the same customer about the same matter does not create a second task for a second person.
Matching on thread identifier, sender and case number, not on the subject line alone
The right person knows straight away
The notification goes to the account owner or to the team channel in Slack or Teams, following the assignment rule. Instead of asking who is taking this, there is a name on the task.
Assignment by customer, case type and availability, with holiday cover taken from the calendar
Questions about the backlog in a plain sentence
How many email requests have been waiting longer than two days. Which cases from customer X are open. How many tasks came out of the mailbox this month. The AI agent answers from the task system in seconds.
An answer in 5 to 10 seconds, with no report and no login to another tool
Proof
Do we work this way ourselves?
Yes, and we will say up front what the number does not show. We have no measurement of an email turned into a task at a client we are allowed to publish. What we have is our own rollout inside the agency our founders run, where inbound requests turn into records and notifications with no human in the loop. Same mechanics, same tools.
Built for ourselves. These are not client deployments but implementations inside the founders' own companies. We say so plainly, because proof you cannot verify is not proof.
JustBottheir agentJustIdea Agency, a performance marketing agency, around 30 people
- 23
- people from the company work with the agent
- 38
- systems wired in permanently
- 112
- processes run without a human
- 475
- thousand lines of the agent’s code
An AI agent wired into the task system, the CRM, Slack, the website forms and the data warehouse. First commit on 1 March 2026, and today 23 people use it.
8 of 38 systems it works in
Google Ads
Meta Ads- HubSpot
- ActiveCollab
- Ahrefs
GA4
Search Console
BigQuery
- Before
- A person read each request and decided alone whether to open a task from it, who to assign it to and by when. What reached the task system was whatever somebody remembered to retype.
- After
- The agent picks up the requests: it creates the record, checks for a duplicate and notifies the right person in Slack. A person joins at the point where the case needs judgement.
29,854 operations with no human in the loop over 30 days, of which 1,301 on inbound requests
And in your company
What if our inbox looks different?
Four sentences we hear in the first conversation, and what we answer to each of them.
We get a dozen or so emails a day, we cope with that.
Then we will say so plainly and we will not sell you a rollout. At a dozen emails a day with one person on the mailbox, a decent label and one rule in the task system is enough. The subject comes back when the mailbox becomes shared, when a second team joins, or when a customer gets a contractual response time.
We do not want AI reading our customers' email.
It works without a model: a rule on the sender, the label and a keyword in the subject opens a task with an empty description and a link to the thread. When a model is in play, the workshop settles which fields are sent to it, how long they are kept and which mailboxes are excluded from watching altogether.
Jira and Asana accept email themselves, why add anything?
If you have one queue, one project and a task carrying the email subject is enough for you, the native inbox in Jira or Asana is the better answer and we will tell you that. An outside workflow earns its place when the task has to reach the right customer project, with a priority, a deadline and a notification, and when a reply in the thread has to attach itself to the existing task.
We are afraid this will produce a thousand junk tasks.
That is why the entry criteria start narrow: one named mailbox, a list of senders, an exclusion for system messages and newsletters. Anything the rule does not recognise goes to an approval queue, where one person decides with a single click. For the first two weeks the workflow runs in a test project, alongside the current mailbox.
- Email and mailboxes
- Gmail and Google Workspace, Microsoft 365 and Outlook, shared inboxes, labels and folders
- Task systems
- Asana, ClickUp, Jira, Notion
- Team collaboration
- Slack, Microsoft Teams, Google Workspace
- CRM
- HubSpot, Pipedrive, Salesforce, LiveSpace
- Files and data
- Google Drive, Google Sheets, BigQuery, SQL databases
- Automation layer
- n8n, Make, Zapier, custom API integrations
What the rule does with a specific email
The kinds of message that most often land in a shared inbox, the signal we recognise them by, and what comes out of them. The starting scope is agreed in the workshop, because two kinds handled properly beat seven handled halfway.
| Kind of message | How we recognise it | What gets created |
|---|---|---|
| Customer request | sender on a domain mapped to a customer in the CRM | a task in the customer project, an owner, a deadline from the contract |
| Outage report | keyword in the subject or in the first paragraph | a high priority task and an alert on the team channel |
| Request for a quote | subject from a list, website form, an attachment with the enquiry | a task for the salesperson and a contact in the CRM |
| Document from a supplier | sender on the supplier list, PDF attachment | a task for finance and the file in the folder for that month |
| Reply in an open case | thread identifier already known to the task system | a comment on the existing task, with no new entry |
| Newsletter and system message | no-reply sender, exclusion list | nothing, the message stays in the mailbox |
| Email the rule does not recognise | no match against the entry criteria | the approval queue, decided by one person |
A first rollout usually covers the first two or three rows. We add the rest once the first ones have run in production for a full month.
How we work
Five steps from a shared inbox to tasks on the board
Every step ends with something you can judge before you decide on the next one.
Workshop
We take your mailbox from the past two weeks and break it down into kinds of case. We check how many of them genuinely need a task, who opens them today, how long the road from email to entry takes and what falls off it. We also write down the kinds of message that must never become a task.
Criteria and templates
We agree the entry criteria, the exclusion list, a task template for each kind of case, the assignment rule and the way the deadline is calculated. We decide how much the model does and how much a plain rule does, and we pick the tool: n8n, Make or an API integration with your task system.
Rollout in parallel
The workflow creates tasks in a test project, alongside the current work on the mailbox. For the first days we compare its decisions with the team's: what it caught, what it skipped, where the priority came out too high. The criteria are corrected against real email, not imagined email.
Switch-over and training
Once it checks out, the workflow creates tasks in the real projects, with error monitoring and a notification when a step fails. The person running the team learns to change the rules without us: a new customer, a new kind of case, a different deadline for the season, somebody switched off while on holiday.
Measurement after 30 and 90 days
We look at what can be counted: how many tasks came out of the mailbox, how many of them went to the approval queue, how many were closed straight away as unnecessary. We narrow or widen the criteria against what actually arrives, not against what we assumed in the workshop.
Before and after
How the day of the person on the shared inbox changes
Before
- The morning goes on reading 60 emails and deciding alone which ones are tasks
- The body of the email is retyped into the task system and the thread link pasted in
- A colleague is asked whether anybody has already taken the case the customer is chasing
- An overdue request is discovered from a second email from the customer
After
- Tasks from overnight mail are already on the board, with an owner and a deadline
- The context of the email sits in the task description and the retyping leaves the day
- The case has one owner, visible to the whole team
- A backlog shows up as a deadline in the system, not as a chase from the customer
The first tasks from email are visible on switch-over day. Entry criteria and the accuracy of priorities we judge after 30 days, the effect on handling time after 90.
For the person signing this off
What a head of customer service gets out of it
You stop being the memory of the team. Today you are the one who knows the customer wrote about something last week, and the question about whether anybody took it comes back to you. After the rollout the answer is on the board: who, by when, in what status, with a link to the thread.
The second thing matters more in front of the board. You know how many cases arrived by email, how many of them broke the contractual response time and which kind of case is where the team jams. That is an argument in the conversation about a new hire or about changing the scope of a contract, and today you do not have it.
- Criteria and task templates written down, independent of one person on the mailbox
- The number of email cases and missed deadlines visible in the task system
- The workflow runs in parallel, so the current work on the mailbox holds until the tests are done
- You change the rules yourself, with no ticket raised with us and no waiting
What it costs
The workshop has a published price, the rollout is quoted after it
The process workshop costs EUR 3,500 net per week, and runs from one to seven weeks. Task creation from email usually needs one week, because the process is narrow: from a message to an entry in the task system. We quote the rollout after the workshop, once it is clear how many mailboxes and kinds of case are in scope and what state the task system is in.
You pay the automation platform and the language model directly to the provider, and when n8n sits on your own infrastructure you do not pay for it at all. A single query costs the provider roughly EUR 0.005 to 0.07. No margin from us.
Process workshop
EUR 3,500 net
per week, and task creation from email is usually one week
A self-contained piece of work. It ends with the entry criteria written down, the task templates and a plan you could execute without us.
- A breakdown of two weeks of your mailbox into kinds of case
- Entry criteria, an exclusion list and a task template for each kind
- A tool recommendation: the native inbox in your task system, n8n, Make or the API
- The metrics to measure after 30 and 90 days
- Most popular
Workshop and rollout
Quoted after the workshop
scope follows from the number of mailboxes and kinds of case
The option most companies choose. A working workflow 2 to 6 weeks after the workshop, tested on your own live email.
- Everything in the workshop
- A workflow in n8n, Make or over the API, wired into the mailbox and the task system
- Content recognition, priority, deadline and an approval queue
- Replies appended to existing tasks, with no duplicates
- A parallel rollout, a monitored switch-over and training for the team
Email tasks and an AI agent
Quoted after the workshop
for teams that ask about the state of cases every day
Everything in the rollout plus BOND, which answers questions about the backlog and the state of cases in a plain sentence.
- Everything in the rollout
- An AI agent wired into the task system, the mailbox and the CRM
- Alerts on overdue cases and on requests with no owner
- Access for the team and the manager, in English and in Polish
The workshop ends with a document that stands on its own: criteria, templates and a rollout plan. If it turns out the native inbox in Jira or Asana is enough, we say so and show you how to set it up. The matter then ends with the workshop.
Frequently asked questions
What is automatic task creation from email?
It is a workflow that watches a named mailbox or a label and opens a task in your task system from every message that meets the entry criteria. The task gets a subject, an owner, a deadline, the original body in the description and a link to the thread, and the notification goes to Slack or Teams. The person handles the case rather than retyping the email.
How long does the rollout take?
One week of workshop and 2 to 6 weeks of rollout, depending on the number of mailboxes and kinds of case. For the first two weeks the workflow runs in a test project, alongside the current work on the mailbox, so the team can compare its decisions with their own before anything is switched over.
Does the model read all of our email?
No. We watch only the mailboxes and labels you name, most often one shared service inbox. In the workshop we agree which fields of a message are sent to the model and how long they are kept. It also works entirely without a model, on a rule built from the sender and a keyword in the subject line.
What happens to an email the rule does not recognise?
It goes to the approval queue with a note on why it is there: unknown sender, no match to a kind of case, a message on the exclusion list. One person decides with a single click whether a task is created. The message never disappears and it never turns into a task without a basis.
What about a reply in a thread that already has a task?
It is appended to the existing task as a comment, with the body and the link. Matching runs on the thread identifier, the sender and the case number rather than on the subject alone, because customers often change the subject halfway through a conversation. That way one case stays one task with one owner.
Who sets the priority and the deadline?
A rule calculates the deadline from the contract and from the delivery time of the message, and the model suggests a priority from the content. The last word belongs to a person: how much the model decides is agreed in the workshop and can be narrowed at any moment, for example so that the model only proposes and a person opens the task after one glance.
Do we need n8n or Make when Jira already accepts email?
Not always. With one queue and one project the native inbox in Jira or Asana is enough and we will tell you so. An outside workflow pays for itself when the task has to go to the right customer project, with a priority, a deadline, a notification and replies appended to an existing case.
What does it cost to run a workflow like this?
The workshop is EUR 3,500 net per week and the rollout is quoted after it. You pay the automation platform and the model directly to the provider, with no margin from us; with n8n on your own server that cost is zero. Maintenance on our side comes down to changes in the rules, and after the training you make those yourself.
Let us see what actually lands in your inbox
The free consultation takes 30 minutes. You tell us how many people work on the shared mailbox and what kinds of case arrive by email. We show you which of them can become tasks straight away and which need the task system tidied up first. You do not have to share your mail or your systems at this stage.
We run at most two rollouts at a time, so that someone is genuinely sitting on each of them.
Book a free consultationPS. If a customer wrote to you this week asking whether anything is happening with their case, that is exactly the problem. A request left in a thread has no owner and no deadline, so nobody is watching it. That is where the workshop starts: with your mailbox from the past two weeks.