Selling chatbot work to local businesses: who to say no to

Advice about selling this work is mostly about getting a yes. That is the easy half. Local business owners buried in messages will say yes readily, and a meaningful share of those yeses turn into projects that consume three times the hours, never quite work, and end with somebody disappointed.

The projects that failed were nearly all identifiable in the first conversation. Getting better at this trade is mostly about learning which signals to take seriously and being willing to turn down work that is going to hurt.

What we'll cover

• The client who makes this fail
• Five questions that predict the outcome
• What they need to already have
• Leading with the problem they recognise
• Building it with CodeWords
• The demo, and what it should not do
• Where this genuinely does not fit
• The expectations to set before signing
• Saying no, and why it pays
• Making it survive
• Limits worth knowing about
• What to ask first
• Frequently asked questions

The client who makes this fail

They are enthusiastic in the meeting, which is part of the problem. The pattern has four features and you will usually see at least three together.

Nothing is written down. Prices are what the owner says on the day, hours vary, the service list lives in their head. A bot can only repeat information that exists, and this business does not have any.

Nobody is going to answer the escalations. They imagine the bot replaces the work rather than absorbing the repetitive part, so the messages it cannot handle sit unanswered, and within a month the thing is doing harm.

The owner is the only decision-maker and is never available. Getting the content approved takes six weeks, and by then the project has consumed its margin.

They want it to sound exactly like them. Sometimes reasonable. Often it means an indefinite loop of tone revisions with no criterion for done.

None of these is about budget, which is why price-based qualification misses them entirely.

Five questions that predict the outcome

Ask these in the first conversation and listen to the shape of the answer more than its content.

"When somebody messages and the bot cannot help, who answers?" A specific name is a good sign. Hesitation, or "well, it should handle most of it", is the single most reliable predictor of a project that goes wrong.

"Where are your prices and opening hours written down?" If the honest answer is nowhere, the first phase is writing them down, and that should be in the proposal and the price rather than discovered in week three.

"Show me the last twenty messages you received." More informative than any amount of discussion. You will see immediately whether the traffic is repetitive enough to automate, and roughly what proportion is.

"What happens to a message at the moment?" Whether anything exists to connect to. A business with a real booking system is a different project from one with a paper diary.

"What would make you consider this a failure?" Most owners have never been asked. The answer tells you what they actually care about, which is frequently not what they said they wanted.

What they need to already have

Three things, and their absence is a reason to phase the work rather than decline it.

Information that exists in a fixed form. Prices, services, hours, policies. Where it does not exist, creating it is genuine work with real value, and it is a separate engagement.

A number the business owns. Client work built on a partner's personal mobile is built on sand. If they are on a personal number, moving to a practice-owned number on the business platform is step one and not an afterthought.

Somebody who will look at it. A person who reads a sample of conversations weekly. Without that, it drifts out of date and nobody notices until a customer is quoted a price from last year.

Leading with the problem they recognise

The opening that works is a question about their week rather than a description of your technology.

What happens to messages that arrive after closing. How often somebody asks the same question. Whether they have lost a booking because nobody replied in time. Every owner who handles messages personally knows these answers precisely and with feeling.

Then be specific about what automation does and does not change. It answers the repetitive questions immediately and at any hour, it takes structured information from people, and it puts the rest in front of a person faster. It does not make judgements, handle unhappy customers, or replace the part of the job the owner is actually good at.

Owners who have been sold to before respond well to being told the limits. It is unusual enough to be credible.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder, using the client's twenty real messages rather than an imagined flow.
3. Authorize the connections to whatever the business already runs on, and to their own WhatsApp Business Platform account.
4. Describe the exceptions, and go through them with the client explicitly, since this conversation is where unrealistic expectations surface while they are still cheap.
5. Build a small demo from their real messages before quoting anything complex, which tells you more about the project than another meeting will.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

The demo, and what it should not do

A demo built from their own last twenty messages is persuasive in a way a generic one is not, and it takes very little time.

It should also show the failure. Send it something awkward and let them watch it escalate to a person. Owners assume these things either work or embarrass them publicly, and seeing a graceful handover answers a fear they have not articulated.

What a demo should not do is imply capabilities you have not built. A demo that handles a booking because you wired it by hand for the meeting creates an expectation you will spend the project paying for. Show what the thing does, say plainly what would need building, and let the gap be visible.

Where this genuinely does not fit

Turning these down is cheaper than delivering them.

Very low message volume. A business getting a handful of messages a week has no problem worth solving, and the honest advice is to say so.

Every enquiry is unique. Bespoke work quoted individually, complex consultative sales. There is no repetitive core to absorb.

Regulated advice at the first touch. Where the first question is one only a qualified person can answer, the automation is limited to routing, which is a much smaller project. Say so rather than discovering it later.

A customer base that does not message. Some trades genuinely still run on the phone, and their customers will not switch because their supplier bought software.

Businesses in real trouble. Automation will not fix a business losing customers for other reasons, and being the supplier who took money at that moment is not a position to be in.

The expectations to set before signing

It absorbs the repetitive part. Some proportion, not all, and you will not know the proportion until it runs.

It needs maintaining. Prices change, services change, and a bot repeating stale information is worse than none.

There will be a second version. The first meets real customers and needs rework. Say this at the start so it is a plan rather than a complaint.

Somebody has to read it. A weekly sample, by a person, indefinitely.

Account health is a live thing. Message the wrong people or ignore opt-outs and sending gets restricted. That is theirs to respect too.

Saying no, and why it pays

A declined project costs you one fee. A bad project costs the fee, the overrun, the reputational damage of something that does not work, and the referrals you would otherwise have had.

Decline it in a way that leaves the door open. Say what would need to be true, offer the smaller piece if there is one, and be specific. "Come back when your prices are written down and somebody can answer escalations" is useful advice that costs you nothing and is remembered.

The trades where this works well are the ones with high repetitive volume and information that already exists in a fixed form. Clinics, salons, garages, bakeries taking orders, practices chasing documents. Concentrating there beats taking everything.

Making it survive

Ask the five questions every time, including when you are busy and want the work.

Write down who answers escalations before anything is built.

Keep the twenty real messages and check the finished thing against them.

Record why you declined the ones you declined, and revisit after a year.

Be explicit about maintenance in the proposal rather than the invoice.

Limits worth knowing about

Enthusiasm in a meeting predicts nothing. The problems are structural and show up under questioning.

You cannot supply the missing information. A business without written prices has to write them.

Some trades are genuinely unsuitable, and pushing through produces a bad reference.

A demo can oversell and create an expectation the project pays for.

Platform rules bind the client too, so a client who wants bulk messaging to people who never opted in is a risk to take seriously rather than a sale.

What to ask first

"When somebody messages and the bot cannot help, who answers?" One question, asked early, and the hesitation in the answer predicts more about the project than anything else you will learn.

Two habits make the difference. Ask to see the last twenty real messages before quoting, because it shows you the shape of the work in a way no conversation does. And be willing to decline, since one bad project costs more than the two good ones you turned down to take it.

Frequently asked questions

How do I find clients for WhatsApp chatbot work?

Concentrate on trades with high repetitive message volume and information that already exists in a fixed form: clinics, salons, garages, bakeries taking orders, practices chasing documents. Breadth is less useful than depth in one of those.

What is the best qualifying question?

"When somebody messages and the bot cannot help, who answers?" A specific name predicts a project that works. Hesitation predicts one that does not.

What makes a project go wrong?

Information that exists nowhere, nobody to answer escalations, an unavailable sole decision-maker, and an open-ended demand that it sound exactly like the owner.

What should a client already have?

Prices, hours and services written down somewhere fixed; a number the business owns rather than a personal mobile; and somebody who will read a sample of conversations weekly.

How should I pitch it?

Ask what happens to messages after closing and how often the same question comes in. Then be specific about the limits, because owners who have been sold to before find that unusual enough to trust.

What should a demo show?

Their own real messages, and the failure path. Watching it hand over gracefully answers a fear most owners have and have not said out loud.

What should a demo avoid?

Implying capability you have not built. A booking flow wired by hand for the meeting becomes an expectation the project pays for.

Which businesses should I turn down?

Very low volume, businesses where every enquiry is genuinely unique, first-touch regulated advice, customer bases that do not message, and businesses already in serious trouble.

What expectations should be set before signing?

That it absorbs the repetitive part rather than all of it, that it needs maintaining, that a second version will be needed after real customers arrive, and that somebody has to read it weekly.

Is turning work down actually worth it?

A declined project costs one fee. A bad one costs the fee, the overrun, a reference that does not work, and the referrals you would have had.

Related reading

• Pricing when your costs are somebody else's volume
• Testing it before customers do
• Measuring what it is actually worth