Client emails from our CRM: one click to send, the warnings come later

Writing to clients is one of the things we do most often, and one of the easiest places to lose time. So when we built the email composer into our CRM, we asked two things of it: suggest a draft written with AI, and check the quality of the text before it goes out. The first request was plain sailing. The second forced a design decision worth explaining, because it goes against the instincts of anyone who builds tools: quality checks never stop a message being sent.

What the composer does

When someone on the team needs to write to a client, the CRM suggests a draft. It isn't the same draft for everyone: the system learns each team member's style. People who write tersely get terse suggestions; those who tend to be chattier find them more relaxed. The aim is for the email, once sent, to sound like the person who signs it rather than a form letter.

The second thing the composer can do is remember. For each client and each property, it keeps track of what has already been sent. It sounds like a minor detail, but it's what prevents the email that repeats information already shared, or presents as news something the client has known about for ages. Anyone who receives a repetitive email realises straight away that nobody on the other end remembers them. With a memory for each property, the draft picks up where we left off.

Then there's the quality check: the composer rereads the text and flags anything it thinks could be improved.

The decision: the click wins

The real question was this: what happens when the check finds something it doesn't like? The obvious answer, the one that springs to mind for anyone who writes software, is to stop everything until the problem is fixed. A greyed-out button, a red message, "correct this before sending".

Our manager decided the opposite. You send with one click, always. The warnings come afterwards, and they come as suggestions, not orders. Whoever wrote the email reads them and bears them in mind for next time, or ignores them if they think they're right.

At first the choice might look like a step backwards. We have a tool that can spot text that could be better, and we let it go out anyway? Yes, and the reason is more interesting than the choice itself.

Why a style block does harm

A system that blocks on grounds of style teaches people to get round it. That's how it works with any tool: if the check gets in your way when you're in a hurry and sure of what you're writing, you quickly learn how to shut it up. You rephrase the sentence so it passes, remove the word that triggers it, open another program and send the email from there. The result is worse than before: the text hasn't improved, and on top of that you've learnt that the system is an obstacle to be climbed over.

There's also a less visible effect, and in our view a more serious one. If everything blocks, nothing really blocks. Once people get used to seeing the red message over a comma or an overlong sentence, they stop distinguishing between a warning that matters and one that doesn't. The real blocks lose their value, because they're met with the same impatience as the pointless ones.

A style check, however well made, is still an opinion. It may be right much of the time, but it lacks the context of someone who knows the client. And an opinion should never have the power to stop the work.

The only block that remains

Of all the possible blocks, only one is left: withdrawn consent. We don't write to people who have asked not to be contacted any more. Here the composer doesn't suggest and doesn't warn afterwards: it simply won't let the email go.

The difference from the quality checks is clear-cut. Style is a matter of judgement, and judgement belongs to the person writing. Respecting a client's explicit request is not a matter of judgement. There's no good reason to write to someone who has asked to stop receiving our emails, and no deadline that could justify it.

Precisely because it's the only one, this block carries a weight it wouldn't have among ten others. When the composer stops, the person writing knows it isn't the tool being awkward. There's nothing to get round, and nobody is tempted to try.

Warnings after, not before

Moving the warnings to after the email is sent also changes how they're read. Before sending, a warning is a hindrance: you read it anxious to get it out of the way. Afterwards, with the email gone, it's a comment on something you've done, and you read it more calmly. It's the difference between a colleague who snatches the page out of your hand and one who, once it's done, says "next time I'd try it this way".

In short, the composer plays the colleague who proofreads, not the gatekeeper who decides. The drafts help you get started, the memory avoids repetition, the warnings help you improve over time. None of these three things stands between the person and the send button.

What we're taking away

The lesson goes beyond email, and we now apply it to every tool we build:

• Separate rules from advice. A rule is something you never do, for any reason. Advice is something that's usually worth doing. Mixing them in the same mechanism spoils both.
• Keep blocks to a bare minimum. Every extra block weakens the ones that matter. If only one is left, everyone takes it seriously.
• Don't make the user pay for the tool's uncertainty. If the system isn't sure it's right, it shouldn't behave as though it were.
• Trust the person writing. The people on the team know the clients better than any automated check. The tool should make them quicker and more careful, not replace their judgement.

If you're building something similar, the temptation to put a blocking check on everything will be strong, because it looks like the cautious option. In our experience it's the opposite: real caution lies in carefully deciding the few things that must never be done, and leaving everything else free.