How we build email intake (inbox to actionable) | Svolta

How we turn inboxes into actionables

Svolta pulls the inboxes together. One agent identifies what the email is. A second fills the object schema that starts the workflow. One client-reported desk: over 1,000 emails a day, 2–3 hours a day back across departments.

Mac SweenyFounder7 min read

A traditional company might have 200 to 300 emails a day. One clustered inbox, or several inboxes that nobody has actually pulled together. Someone opens them, decides what each message is, and types the useful bits into a job system, a warranty form, a spreadsheet. That is the desk. The hours sit in the sorting, the re-keying, and the messages that never become an object.

Svolta pulls the inboxes together. Then the work is not a smarter inbox. It is turning each message into an actionable: a job, a warranty claim, whatever the objects actually are in that operation. The object is what starts the workflow.

We do not start with the agents. We start with the process. Which inboxes. Which objects. Who currently sits the mail. What “done” means in the system of record. Process mapping is the first artefact. Software comes after.

Two agents, not one clever prompt

The first agent identifies what the email is. It has tools for context: the rest of the thread, a search across other emails, the usual thread tools. It is trying to answer a boring question. Is this a new job, a change to an existing one, a warranty claim, or something that should not create work at all?

The second agent — or a tool, if the object is simple enough — structures the data into the correct schema for that object. Customer, site, requested date, lines, claim type. Your fields. That write is what triggers and organises which workflow runs.

Identify, then schema. Skip the first step and you fill the wrong object. Skip the second and you have a summary sitting next to the job system. A chatbot that recaps the thread has not closed the seam.

The source might be a body, a thread, a PDF, a photo of a docket. Keep the file. The source is evidence. If the agent cannot tell what the email is, it should not invent an object.

Email and PDFs become a job recordIncoming email is read in an extract station. Customer, quantity, and date confirm and pack into a job record that writes into the job system. Site stays uncertain and peels to an exception queue so a person can review it.Email inExtractCustomerSiteQtyDateJob recordExceptionJob system
Email and PDFs become a job recordIncoming email is read in an extract station. Customer, quantity, and date confirm and pack into a job record that writes into the job system. Site stays uncertain and peels to an exception queue so a person can review it.Email inExtractCustomerSiteQtyDateJob recordExceptionJob system

A client-reported desk

One client we worked with ran over 1,000 emails a day across inboxes. There was no single dedicated FTE on email. A bunch of people touched it every day. A significant part of the day was managing, cleaning, organising. The error rate was really high.

They built this workflow. Client-reported, it took 2–3 hours a day back across entire departments.

That figure is not a guarantee. It is not an industry rate. It is not “we see this in construction.” It is what that desk reported after the agent was in. Your number is the signed pack on your workflow, or it is not a result we will sell you.

What 2–3 hours a day actually means

Those hours did not come from deleting one person. Nobody was sitting email as a full-time job. The time was spread: a bit of every morning, a bit of every afternoon, across people who already had other work. Cleaning the inbox is easy to underestimate because it never shows up as a role.

2–3 hours a day across departments is capacity. The people stayed. They spent it on the jobs and the claims, not on sorting mail. We are not attaching a dollar saving or an hourly rate to those hours. Client-reported. Not a measured Launch baseline for a prospect.

What a production slice includes

The use-case is email and PDF to the job system. This page is how we build it.

Workflow Launch is the commercial home. One named intake workflow, connected to the mailboxes and the system of record you already run, with a bounded normal path, an exception queue, quality checks, source records, a capacity dashboard from the signed pack, training, and 30-day stabilisation.

Launch starts at $14,995 AUD ex GST per workflow, including all scoping expenses. If you do not yet have a signed baseline for this seam, Workflow Scoping is the measurement step (from $2,995 AUD ex GST). Scoping for the same workflow is not charged on top of Launch. After go-live, AI Accelerator keeps the accepted system supported from $995/m AUD ex GST per workflow.

If you still need a person in your corner before you can name the objects, AI Consulting is $1,195/mo AUD ex GST. That is advice. It is not this build.

If this is the first workflow you are considering, start with volume, a KPI, an owner, and a stop. An AI readiness assessment is how you test whether the seam is ready to measure. Then write objects, not summaries.

Book a free consultation.

Bring one workflow this article made you think about. A 30-minute call checks whether Workflow Launch is the right next step. The service page remains the source for scope and pricing.

Book a free consultation