AI reads the email and creates the job. A demonstration, not science fiction.

One concrete flow end to end: an ordinary enquiry arrives, the system pulls out the line items and the company ID, fills in the company from the public registry, creates the job and stops at human approval. What you need for it, and where its limits are.

Marek Raja

Most demonstrations of AI in a company are either too vague (“it streamlines processes”) or too distant (“an agent will run your business”). This is something in between: one concrete flow that runs today at companies taking enquiries by email.

The starting point

A company receives five to twenty enquiries a day by email. They aren't forms - they're ordinary letters from people:

Hello, we'd need 12 units of cabinet type B by the end of September. Please invoice to company ID 27604977, Dřevo Morava s.r.o. Thanks, Jiří Novák

Today it works like this: somebody in the back office reads the email, opens the system, retypes the item, quantity and date, looks up the company by its ID, fills in the billing details and creates the job. Three to five minutes per enquiry. Fifteen enquiries a day is an hour of pure retyping.

The flow, step by step

1. The email lands in the system. Not in a separate mail client - in a mailbox that's part of the system and can create records. This is the boring but decisive part.

2. AI pulls out what matters. The item “cabinet type B”, quantity 12, the date “by the end of September” resolved to an actual date, and the company ID 27604977. The rest of the letter - the greeting, the thanks - it ignores.

3. The system fills in the company from the public registry. The ID is enough. In the Czech Republic that's ARES; the name, address and legal form come straight from it, so nobody retypes anything or has to watch for typos. That's covered in more detail in ARES and automation.

4. The job is created. With every field filled, with a link to the original email, and with the client attached to an existing record - or a new one created if it's a new company.

5. It stops at a human. The job sits in a “Waiting for approval” state. The back office sees it in a view, checks it in ten seconds and confirms. Or corrects it, if AI understood something differently.

From a letter to a job, without retyping

AI reads, the registry fills in, the system creates. But the last step stays with a person - and that's exactly why it's usable.

Why step five is the important one

Without an approval step nobody sensible would switch this flow on. AI does occasionally get it wrong - it reads “12 units” as 12 when it meant twelve packs of ten. It misreads a date that was conditional in the text.

Errors happen. The question is whether they surface in ten seconds at approval, or in three weeks when the wrong delivery arrives.

A practical setup that works: for the first month a person approves one hundred per cent of jobs and notes how often they had to intervene. Once that drops below ten per cent, some flows - typically repeat orders from regular clients - can run without approval, leaving the rest to be checked.

What happens when AI can't identify something

The field stays empty and the job is created incomplete - with a note saying what's missing. That's markedly better behaviour than guessing. A system that would rather fill in a probable value does you more harm than good.

What you need for it

Nothing exotic, but three things have to be in place:

WhatWhy it's needed
Email inside the systemSo the message has somewhere to land and can create a record
A data modelThe job has to know it belongs to a client - otherwise there's nothing to attach
A clear approval ruleWho confirms, and what happens on rejection

The last one is organisational rather than technical, and it's usually the only thing that actually causes delay.

Where the limits are

Let's be concrete about what this flow won't handle:

  • Enquiries with no company identification. If there's no ID or unambiguous name in the email, the system can't guess who it's from. It creates the job with an empty client.
  • Complicated pricing arrangements. “Same as last time, but with that discount we discussed” isn't a value that can be extracted from text.
  • Attachments with non-trivial content. A scanned handwritten order is a different problem from text in the body of an email.

In all three cases the correct behaviour is the same: create an incomplete record and let a person fill in the rest. It's still less work than retyping everything.

What email as part of a record looks like is on the Email in the app feature page. A broader overview of what AI can do in a company today is in 5 things AI can do in your company. The whole subject of process automation is covered in the guide to automating business processes.

Common questions about creating jobs from email

How many enquiries will AI handle without intervention?

It depends how consistent they are. At companies where enquiries come from regular clients in a similar shape, the proportion is high. With very loose text from varied senders, expect AI to pre-fill and a person to finish - which is still a saving.

What about spam and unrelated mail?

Record creation is switched on for a specific mailbox (typically orders@ or enquiries@), not a personal inbox. Messages AI doesn't judge to be an enquiry don't create a record.

Does the original email stay accessible?

Yes, and that matters. The job links to the message it came from, so you can always see what the client actually wrote - including anything that didn't make it into a field.

Describe how enquiries reach you.

Apexloop builds the app around you