The AI employee pitch, and the five questions that deflate it

The pitch

You will receive this email. It is well written, because of course it is.

An AI employee that answers every enquiry, follows up every lead and never takes a holiday, for USD 299 a month instead of a salary. Often with a name and a face.

Some of these products are useful. Almost all of them are the components in this module (a model, a few tools, a prompt, a queue) assembled by somebody else, which is a legitimate thing to sell. What makes the pitch worth examining is not that it is fraudulent but that its pricing is anchored to a salary rather than to what it costs to run, and that the claim of autonomy is the part least likely to survive contact with your business.

Why the salary comparison is the wrong anchor

The right comparison is not “cheaper than a person”. It is “cheaper than the free tier plus two hours of setup”, which is what most of these products are competing with whether they say so or not.

From the costs lesson: three hundred enquiries a month costs pennies in model usage. A product charging USD 299 for that work is charging for the assembly, the interface and the support. That can be worth paying: you are buying not having to build it, and your time is the scarcest thing in a small business. But price it against the build, not against a salary, or you will conclude that anything under a wage is a bargain.

The five questions

Ask these before a trial, in writing, and treat a vague answer as an answer.

1. How many steps does a typical run take, and what happens when step four is wrong? This is the compounding question from earlier in the module. A vendor who has built something real can describe the failure path: what gets flagged, what halts, what a human sees. A vendor who cannot has not thought about it, which tells you what the bad days look like.

2. What can it do without a person, and can I turn each of those off separately? You are asking which rung it ships on. If sending is not separable from drafting, you cannot run it at rung three, and you will be at rung four on day one whatever the demo showed.

3. Where does my data go, who processes it, and is it used for training? Sub-processors, region, retention. Module nine goes into what you owe your customers here. For now: a vendor who cannot name their sub-processors has not been asked before.

4. How do I export everything, and what do I have afterwards? The answer you want is a file format you can open. Conversation histories, customer records, the configuration. If the answer is “you can request an export”, ask how long it takes and what it contains.

5. If it tells a customer something wrong, who is responsible? You already know the answer (you are, in every jurisdiction and under every terms of service) but how they answer tells you whether they will help you when it happens. Check the contract for the liability cap. It is usually one month’s fees, which is worth knowing before you put it in front of customers.

What to do in the trial

Not the demo tasks. Your ten hardest real cases, from module two’s testing lesson: the ambiguous ones, the awkward ones, the one where the customer is angry and slightly wrong, the one containing an instruction aimed at the assistant.

Then look at what it does when it does not know. A product that says “I will get someone to confirm that” on the out-of-range case is better built than one that answers everything smoothly, and the second kind demonstrates better.

The position

Buying is often right. A small business with no appetite for building should buy, and there are decent products in this space.

What you should not do is buy the autonomy. Buy the assembly, run it at rung three, keep your data exportable, and let the claim of an employee who never sleeps be what it is: a description of a loop that runs on a schedule, sold at a price anchored to a person who does not exist.