Client Communication on a Web Build: What AI Actually Fixed

Every web design project has one job that never gets done on time, and it isn't the build. It's the email that tells the client what's happening.

We know how that goes, because we've done it. You're three hours into a layout problem, the client isn't on your mind, and the update you meant to write on Tuesday still isn't written on Friday. Nothing has gone wrong with the site. Everything has just gone quiet. From the client's side of the desk those two things look identical, and the second one is the one that costs you the relationship.

So client communication on a web design project is the part of our workflow we changed most this year, and we changed it in a way that sounds worse than it is: we connected our project mailbox to an AI assistant. This is what that actually altered, mapped onto our five-step process, with the mechanism named rather than waved at.

Disclosure, and you should have it before anything else. The connector we use is Mailbox MCP, and it's ours. 365i Web Design, 365i and mailbox-mcp.com are the same property, run by the same person. We built the thing we're about to describe using it, and we sell it. You'd have found that out eventually and it would have annoyed you, so here it is at the top.

Why client communication breaks on a web design project

It isn't laziness and it usually isn't disorganisation. It's that the update email is the only task on a build with no deadline attached to it. The staging site has a date. The content deadline has a date. The client update has whenever you get round to it, which is a date that keeps moving.

Every agency intends to keep clients updated. Far fewer have a mechanism that makes client updates actually happen during the week the build is going badly, which is exactly the week they matter most. So clients go quiet, and the silence gets read as trouble.

The numbers back up how common the damage is. Wellingtone's project management research, reported by Productive, found that only 29% of agencies mostly or always complete projects on time, against 43% who mostly or always come in on budget. Money is easier to control than time, and the thing that eats the time is very often the waiting: for an answer, for a decision, for a sign-off that nobody chased.

Three failures do most of the harm on a website build, and they're all the same failure wearing different hats.

• The client goes quiet because they don't know what's happening. Silence from us reads as trouble, so they stop asking and start worrying.
• A question asked in week two is still unanswered in week five. Not refused. Just buried under forty messages, and nobody has read back far enough to find it.
• Sign-off sits unchased. We don't know whether the approval email arrived, was read, or was quietly deleted by a spam filter, so we guess and wait.

Every one of those is fixed by the same email, and that email is the one that gets bumped.

What we connected to the project mailbox

Mailbox MCP is a remote MCP server. You connect a mailbox you already own, and your AI assistant can then actually use it: search it, open messages, compose from your own address, reply inside the right thread, move things between folders. Our sister site has already written up what the connector is and how you attach one, so I won't repeat it here. This piece is about running client projects through it.

The surface is 28 mail tools on every mailbox. A Microsoft 365 mailbox whose consent covers the diary gets up to 21 calendar tools on top. "Up to" is doing real work in that sentence: the calendar half is registered from a measured capability set rather than an assumed one, so Microsoft is offered all of them and a Google or CalDAV diary is offered the subset its server can actually answer for. Two agencies can connect the same product and be handed different tools, and both are right.

Those counts come out of the source, not out of a brochure. That matters here, because the rest of this article names specific tools, and every capability described below is one that exists.

Reading the whole thread, not the last email

This is the single biggest quality change and it's the least impressive-sounding one.

read_thread returns the entire conversation in one call, oldest message first, pulling from the folder the message is in and from Sent as well, because half of any client conversation is what you wrote yourself. It strips each message's quoted copy of the one before it, so a twelve-message thread doesn't arrive as the same text repeated twelve times.

The effect on a web build is not subtle. A week-five update written from the whole thread answers the question the client asked in week two, because the question is right there. A week-five update written from the last email answers whatever was most recent and leaves the client thinking, again, that nobody is listening.

Paul Boag, who co-founded the agency Headscape and has been working on the web since 1994, makes the point better than I can, and he made it about feedback rather than about software:

"I highly recommend allowing all stakeholders to feedback directly to you. Not only does it allow you to participate in the discussion, but it also puts you in control because you are the only person with all of the feedback, allowing you to pick and choose what feedback you decide to act upon."

Paul Boag, 4 Reliable Steps For Managing Client Feedback

Read that again with the emphasis on "the only person with all of the feedback". Boag is describing the advantage of holding the complete picture, and he's right that it's an advantage. What he's assuming, reasonably, is that you can hold it. On a fourteen-day build with thirty-odd messages you can. On a longer one you can't, and neither can I, which is why the picture drifts and things get missed. The thread is the record of who holds what, and the tool that reads all of it in one go is the tool that hands the complete picture back to the person who is supposed to have it. It doesn't make a designer more diligent. It removes the bit where diligence depends on memory.

Discover and Design: questions that stay answered

Steps one and two of our process are where most of the detail arrives and where most of it later goes missing. Brand assets, the exact company name for the footer, who signs off the colour palette, whether the old phone number is still live.

search_emails searches several folders in a single call, so "where's the logo they sent" covers INBOX, Sent and the project folder at once rather than three times over. find_contact pulls the address of the person who approved something eighteen months ago, on a different project, when nobody can remember their surname.

Neither is clever. Both remove a specific class of client-facing embarrassment: asking somebody for a thing they've already given you. If you want the wider case for why the details you gather at this stage are worth this much fuss, we've written about what actually earns a return visit, and the answer is nearly always specificity.

Build: the draft we still send ourselves

Step three is where the site gets made, and on most of our projects that means a WordPress build. It's also the stage where the client hears from us least, because the work is absorbing and the progress is hard to describe. So this is where the drafting matters most.

Here's the rule we won't move on. draft_reply puts a draft in the Drafts folder. It doesn't send anything. We open it in Outlook, read it, change what's wrong, and press send with a human finger.

Since 3 September 2026 there's also update_draft, which revises a draft in place instead of deleting it and making a new one. That sounds like housekeeping and isn't: it means the version you've been editing is the version that goes out, rather than an earlier copy that got resurrected while a stale one sat in the bin.

People assume the draft-first rule is a limitation we haven't got round to lifting. It isn't. It's the design, and the protocol this is all built on says so out loud:

"For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny sampling requests." Applications SHOULD "allow users to view and edit prompts before sending" and "present generated responses for review before delivery".

Anthropic, Model Context Protocol specification, Sampling

What I'd point at in that wording is the word SHOULD, in capitals, which in a specification is not a suggestion dressed up politely. It's the strongest recommendation the document can make short of a requirement. And the two clauses under it are the interesting part: view and edit before sending, review before delivery. Both are about the moment before the thing becomes irreversible. An email to a client is exactly that kind of moment. You cannot unsend a wrong figure, a promise about a date you can't hit, or a paragraph that reads as though nobody has looked at the project in a fortnight. So the draft sits in Drafts and a person decides. We wouldn't ship it any other way, and if you're an agency that wants mail going out without a human reading it, don't do this, and don't buy ours.

Launch: chasing sign-off, and the two questions everyone confuses

Launch is where waiting turns expensive, because a build that's finished but unapproved is a build you can't invoice and can't stop thinking about.

Two tools answer two questions that get muddled together constantly. check_bounces answers did it arrive. check_receipts answers did they read it. Those are not the same question and the difference is the whole of a chase.

The two sign-off questions, and which tool answers which

The question	The tool	What you do next
Did the approval email arrive at all?	check_bounces	If it bounced, the address or their filter is the problem. Ring them. Don't resend blind.
Did they open it?	check_receipts	Delivered and unopened is a nudge. Opened and silent is a decision they haven't made yet, and needs a different email entirely.
Is it just sitting there?	Neither. That's a phone call.	No tool fixes a client who is avoiding a decision.

Read receipts are worth a caveat, since plenty of clients have images blocked and plenty of mail clients suppress them. A receipt that comes back is information. A receipt that doesn't is not evidence of anything, and treating it as evidence is how agencies end up sending a passive-aggressive follow-up to somebody who replied an hour earlier from their phone.

Support: filing a finished build so it can be found in two years

Step five is the long one. Maintenance and support can run for years after launch, and the correspondence from the build is what you need when somebody asks in 2028 why the contact form goes where it goes.

move_email takes up to 500 messages into a project folder in one call, preserving flags and the internal date, so a build's correspondence ends up in one place instead of scattered across an inbox by date. It's the least glamorous thing in this article and the one I'd miss most.

Booking the meeting against the diary we already keep

The calendar tools work against the diary you already use, not a new one you have to adopt. check_availability and find_meeting_times answer when we're free, and schedule_meeting, update_meeting, cancel_meeting and respond_to_invitation handle the rest of a meeting's life.

How many of those you get depends on your provider, and this is the honest bit that most tooling pages skip. Microsoft 365 answers for all of them. Google and CalDAV diaries answer for a measured subset, because the server is asked what it can actually do rather than assumed to do everything the standard permits. If your diary can't do free/busy lookups, you won't be handed a tool that pretends it can.

Why the client cannot tell, and why that is the point

There's one rule written at the top of the product's own documentation, and it governs everything else:

A user must not be able to tell, from Outlook or webmail, that a message was handled by us rather than by them.

That reads like an engineering standard. It's a design standard, and on a client project it's the one that decides whether the relationship survives contact with the tooling. Work through what it forces:

• The reply lands inside the existing thread, with correct In-Reply-To and References headers, so the client's own reply history stays intact and their mail client doesn't fork the conversation.
• It carries our signature, from the identity it was sent as, because a message from an agency with no sign-off looks like it came from a system.
• The Sent copy is filed exactly once. Not twice, not never. Our records stay straight without anybody tidying.
• Reading never marks anything as read. Nothing goes quietly grey behind your back, so the unread badge still means what you think it means.

Get any of those wrong and the client doesn't file a bug report, they just form an impression. An update that arrives as a broken new thread with no signature, sitting outside the conversation it belongs to, tells a client they're being processed by something rather than talked to by somebody. That's not a technical failure. It's a design failure, and it's the kind we'd sack ourselves for on a website.

There's a neighbouring problem worth naming while we're here, because we've written about it before: clear writing now gets dismissed as AI-written, which puts anyone drafting with assistance in an odd bind. Our answer is the same as it was there. Write like a person, keep the specifics in, and don't let anything go out that you haven't read. A vague, tidy, structurally perfect update is the tell. A specific one that mentions the actual staging URL and the actual outstanding decision is not.

One connector, one mailbox

For a post about client communication, this is the paragraph that should earn your confidence, and it's the simplest thing in here.

One connector opens exactly one mailbox. The assistant can only ever open the mailbox it was given. There's no mailbox-selection argument for a model to get wrong, no dropdown of accounts, no chance of a reply going out from the wrong identity or a client's thread being filed into somebody else's account. The scope isn't a policy the model is asked to respect. It's the shape of the connection.

That also means "search everything" is per mailbox, which is a real limitation and I've listed it below rather than hiding it here. It's the price of the guarantee, and on client work it's a price worth paying. If you want the longer version of the safety question, there's a guide on whether it's safe to give AI your email.

What this AI email assistant does not do

A list of capabilities with no matching list of limits isn't an article, it's a brochure. So:

• It drafts. It does not decide. Every client-facing message is read and sent by a person. That's a deliberate rule, not a feature waiting to ship, for the reasons in the specification quoted above.
• There is no meeting transcription and no note-taker. Nothing records a call, nothing joins a meeting, nothing produces a transcript. What exists is that it reads the thread and drafts the summary or the agenda, which is a different job. If you want notes taken in a meeting, this is not that, and no amount of wishing makes it that.
• One call cannot span mailboxes. Per the section above. If your project mail is split across two addresses, that's two connectors and two searches.
• It's metered, and the ceiling is published. Free is 5 calls a day per mailbox. Pro is 1,000 a day per mailbox, and that's a ceiling rather than "unlimited", because a long conversation spends calls on reading and searching and re-checking, not just on sending. Pro is £34.99 + VAT per mailbox per year. The pricing page carries the current figures.
• Calendar capability varies by provider. Microsoft gets everything, others get a measured subset.
• It will not fix a client who doesn't want to decide. Nothing does. That's a phone call, and it always was.

What we changed on client projects, and what we are watching

I want to be careful here, because this is the part where an agency blog usually produces a percentage.

What I can tell you is countable. Between 18 and 31 August 2026, a fortnight, we ran a complete web build through this mailbox for an accountancy practice in Hampshire, the sort of professional services site we build most often: proposal, hosting plan, five extra pages, a Google Business Profile handover, two client references built and staged behind approval flags, and the sign-off conversation around all of it. Thirty-one client-facing messages in fourteen days on one project. The Drafts folder is empty, which is the shape you'd expect: drafts were opened, edited, sent, and left nothing behind.

What I can't tell you is how much time it saved, because we didn't measure it, and a figure invented after the fact is worse than no figure. I also can't tell you what the client thought, because their replies land in a different mailbox and I'm not going to characterise a reaction I can't point to. If that's the sentence you wanted from this article, I'm sorry, and I'd rather disappoint you than make one up.

Here's one that isn't flattering, though, and it's the most useful thing in this section. On the morning of 31 August, two emails went out to that client with a block of raw code visible at the bottom of them. Our fault, a formatting fault in how they were sent, nothing to do with the client and nothing lost, because the readable message sat above the mess. We wrote and apologised at 08:24 and had it fixed the same morning. That is what a new tool in a client-facing workflow looks like in its first fortnight, and any agency telling you their rollout was clean is either lucky or editing.

What we're watching from here: whether project updates hold their quality when a build runs three months instead of two weeks, so that a week-five email still answers the week-two question. And whether the draft-first rule survives a busy period. That second one is the real test. The temptation to let it send will arrive on the day we're behind, and the answer needs to be no on that day too.

If you want the practitioner version of the mechanism rather than the agency version, the guide to AI email replies and the calendar scheduling guide cover the tools directly. And if you'd rather see what this looks like on the finished side of a build, the Lockerfella locksmith case study and the full interview with Sean Hamilton are the same story told from the client's chair.

Frequently asked questions