Summary: Any tool can send an instant auto-reply. Guaranteeing one, with money attached, forces you to answer questions most lead-response marketing never raises: what happens when the automation is down, what happens when the lead was never captured at all, and what happens when one outage breaches every customer you have at the same moment. Here is what I concluded before publishing the promise.
Why five and not fifteen
The instinct when writing a guarantee is to buy yourself room. Fifteen minutes sounds safer than five.
It is barely safer at all, and this is worth understanding before you soften your own promise. The failure mode is binary. The system is running or it is not. When it is running, replies go out in seconds, and the difference between a five-minute ceiling and a fifteen-minute one is meaningless. When it is down, it is usually down for longer than fifteen minutes anyway.
So widening the window gives away the only memorable thing about the claim and reduces your actual exposure by almost nothing. Pick the number that is true and defend it properly.
Reply on the channel they used
A response-time promise needs to say what a response is, or you will keep it in a way the customer experiences as strange.
Someone who typed an email address into a form expects an email. Texting them unprompted, using a number they gave you for a callback, reads as invasive rather than responsive. Someone who called and got voicemail expects a call or a text.
So the rule is the channel they used: missed call gets a text, form with a phone number gets a text, form without one gets an email. This also keeps the promise honest, because it removes the temptation to count “we sent something, somewhere” as a reply.
The exception is landlines, which cannot receive a text at all and which will otherwise produce a logged success and a silent customer. That failure mode is its own article, and it needs an explicit exception written into the guarantee rather than left implicit.
The failure I built the design around
My own website's contact form went down for about twenty-four hours. Every visitor who tried to send a message saw an error. The leads reached nobody.
The cause was mundane. The interesting part is the design lesson, and I got it the expensive way: the form had exactly one path. It posted to my automation and did nothing else. When the automation was down, the message was not late. It never existed.
That is the difference between a system that is slow and a system that loses your customers, and it is the single most important decision in this whole design:
- Automation up: reply in under five minutes.
- Automation down: the lead still lands in the owner's inbox natively. The reply is late. The customer is not lost.
Capture and speed must not share a single path. If they do, every outage is a lost customer rather than a late reply, and no guarantee is worth anything on top of that.
Missed calls are naturally durable, incidentally. The call is already in the phone's log, so a late text-back loses nothing. It is web forms that need the second path.
The risk nobody prices: everyone breaks at once
Here is the question that changed how I build this.
If ten clients run on one shared server and that server has a bad afternoon, how many guarantees did I just breach? All ten. Simultaneously. My worst day scales with my customer count, which is the opposite of how a business should work.
Run each client on their own isolated instance and one bad afternoon costs one client's monthly fee. The infrastructure runs a few dollars a month against a monthly fee many times that, which makes it a small percentage of revenue and the cheapest insurance in the entire product.
Correlated risk is the thing that kills service guarantees, and it is almost never visible in the pricing conversation, because on a good day shared infrastructure looks identical and costs less.
I also put each client's instance in their own account rather than mine. Their leads are their data, the cost passes through at cost, and if they leave they keep a working system. What they were paying for was me running it, not the server.
Monitoring is most of what the fee buys
My form was broken for twenty-four hours and I found out by accident.
That is the actual product. Not the automation, which is a commodity and always has been. The thing worth paying for is that when it breaks, somebody knows within minutes rather than whenever a customer happens to complain.
A watchdog that checks every few minutes turns a silent twenty-four hour outage into a fifteen-minute one. That is a boring script and it is worth more than any individual feature in the system.
Two details from building mine. Make the routine check a read rather than a write, or your monitoring will pollute the data it is monitoring. And check the thing the customer actually touches, end to end, not just whether the server is responding, because a server that is up and a form that works are different claims.
What to exclude, and why excluding it is honest
My guarantee excludes outages at the client's phone provider, their internet, and the carrier network.
That is not weaseling, it is accuracy. I cannot make a text arrive when a mobile carrier is having an incident, and a promise that pretends otherwise is a promise I will break and then argue about. The exclusions are short, specific and named. A guarantee with a paragraph of exclusions is a marketing device; a guarantee with three named ones is a commitment.
The uncomfortable question to ask any vendor
If you are buying lead response rather than building it, the useful question is not “how fast do you reply?” Everyone says instantly and everyone is telling the truth on a good day.
Ask these instead:
- If your system is down, does my lead still reach me somehow?
- How would I find out you were down, and how long would that take?
- Am I on shared infrastructure with your other customers?
- What do you do when the number is a landline?
You are not really testing the technology with these. You are testing whether anyone has thought about the day it does not work, because that is the day the promise either means something or does not.