A chat link beats a contact form for buyers on a phone

A buyer with a container of sugar to move is not sitting at a desk. That buyer is standing in a yard or a warehouse, on a phone, with one hand free, and is messaging four suppliers this morning to see which one answers first. Your website is one of those four, and it has about ten seconds. We built a site for exactly that reader, a London import and export company selling agricultural produce, food commodities and recycled materials to wholesalers and manufacturers, mostly outside the UK. It has no contact form on any of its eight pages, and that was the decision we spent the most time on.

The form is a queue nobody agreed to join

A contact form looks free. It is not. Count what it asks of the person filling it in: name, email address, company, a message written from scratch, a captcha if you have been getting spam, a submit, and then a wait of unknown length for a reply that will arrive somewhere they may not be reading on that phone.

Now count what it asks of you. A form service or an API route. Spam filtering. Somewhere to store submissions. A person whose job includes checking that somewhere. A retention policy and a lawful basis for the personal data you just collected, because a name and an email address in a database is processing whether or not you thought of it that way.

Then count the failure modes, which is where forms really cost money. The notification address belongs to somebody who left in March. The alerts have been going to a spam folder for three weeks. The form service changed its API and nobody redeployed. Every one of those is silent. A broken form does not tell you it is broken. It just stops producing enquiries, and everyone concludes that the market is quiet.

Meeting the buyer where they already are

For this business, buyers run their working day on a messaging app. Not email, and certainly not a web form. So the enquiry route is a floating button present on every page that opens a chat, and there is nothing else.

Three things change. The reply lands on the device and in the app the buyer checks every few minutes. The conversation keeps its history, so a follow-up next quarter arrives in the same thread instead of as a cold email. And there is no delivery machinery in between to break: nothing queued, filtered or forwarded.

The detail that makes it worth doing properly is prefilling the first message. The button carries the page the visitor is reading, so the conversation opens with context rather than the words "I am interested in your products".

// One component, rendered on every page.
const NUMBER = '447700900123';        // international format, no plus, no spaces
const label  = 'Enquiry about ' + pageTitle + ' (' + pageUrl + ')';
const href   = `https://wa.me/${NUMBER}?text=${encodeURIComponent(label)}`;

Two things bite people here. The number must be in international format with no plus sign and no punctuation, or the link silently opens a chat with nobody. And the message must be URL encoded, otherwise it truncates at the first ampersand, which you find out about when a buyer sends you half a sentence.

One more, specific to a statically exported site: pass the page title and path in as props at build time rather than reading them from the browser. The button then renders correctly in the HTML instead of waiting for hydration, which matters on the connection our reader is actually using.

Where a form is still the right answer

This is not a general argument against forms. Four cases where the form wins.

You need a record that outlives a handset. Chats live on a phone, often a personal one. If that person leaves, the enquiry history walks out with them. If every enquiry has to become a row in a CRM, a form writing to a database is the honest way to get one.

You need structure before you can reply. If quoting requires a delivery port, a quantity, an incoterm and a target date, asking for four fields is faster than a chat that takes four rounds to extract them.

You need auditability. Marketing consent, retention periods and subject access requests are straightforward against rows in a table and awkward against a messaging app on somebody else's device.

You would rather not publish a mobile number. Numbers attract the same automated nuisance that email addresses do, and you cannot rotate one as easily.

There is also reach. Not everyone has the app, some corporate networks block it, and in several markets people use a different one entirely. For an accountancy practice we work with, the answer was both: a validated form with a honeypot field for people who want to write something considered, and chat buttons on the pricing cards that name the chosen package in the first line, so the practice knows which tier prompted the enquiry before anyone has typed a word.

The test is not which channel is better in the abstract. It is which one your buyer already has open.

What is left to run

Once the form is gone, look at what the site still needs from a server. On that trading site, nothing. Eight pages. A ten item product catalogue across three categories, each item with its sourcing origins. Two service pages for ship dismantling and material recovery. A gallery with nine category filters that runs in the browser over a fixed set of images. A cookie banner that stores the answer in local storage, because there is no database to store it in. Structured data and a sitemap generated at build time from the route list, so neither can drift away from the pages that actually exist.

So it ships as a static export: a folder of files, no API routes, no database, no third party form service, and no analytics script loading in front of the content.

The argument for that is not speed, although it is fast. It is that there is nothing to maintain. A brochure site with a content system behind it acquires a login, a dependency tree, a monthly patching obligation and a renewal date, in exchange for edits that happen twice a year. Two years on, the versions are old, nobody wants to be the one to upgrade, and a two word copy change costs a day of work first.

What the static version costs

Content changes need a developer and a rebuild. That is a genuine cost and it is the reason to refuse this shape as often as to choose it.

The test we use is boring arithmetic. How many people need to change content, how often, and can they wait a day. Two people, a few times a year, yes: build it static and spend the saved money on something the business can feel. Five people, weekly, no: they need an editor, and running one is simply the price of that. There is no principled answer, only an honest count.

The second cost is measurement. With no analytics and no form you can see how many conversations started, and nothing at all about how many people looked and left. For a business whose enquiries arrive by reputation and trade shows, that was acceptable. For one spending money on advertising it would not be, and we would have built it differently.

Most brochure sites are running a stack to serve a form that could be a link. Work out which channel your buyer already has open, build for that one properly, and then delete everything the site no longer needs.

The site described here is Linked Corporate International.