AI Replies to Booking Inquiries

The reply to an enquiry is the first sample of your judgement a client ever gets. Before they have seen your boat, your water or your fish, they have read four sentences and decided whether you sound like somebody who knows what they are doing.

That is why this subject is not really about speed, although speed is the reason everybody reaches for it. It is about whether the thing that arrives is recognisably you, and about a line the law is now drawing between a machine that talks to your customer and one that helps you talk to them.

The line, in two statutes

Start with the definition, because it is narrower and more useful than the marketing word. Utah's artificial intelligence statute defines artificial intelligence as a machine-based system that makes predictions, recommendations, or decisions influencing real or virtual environments, and artificial intelligence technology as a computer system, application or other product that uses or incorporates one or more forms of it.

Predictions, recommendations, or decisions. A tool that drafts a reply and hands it to you has made a recommendation, to you. A tool that sends the reply has made a decision, about your customer. Those are different products even when they share a logo, and the difference is where the obligations attach.

Colorado's consumer protections act states the duty plainly: a person doing business in the state that deploys or makes available an artificial intelligence system intended to interact with consumers must ensure disclosure to each consumer who interacts with it that they are interacting with an artificial intelligence system.

Intended to interact with consumers. A drafting assistant that never touches the customer is not that. An automated responder that answers enquiries on its own is, squarely. The rest of the channel decisions sit at the getting-booked hub.

Down South, TX

What that means in practice

Two setups, two answers, and most guides could not say which one they are running.

If a tool writes a draft that you read, edit and send, the customer is interacting with you. Nothing in either statute is triggered, because there is no system interacting with the consumer, and the judgement in the message is yours because you signed off on it.

If a tool answers enquiries without you seeing them first, the customer is interacting with the system, and disclosure obligations attach in states that have legislated. That version also carries the risk that matters more commercially, which is that something confident and wrong went out under your name.

The safe arrangement is to keep the assistant on your side of the conversation. That is not a compliance dodge; it is the arrangement that produces better replies, because the part a client is buying is the part software cannot supply. The bot-facing version of this question, where the customer knowingly talks to software, is a different problem handled in the chatbot piece.

The defence built into the Colorado act

One provision is worth knowing because it tells you what good practice looks like without having to guess. The act provides an affirmative defence where a person is in compliance with a nationally or internationally recognised risk management framework for artificial intelligence systems that the act or the attorney general designates, and takes specified measures to discover and correct violations.

Read the shape of that rather than the detail. The legislature is saying that following a published framework and actively looking for your own mistakes is what reasonable use looks like. For a one-boat operation that scales down to something simple: write down how you use the tool, and check its output on a schedule rather than when something goes wrong.

The act also sets its main duties running from February 2026, which puts it in the category of things to keep an eye on rather than history.

The problem nobody warns you about

Automating replies usually means sending from something new, and something new sending on your behalf is where automated replies quietly stop arriving.

The federal standards body's guidance on trustworthy email sets out the mechanisms involved. It recommends technologies supporting the mail protocol and the domain name system that authenticate a sending domain, naming the sender policy framework, domain keys identified mail, and domain-based message authentication, reporting and conformance. It adds transport layer security for transmission and certificate-based protocols for content.

The document says its primary audience is enterprise administrators and security specialists, and then says it will also be useful for small or medium sized organisations, which in this trade means you.

The practical consequence is blunt. When a new tool starts sending as your domain without being authorised to, receiving systems treat those messages as unauthenticated, and unauthenticated mail is exactly what spam filtering exists to catch. A guide who automates replies and sees response rates fall has usually not written worse replies; they have started sending mail that nobody can verify came from them.

What the tool is actually good at

Structure and completeness, which is where most guide replies fail.

A guide answering an enquiry from a phone at a ramp writes three lines and forgets the price, the meeting point or the question they were asked. An assistant given your standard information produces something with all of it in, which the client can act on without a second exchange. That is the real gain, and it has nothing to do with the writing being good.

It is also good at the boring half of a reply. Confirming what is included, restating dates, listing what to bring. Those are facts, they do not vary, and a machine assembling them from your notes saves the part of the evening you were not going to spend anyway, and the same facts drive everything else you send.

And it is good at a first pass on a long enquiry, the sort that arrives with six questions in a paragraph, where the work is making sure none of them goes unanswered.

What it is bad at, and why that matters more

Judgement about the water. Anything about how the fishing will be, what the wind is going to do, or whether a particular week is worth travelling for is the thing being bought, and a plausible sentence about it is worse than silence because it is a promise nobody meant to make.

Saying no. A great many enquiries deserve a version of not that trip, not that month, or not with me, and machines are trained to be accommodating. A reply that agrees to something you cannot deliver is expensive, and the wording that declines well is collected in the difficult clients piece.

Sounding like a person. Generated replies converge on a register that is fluent, warm and completely anonymous, and clients notice. In a trade where somebody is choosing a person to spend a day with, sounding like everybody else is the specific failure to avoid.

And pricing anything unusual. A group, a multi-day trip, travel, or an odd start time is a negotiation, and the answer depends on things not written down anywhere the tool can read.

The reply that actually books trips

Worth writing down once, because it is short and almost nobody sends it.

Answer the question they asked, first, in the first line. Confirm whether the date works, plainly. Give the price without being asked. Say one specific thing about that water in that month that could only come from somebody who fishes it. Then ask one question back, because a reply that ends with a question gets answered and a reply that ends with a full stop often does not.

The specific detail is the whole difference. Anybody can send availability and a rate; a sentence saying the fish move onto the flats in the last hour of light in early June, and that is when the trip is built around, is the thing that gets a deposit. It is also the sentence a machine cannot write for you, which is a useful test of whether the reply is worth sending.

Speed matters too, and it is worth measuring rather than assuming, which is what the response time piece is for.

Using it without losing your voice

Give it your own material rather than a description of your business. Paste in three replies you actually sent and were happy with, and ask for the shape rather than the words.

Edit every draft, and edit the first line hardest, since that is the part that decides whether the rest is read. If you find yourself sending drafts unchanged, the tool has stopped assisting and started replying, and you have moved into the other column of the table above without deciding to.

Keep a short list of things it must never say, including anything about conditions and anything about price outside your standard rates, and check drafts against it rather than trusting the tool to remember.

And read your own replies back after a month. If they have converged on a register that is not yours, the tool has been training you rather than the reverse, which is the same drift described in the generated content piece.

Fly Fish Miami, FL

Getting the sending side right first

Before any of this is worth doing, the mail has to arrive, and that is a half-hour of setup rather than an ongoing burden.

Three mechanisms do the work, and the guidance names all three. The sender policy framework publishes, in your domain records, which servers are permitted to send as you. Domain keys identified mail signs each message so a receiving system can verify it was not altered and did come from your domain. The reporting and conformance layer sits on top, telling receivers what to do with mail that fails those checks and sending you reports about it.

None of that is optional once a third service starts sending on your behalf. The service will give you records to add; add them before the first automated reply goes out rather than after enquiries stop being answered.

Then send yourself a test from the new system and look at whether it lands in the inbox, the promotions tab, or nowhere. A guide who does that once has removed the most common and least visible failure in this whole subject, and the wider version of the problem is set out in the spam piece.

What to keep as your standard information

Whatever assembles your replies is only as good as the facts it is given, and most guides have never written those facts down in one place.

Six things, kept in one file: trip lengths with start times, what is included and what the client brings, your standard rates, the meeting point with parking, which months run for which species, and your weather position. That file is the source for the replies, the pages, the widget and whatever comes next, and updating it once a year is the whole maintenance burden.

Write it as sentences rather than bullet fragments, because sentences can be reused verbatim in a reply and fragments cannot. Include the awkward parts, since the enquiries that go wrong are usually the ones touching something you never wrote down, such as what happens with a late arrival or whether a non-fishing passenger can come.

Keep a second short file of the things you will not do. Trips you do not run, waters you do not cover, group sizes you cannot take, which is also the material that keeps group bookings from becoming a problem later. A reply that declines quickly and names somebody better is worth more to your reputation than an evening of polite hedging.

Measuring whether it helped

The question is not whether replies got faster, because they will have. It is whether more enquiries turned into trips.

Count two things for a season: how many enquiries you received and how many became bookings. If the ratio falls after automating, the replies are worse even though they are quicker, and the usual cause is that the specific detail went out of them.

Watch the second-exchange rate as well. A good reply ends the exchange with a booking or a clear no; a poor one produces three more messages clarifying what was already asked. Generated drafts tend to be complete and unspecific, which is exactly the combination that produces polite follow-up questions and no deposit.

And read a sample of your own sent replies each month with fresh eyes. If you cannot tell which ones you wrote, neither can anybody else, and that is the finding that matters most in a trade where people are choosing a person.

What experienced guides do differently

They keep a file of their own best replies and reuse the sentences, which produces something faster than any generated draft and unmistakably theirs.

They answer fast and short rather than slowly and completely. A two-line reply within the hour beats a polished one the next evening, and the second exchange can carry the detail, which is the same logic behind the short operational messages in the pre-trip messaging piece.

They separate the enquiry that is really a question from the one that is really a booking. The first wants an answer; the second wants a date held and a way to pay, and treating them the same loses both.

And they write the standard information down properly once, so that whatever assembles a reply, human or otherwise, is working from something accurate. That work also feeds the pages, as set out in the water and city pages piece.

Common mistakes

Letting it send. The moment nobody reads the message before the customer does, you have changed what the system is and taken on the obligations that go with it.

Automating without setting up sending-domain authentication first, which is how a guide arrives at faster replies that nobody receives.

Letting it answer questions about conditions, which is the one thing clients quote back at you in a complaint.

Sending drafts unedited, and using it for the enquiries that most needed a person, which tend to be the difficult, ambiguous or annoyed ones where the whole value is that somebody thought about it.

What surprises people

That the statutory definition is about predictions, recommendations and decisions rather than about how clever the software is, which makes the drafting-versus-sending distinction legally meaningful rather than a matter of taste.

That a state has attached a disclosure duty to any system intended to interact with consumers, not merely to high-risk ones.

That an affirmative defence exists for following a recognised framework and actively looking for your own errors, which is a legislature describing good practice rather than only prohibiting bad.

And that the commonest failure of automated replies is deliverability rather than content. The message was fine; the receiving system could not verify who sent it.

When not to use it at all

When you get few enquiries. Twenty a month is a personal conversation, and the time saved is not worth the register you lose.

When the enquiry is difficult. Complaints, refunds, ambiguous requests and anything involving somebody's safety are the exact cases where a considered human reply is the product.

When you have not written down your own standard information, because the tool will invent what it does not have, confidently.

And when you would not be comfortable telling the client afterwards how the reply was produced. That is a good general test, and it is close to what the disclosure rules are reaching for anyway. Where the enquiry arrives through a platform rather than your own inbox, the answer changes again, which is covered in the direct messages piece.