Contact Form 7 sends the email. Then what?

Contact Form 7 has been installed on millions of sites for a good reason: it does one job properly. You define a form, it validates the input, it sends the mail. It has survived fifteen years of WordPress churn by refusing to become anything else.

But look at where its job ends. CF7 hands the submission to your mail server and stops. Everything after that — deciding what the message is, how urgent it is, who should answer, and what to say — happens in your inbox, unaided.

For a site getting two enquiries a week, that is completely fine. The problem starts somewhere around ten a day.

What actually goes wrong

It isn’t that messages get lost. It’s subtler than that, and it compounds.

Everything arrives flat. A refund request, a partnership enquiry and someone asking your opening hours land as three identical-looking emails from wordpress@yoursite.com. Nothing about the delivery tells you which one costs you money if it waits until Monday.

They mix into everything else. Form notifications sit alongside plugin update nags, hosting invoices and newsletters. Sorting them is manual, and rules break whenever you change a form field.

There is no state. Email has no concept of “dealt with”. You reply, and the original stays in the thread looking exactly like one you haven’t answered. Whether something was handled lives in your memory, or in a spreadsheet someone stopped updating.

Replying is slow, and the slow part isn’t typing. It’s context reconstruction: opening the message, working out what they want, checking whether it is the same question you answered last week, and deciding on a tone. The words come last.

Nothing survives the person. When enquiries live in one inbox, handing them over means forwarding a folder. There is no record of what was asked, what was answered, or how long it took.

The two usual fixes, and why they miss

Most people reach for one of two things.

A form-entries plugin stores submissions in the database and gives you a table. That fixes the record-keeping problem — you can find things later, export them, prove what was submitted. It does nothing for triage. You still open every row and work out what it is.

A helpdesk solves triage properly, with statuses, assignment and SLAs. It is also a system you now operate: an inbox to configure, addresses to route, seats to pay for, and a migration to run. For a business fielding twenty enquiries a week, that is a large answer to a modest question.

There is a gap between “a table of rows” and “adopt a support platform”, and most WordPress sites live in it.

What the gap actually needs

Not automation. The tempting move is to have a model answer the messages, and it is the wrong one — the failure mode isn’t that AI writes bad replies on average, it’s that the worst one goes out too, in your voice, before anyone reads it. The refund demand, the legal threat, the person having a terrible week.

What the gap needs is preparation. When a message arrives, the questions are always the same: what is this, how urgent, and roughly what do I say? Those are answerable before you open it. Answering them ahead of time doesn’t remove your judgement — it removes the twenty seconds of reconstruction that happen before your judgement can start.

That is the whole idea behind Olmbox. Every submission to a form you choose arrives already summarised, categorised, prioritised, and with a draft reply attached. Then it stops and waits for you.

What that changes in practice

You open a list, not a folder. Each row already says what it is and how urgent it looks. The three that matter are visible without opening the other seventeen.

When you do open one, the draft is there. Sometimes it is right and you send it. Often you rewrite half of it — and rewriting half a reply is still faster than starting at an empty box. Occasionally it has misread the message entirely, which is exactly why a human clicks send.

Low-confidence analyses are flagged, because a short, vague message is precisely where a confident-sounding draft would be most dangerous. The flag isn’t the plugin apologising; it is telling you which items deserve your full attention.

And because every row carries a status, “have I dealt with this” stops being a memory problem.

What it deliberately does not do

It does not touch Contact Form 7. Your notification emails, validation and spam filtering keep working exactly as they did — Olmbox runs after CF7 has finished, so there is nothing for it to interrupt. If the AI request fails, the submission is still captured; you just get it without the analysis, and it tells you why.

It does not email anyone on your behalf. There is one code path that mails a visitor, and it runs on a confirmed click.

It does not replace your record-keeping. The log holds the most recent 200 submissions — it is a review queue, not an archive. If you need submissions kept forever, keep your form-entries plugin; the two do different jobs.

Is it for you?

Probably not, if you get a handful of enquiries a month. The honest answer there is that your inbox is fine.

It starts earning its place when enquiries arrive faster than you can keep a mental model of them — when you have caught yourself scrolling back to check whether you answered someone, or replying to the easy message first because the important one needs thought you do not have right now.

The claim is narrow and worth stating plainly: reviewing a prepared reply is faster than composing one from scratch, and knowing which three of today’s forty messages matter is worth more than any individual draft.

If that describes your week, the documentation covers installation and the review workflow, and the whole thing is on GitHub.