Why Thin Fishing Lodge Websites Lose Premium Bookings

 

 A premium fishing lodge week can reach five figures once flights, gratuities, and gear are added. Buyers research that trip for months, compare several lodges side by side, and ask pointed questions before a deposit moves. Then many of them land on a destination page with a hero photo, two paragraphs about "world-class fishing in a pristine setting," and a contact form.

That page costs the lodge money. A thin fishing lodge website loses booking demand in three places at once: Google's rankings, AI-generated answers, and the buyer's final comparison. A page that could describe any lodge gives nobody a reason to choose this one.

This is the visibility problem I covered in how SEO, AEO, and GEO work as one connected system, applied to one of the highest-consideration purchases in outdoor travel.

What is a thin destination page for a fishing lodge?

A thin destination page names a place and a species but tells a serious angler nothing they could not guess. It describes the lodge in adjectives instead of facts. The test is simple: swap in a competitor's name and see whether a single sentence stops being true.

The warning signs are consistent:

• Generic copy that fits any river, flat, or offshore grounds
• No seasonality beyond "the season runs June through September"
• No named guides, dated catch reports, or recent results
• Pricing, inclusions, and deposit terms hidden behind "contact us"
• Near-identical pages for each river or species
• The same description pasted onto every booking agency listing

Why do booking agencies sometimes outrank a lodge for its own name?

When the same lodge description appears on the lodge's site and on several agency listings, Google generally shows one version of duplicate content, and it is not always the lodge's. The agency page usually carries more authority, so it can win searches for the lodge's own name. Writing unique copy for your own site, and giving agents a shorter summary, protects the page that takes direct bookings.

Why does a premium lodge booking take so long to win?

Premium lodge bookings take long to win because modern travel research loops rather than runs in a straight line. A 2026 report from McKinsey and Skift Research, based on a survey of more than 1,000 U.S. travelers and a diary study of 211 real planning sessions, found that travelers pass through roughly 65 touchpoints before booking, up from 45 in 2018. More than 70 percent revisit the same sites before deciding, and comparing options now ranks as the most frustrating part of planning.

The same research shows where decisions actually get made. Sixty percent of travelers named social media as a top-three source of trip ideas, while only 26 percent turned to OTAs or supplier sites at that stage. And while 71 percent are comfortable letting AI generate ideas, only 16 percent have used an AI tool to book anything travel related. AI and social media shape the shortlist. The lodge's own site still has to close the sale.

The research covers travelers broadly, not anglers, but the pattern fits a lodge purchase with a narrow window. Lodges tell buyers this directly: No See Um Lodge recommends booking 6 to 12 months out for peak weeks. A buyer who cannot get answers during that research phase moves on.

Booking agents fill that gap. One agency, Yellow Dog Flyfishing, argues that anglers planning alone are left "blind googling" without first-hand guidance. Yellow Dog has a stake in that argument, since it wants the booking. That is the point. Every question a lodge page leaves unanswered sends the buyer to someone else who will answer it.

How does thin content hurt a lodge's Google rankings?

Thin content hurts rankings because it fails the tests Google publishes. Its helpful content guidance asks whether a page offers original information, a complete description of the topic, analysis beyond the obvious, and signs of first-hand experience. "Unforgettable adventures" meets none of those.

Templated location pages add risk. Google's spam policies describe doorway abuse as pages created to rank for specific, similar queries, including pages targeted at particular regions or cities. A set of "Fishing the [River Name]" pages with swapped nouns sits close to that pattern.

There is an opening for operators. In early 2025, Brendan Nugent, CEO of the adventure marketplace Adrenaline, told PhocusWire that navigational referrals had fallen 67 percent year over year, and he attributed the drop to Google favoring official operator sites with Google Business Profile listings. That is one marketplace's analysis, not a study, but Google appears willing to send buyers straight to the operator. The lodge only benefits if its page deserves the visit.

What should a lodge do with its Google Business Profile?

Treat it as a second homepage. Choose the most accurate primary category, upload current photos of boats, water, rooms, and guides, answer common questions in the profile, and respond to every review. Keep the name, address, phone, and website identical to what appears on your site and agency listings.

 

Why do AI assistants cite reviews instead of lodge pages?

AI assistants cite reviews because that is where the specific, first-hand travel information usually lives. Similarweb's 2026 Generative AI Landscape report, covered by Search Engine Journal, found that ChatGPT included citations in 22.6 percent of travel answers in May 2026, more than any of the nine topics Similarweb tracked and well above the 6.8 percent average. Within travel, reviews and user-generated content made up 54.1 percent of citations.

Those figures cover U.S. desktop use in a single month, Similarweb calls its data estimates, and the company sells AI visibility tracking. Still, the likely result for a thin lodge site is clear. When an angler asks which Alaska lodge fishes best for king salmon in late June, a lodge page with no seasonal detail gives the model nothing to cite, so it cites a review site, forum, or agency instead.

Tour marketing agency BeaconPoint describes this as compression: AI condenses generic information into interchangeable summaries but struggles to compress first-hand, uniquely sourced content. To see whether AI tools send your lodge any traffic, start with how to measure AI search traffic, since much of it hides in the Direct channel.

Where do thin pages lose the deposit?

Thin pages lose the deposit at the comparison stage, where premium buyers make their final decision. The McKinsey and Skift report's first key takeaway is that proof beats volume: evidence from people like the traveler, such as reviews and peer recommendations, moves decisions more than polished brand material.

The report also found that half of travelers have changed a confirmed accommodation after seeing a better option online. Most accommodation bookings are refundable, and lodges with non-refundable deposits are less exposed. But a buyer who regrets the choice is less likely to rebook or refer friends, and a lodge losing that repeat business rarely sees why.

B2B buying works the same way, where buyers shortlist vendors before they ever talk to sales. By the time an angler calls, the ranking in their head already exists.

What should a premium fishing lodge page include?

A strong lodge page answers the questions experienced anglers ask before booking, in detail only that operation could provide:

• Species and conditions by week or month
• A day-by-day itinerary: boats, anglers per boat, guide ratios, meals, pacing
• Named guides with years on that water
• Group size, catch-and-release policy, licenses, and safety
• Pricing, inclusions, deposits, cancellation terms, travel insurance, and booking lead time
• Travel logistics, including fly-out or floatplane transfers and options for non-anglers

Build pages around the season, not the brochure

Seasonality is the most useful thing a lodge can publish and the thing thin pages skip most. Tikchik Narrows Lodge lays out species and fishing by period through its season, and Panama Sportfishing Lodge explains its seasonal windows for marlin, inshore species, and weather. Publish seasonality as an HTML table rather than only an image, because search engines and AI models can read a table:

Sample fishing lodge seasonal calendar

Period	Primary species	Water conditions	What to expect
Early season	[species]	[flows, clarity, temperature]	[typical results]
Peak weeks	[species]	[conditions]	[typical results]
Late season	[species]	[conditions]	[typical results]

Put names, numbers, and dates on the proof

Guest stories, guide profiles, and dated catch reports do what adjectives cannot, and they are the first-hand evidence Google's guidance asks for. Add a "last updated" date to seasonal pages and archive reports by year. Undated reports look abandoned. A lodge that publishes what happened last week is usually more credible than one promising what might happen next year.

Which schema markup should a lodge use?

Structured data tells search engines and AI systems what the page describes. Mark up the lodge as a LodgingBusiness, packages as a TouristTrip with an Offer showing price, and reviews with Review markup. FAQPage markup still helps machines parse answers, though Google now shows FAQ rich results mainly for authoritative government and health sites, so do not expect a visual result.

 

Does more content guarantee more lodge bookings?

No. No study I could find directly measures bookings lost to thin lodge pages. The case rests on Google's published policies, broad travel-buyer research, and marketplace and agency observations, not a controlled experiment on fishing lodges.

Depth also works best alongside the rest of a lodge's footprint: an accurate Google Business Profile, steady reviews, and mentions on the forums, podcasts, and agency sites where anglers already look. A detailed page without those signals is a better page, not a guaranteed booking engine.

Frequently asked questions

Why is my fishing lodge website not getting bookings?

Usually because it does not answer the questions buyers ask before committing. If seasonality, pricing, guide ratios, and recent results are missing, anglers get those answers from a competitor, an agent, or a review site, and the booking follows the answers.

What is thin content on a lodge website?

Thin content is copy that could describe any lodge. It relies on adjectives, skips seasonality and pricing, and often repeats one template across river or species pages, a pattern close to what Google's spam policies call doorway abuse.

How do fishing lodges get cited by ChatGPT and AI Overviews?

Publish specific, first-hand information that AI models cannot find elsewhere, such as seasonal tables, named guides, and dated catch reports. Then make sure the lodge appears consistently on the review sites and forums AI models already cite for travel.

Should a lodge publish its prices online?

In most cases, yes. Premium buyers compare lodges side by side, and a missing price adds a step many will skip. Publishing rates, inclusions, and deposit terms lets serious buyers qualify themselves before they call.

The lodge page is the first conversation

Premium anglers no longer start the booking on the phone. They start on your website, in a Google result, or inside an AI answer, and they come back to compare before they commit. Each visit is a conversation the lodge either wins or hands to someone else.

A specific page, built on seasonality, named guides, real numbers, and clear terms, gives search engines something to rank, AI models something to cite, and buyers a reason to stop comparing. The fishing is what the guest pays for. The page is what convinces them to pay you.

Want to know how your lodge site stacks up? Digital Upwelling audits lodge and outfitter websites for search and AI visibility.

Copyright © 2026, Full Throttle Media, Inc. FTM #fullthrottlemedia #inthespread #sethhorne

Agentic TMS Has an Identity Problem

 

I spent part of my career selling supply chain software, and I now write about identity security. For most of those years, those were two separate conversations. In 2026 they are the same one, and transportation management is where they collide.

Two trends are converging. Transportation management systems are going agentic, handing AI agents the authority to negotiate rates, book carriers, and clear exceptions on their own. At the same time, freight fraud has quietly become an identity crime, with criminals hijacking carrier identities and compromised accounts to steal loads on paper before anyone touches a truck. Put those together and the conclusion is uncomfortable. Agentic TMS is an identity problem before it is a logistics one, and the industry is automating the exact attack surface criminals are already working.

What is agentic TMS, and why does it change the risk picture?

An agentic TMS is a transportation platform where AI agents make and act on operational decisions rather than waiting for a human to configure a rule or approve a recommendation. Earlier systems optimized routes and flagged exceptions for a person to handle. The new generation books the carrier, negotiates the rate, schedules the appointment, and resolves the exception on its own.

Gartner's 2026 Magic Quadrant for Transportation Management Systems names this shift directly, pointing to the rapid adoption of AI agents to automate tasks such as appointment scheduling, exception handling, and freight procurement. Vendors are shipping these capabilities into platforms that already sit at the center of an API-first ecosystem, wired to the ERP, the warehouse system, EDI networks, telematics providers, carrier systems, and external AI services.

That connectivity is the entire point of a modern TMS, and it is also what changes the risk picture. Every one of those connections is a door, and an autonomous agent now holds the keys to walk through them without asking.

Why is agentic TMS an identity problem?

Because every agent acting inside that system is an identity, and most of them are barely governed.

An AI agent that books freight authenticates as something to reach the load board, the carrier API, the rate engine, and the payment step. It holds credentials, and the more it does, the more access it accumulates across the partner ecosystem. These are non-human identities, and they now carry the authority to move freight and money. I wrote about this category in Non-Human Identities and AI Agents: The New Blind Spot in Your IAM Program, and transportation is where the blind spot stops being theoretical.

The uncomfortable part is that logistics already runs on trust it does not verify. When an agent hands a load to a carrier, the decision rests on whether that carrier is who it claims to be. In freight, that claim is exactly what criminals have learned to forge.

How do attackers already exploit identity in freight?

Constantly, and through identity rather than force. The fastest-growing category of cargo theft is strategic theft, where criminals take legitimate control of a shipment on paper and then disappear with it. It now accounts for close to a third of reported cargo theft in some datasets, up from a small share a few years ago.

The mechanics are pure identity attack:

• Carrier identity theft, where criminals hijack a real company's motor carrier number, insurance certificates, and email domain, so the paperwork checks out because it belongs to someone else.
• Double brokering, where a load is re-handed to an unauthorized carrier without the shipper's knowledge, a scheme that accounts for an estimated $500 million to $700 million in freight loss each year.
• Compromised accounts, where actors reach into broker and carrier systems through spoofed emails and fake links, then post fraudulent listings to hijack and reroute freight.

That last pattern is not my characterization. In April 2026 the FBI warned publicly that cyber threat actors are increasingly impersonating legitimate businesses to hijack freight and reroute deliveries, gaining access through spoofed emails, fake URLs, and compromised carrier accounts. The operational data reaches the same conclusion. Highway's Q4 2025 freight fraud index reported that across every fraud vector, the same weakness surfaces: identity and authorization get taken on trust instead of checked. In a single year the company blocked nearly two million fraudulent email attempts, more than double the year before.

Sit with that finding, because it is the whole argument. Identity is taken on trust rather than verified. That was already the industry's core vulnerability while humans were doing the booking.

What happens when you add autonomous agents to that?

You scale it. An agent that books at machine speed does not pause to notice that a carrier reactivated after months dormant, or that a contact email sits on a free domain, or that a rate runs suspiciously below market. Those are the human instincts that catch strategic theft, and autonomy removes the human.

Then add the second exposure. The agents themselves are targets. An agent identity with authority to onboard a carrier, release a load, or approve a payment is a credential worth stealing, and a compromised or impersonated agent can move real freight and real money before anyone notices. Enterprises are learning this same lesson in software development, where autonomous agents that hold credentials become an execution path into the business. I covered that dynamic in AI Is Writing Your Code and Leaking Your Secrets, and the principle carries straight into freight. An ungoverned agent identity is a liability whether it is writing code or booking a truck.

The trouble is that adoption is outrunning governance. Vendors are shipping agentic features into platforms faster than most operations are building the identity controls to contain them.

To be clear, this is a risk arriving rather than one already cataloged. I am not aware of a public case of an autonomous freight agent being hijacked to date. But the fraud playbook already targets the exact trust these agents automate, and identity controls take time to stand up, which is the argument for building them ahead of the incident instead of after it.

How do you secure an agentic TMS?

You secure it by governing the agent identities with the same rigor you would give any party that can move your freight or your money. The controls are not exotic. They are the identity discipline logistics has under-applied for years, now made mandatory by autonomy.

• Give every agent its own scoped identity. Name it, and grant least-privilege access to only the systems and actions its job requires, so a compromised agent cannot reach the whole ecosystem.
• Keep credentials short-lived. Replace standing keys with credentials that expire quickly, so a stolen one is worth little.
• Put a human in the loop for high-consequence actions. Carrier onboarding, load release, and payment approval are exactly where identity fraud pays off, so an agent should propose these and a person should confirm them.
• Verify carriers actively, not on documents alone. Feed the agent real verification, cross-checked authority, direct insurance confirmation, and known-partner networks, because paperwork is the thing criminals forge.
• Monitor and inventory every non-human identity. Each agent needs an owner, a logged trail of what it did, and a decommission date, so nothing acts unwatched.

None of this asks you to slow the platform down. It asks you to make sure the speed belongs to you, and not to whoever learns to impersonate your agents.

These controls are not new inventions either. They map to an existing category of non-human and workload identity management, supported by secrets managers that issue and expire credentials, and active carrier verification is already a product in the market, sold by Highway among others. Policy is moving in the same direction, with the Federal Motor Carrier Safety Administration and the Transportation Intermediaries Association both pushing on carrier identity verification and double brokering. The tooling and the rules are catching up. The open question is whether your agent governance keeps pace with your agent adoption.

I write about where identity security meets commercial reality, because in transportation they are now the same problem. If your operation is adopting agentic logistics and working through what it means for security, connect with me on LinkedIn.

Frequently asked questions

What is an agentic TMS?

An agentic transportation management system is one where AI agents make and act on operational decisions on their own, such as negotiating rates, booking carriers, scheduling appointments, and resolving exceptions, rather than only recommending actions for a human to approve. The agents operate across the platform's connections to carriers, load boards, ERP, and payment systems.

Is agentic TMS safe to use?

It can be, but only with identity governance in place. The agents hold credentials and the authority to move freight and money, and freight fraud is already an identity crime. Safe adoption depends on scoping each agent's access, verifying carriers actively, and keeping a human in the loop for high-consequence actions like onboarding and payment.

What is carrier identity theft?

Carrier identity theft is when criminals hijack a legitimate carrier's motor carrier number, insurance certificates, and email domain to impersonate them. The stolen identity lets them win and pick up loads that check out on paper, then divert the freight. It is a leading method behind the rise in strategic cargo theft.

How do you keep AI freight agents from being hijacked?

Treat each agent as a governed non-human identity. Give it a scoped, least-privilege identity, issue short-lived credentials, require human confirmation for onboarding, load release, and payment, and monitor every agent's activity with a clear owner and audit trail. The point is to make a stolen or spoofed agent identity useless.

Governance is what lets logistics run agents

Agentic TMS is a real advance, and the operations adopting it will move faster than the ones that do not. The mistake would be to treat the autonomy as free. It arrives inside an industry where fraud already works by forging identity, and where verification too often stops at documents, and it hands that environment agents with the authority to act.

The answer is not to hold back the technology. It is to govern the identities that make it work. Scope the agents, verify the carriers, keep a person on the decisions that move money, and watch every non-human identity in the system. Do that, and agentic TMS protects your freight, your margins, and your speed at once. Skip it, and you have simply handed the criminals a faster way in.

---

Navneet Lounsberry writes on cybersecurity and commercial strategy, drawing on more than two decades in enterprise technology sales and business development across IBM, SAP, Manhattan Associates, and UKG.

 

 

Copyright © 2026, Full Throttle Media, Inc. FTM #fullthrottlemedia #inthespread #sethhorne

How Enterprises Actually Buy Cybersecurity

 

I have spent twenty years selling enterprise technology, and I have watched the better solution lose more times than I can count. Not to a stronger competitor. To a buying process the vendor never understood.

Worldwide end-user spending on information security is projected to top $240 billion in 2026, by Gartner's latest forecast. That is an enormous market, and most companies competing in it believe they lose deals on features, price, or timing. They are usually wrong. You rarely lose a security deal on the merits alone. You lose it in the gap between how security teams sell and how enterprises actually buy.

Closing that gap is not a technical skill. It is a commercial one, and it can be learned.

How do enterprises actually buy cybersecurity?

Enterprises buy cybersecurity by committee, slowly, and mostly without you in the room. Gartner's 2025 buyer research puts modern B2B buying groups at anywhere from five to 16 people across as many as four functions. In enterprise security, that group often includes a CISO, a security architect, a compliance lead, a procurement officer, a budget owner, and legal, each carrying a different definition of what good looks like. The exact mix shifts with the category and the trigger. An incident, an audit finding, a renewal, a merger, or a board mandate can reshape both who sits on the committee and how fast it moves.

Here is the part sellers underestimate. Gartner's research shows buyers spend only about 17 percent of the purchase journey meeting with potential suppliers, and an even thinner sliver of that with any single vendor when they are comparing several. You are not the main character in this decision. You are a supporting reference the committee consults briefly and then debates without you.

By the time sales enters, the buyer's preference is often already taking shape. 6sense found that the vendor a buying group ranks first at the end of the selection phase goes on to win about 80 percent of the time. That is a broad B2B pattern rather than a security-specific law, but it holds. The real work of selling happens before the first call, in the reputation, the content, and the peer conversations that shaped that ranking.

Now the core mismatch. Security teams and vendors sell the way engineers think, in features, threats, and technical superiority. Enterprises buy the way executives decide, in risk reduction, business enablement, and political cover for the person whose name goes on the decision. Those are different languages. The vendor who speaks only the first one loses to the vendor who speaks both.

Technical validation still matters, and in security it matters a great deal. The product has to clear the architecture review, the integration test, and the security questionnaire. But clearing those gates does not create a budget, a consensus, or a decision the committee feels safe defending. Technical merit gets you considered. It rarely closes the deal on its own.

Why do good security teams and vendors lose winnable deals?

Because their toughest competitor is not another vendor. It is the buyer deciding to do nothing.

The research is blunt about how often that happens. Analyzing more than 2.5 million recorded sales conversations, the team behind the JOLT Effect found that 40 to 60 percent of deals end in no decision, even after the buyer signals a clear intent to purchase. The reason is not laziness or a simple preference for the status quo. In that research, 56 percent of no-decision outcomes traced to fear of making the wrong choice.

That fear has a structural cause. Gartner found that 74 percent of buying teams experience unhealthy conflict during the decision, and that more than three quarters of buyers describe their last purchase as very complex or difficult. A committee that cannot resolve its own disagreement does not pick you or a competitor. It postpones, and the deal quietly dies.

Good security vendors lose winnable deals for a short list of repeatable reasons:

• They sell to the technical champion and never reach the economic buyer who controls the budget.
• They present capabilities instead of quantifying the cost of doing nothing.
• They cannot answer "why now," so the purchase slides to next quarter and then off the table.
• They give the buyer no political cover, no defensible business case or reference story that makes the decision safe to explain to the board, the CFO, or the next audit.
• They treat a rival vendor as the threat, while indecision walks off with the deal.

None of these are product failures. Every one is a translation failure.

What actually closes an enterprise security deal?

You close it by selling the way the enterprise buys. No five moves guarantee a signature, but these do most of the work.

First, translate the risk into a budget consequence the economic buyer owns. A control gap is abstract. A quantified exposure tied to a number on their budget is a decision they can defend. I wrote about this exact failure in Why Identity Risk Loses the Budget Conversation, and it is the most common place a strong security case falls apart.

Second, multi-thread past the champion. If five to 16 people decide and you know one of them, you are not running the deal, you are hoping. Map the group, learn what each person needs in order to say yes, and give them each a reason.

Third, arm your champion for the room you are not in. The committee debates you without you present, and most of those rooms hold real conflict. Your champion is selling on your behalf whether you helped them or not. Hand them the business case, the answers to the hard questions, and the one-page argument they can carry upstairs.

Fourth, build a real reason to act now, and make sure it is real. Regulatory deadlines are the cleanest source of urgency, but only when the buyer understands the scope, the timing, the enforcement exposure, and the work required to comply. A date on its own does not move a committee. The CMMC timeline shift I covered in CMMC Phase 2 Paused: Why the Work Should Not Stop is a live example of a deadline that moved and left buyers unsure whether to act, and that uncertainty stalls decisions.

Fifth, lower the buyer's career risk. This is the counterintuitive one. Where fear of a wrong decision is the obstacle, piling on more evidence of how bad the status quo is tends to backfire. The JOLT research found that leaning harder on the cost of inaction made things worse more often than not. The buyer already believes they have a problem. What they need is confidence that choosing you is the safe move, not another reason to be afraid.

I write about this intersection of cybersecurity and commercial strategy, because in enterprise security they are the same discipline. If your team is working through a stalled deal or a buying process that will not close, connect with me on LinkedIn.

Frequently asked questions

Who actually decides on a cybersecurity purchase?

Rarely one person. Enterprise security deals commonly involve security, architecture, compliance, procurement, finance, and legal. A technical champion often starts the process, but the budget owner has to carry the business case, and procurement, legal, security architecture, privacy, or executive leadership can reshape or stop the decision.

Why do enterprise security deals stall?

Most stall on internal disagreement, not on the product. Gartner found that 74 percent of buying teams hit unhealthy conflict during the decision, and no decision is a leading cause of lost deals. When a committee cannot align, the safest path for its members is to postpone, and postponement usually ends the deal.

What is the biggest mistake security vendors make?

Selling features to the champion instead of selling business outcomes to the whole committee. A champion who loves the product still has to win an argument with a budget owner and a room full of peers. If you have not given that champion a business case and political cover, you have left them to lose the deal on your behalf.

How long do enterprise cybersecurity sales cycles run?

Complex enterprise deals commonly run several months, and often past a year, because every added stakeholder adds research, review, and another chance to stall. The length is a symptom of the committee dynamic, which is why shortening a cycle depends on reducing internal friction rather than pushing harder.

The skill that decides the deal

Cybersecurity is one of the largest and fastest-growing categories of enterprise spending, and the competition for those budgets is fierce. Yet most of the vendors and internal teams fighting for that money are fighting the wrong battle. They sharpen the product when they should be learning the buyer.

The enterprises writing these checks do not buy the best technology. They buy the case they can defend, from the vendor who made the decision feel safe. The teams that win have stopped treating the sale as something beneath the technology and started treating it as the discipline it is. Translate the risk into money, arm the people who decide, and take the fear out of the choice. That is how enterprises actually buy cybersecurity, and it is how you get them to buy yours.

---

Navneet Lounsberry writes on cybersecurity and commercial strategy, drawing on more than two decades in enterprise technology sales and business development across IBM, SAP, Manhattan Associates, and UKG.

Copyright © 2026, Full Throttle Media, Inc. FTM #fullthrottlemedia #inthespread #sethhorne

How B2B buyers use AI to pick vendors before sales

 

By the time a buyer books a call with your sales team, the important decision is usually already made. They have framed the problem, compared you against two or three competitors, drafted a business case, and ranked a shortlist. Much of that happened inside an AI tool you never saw, in a room you were never invited to.

If your go-to-market still treats the first sales conversation as the start of the deal, you are optimizing for a moment that no longer decides much. The evaluation that used to happen on your website and across a series of sales calls now happens earlier, faster, and mostly out of view, because buyers research vendors with AI before they raise their hand. This is the same dynamic behind B2B displacement campaigns that win before the obvious buying moment, pushed one step further back into the journey.

Is the vendor shortlist really decided before sales contact?

Yes, and the data is blunt about it. 6sense's 2025 Buyer Experience Report, a global study of nearly 4,000 B2B buyers, found that 95 percent of the time the winning vendor was already on the buyer's Day One shortlist, formed before any seller contact. The vendor a buyer prefers before engaging sales goes on to win roughly 80 percent of deals. Buyers now reach the point of first contact around 61 percent of the way through their journey, and when they do reach out, they contact their preferred vendor first.

The implication is uncomfortable but clarifying: your sales team is mostly confirming a decision, not creating one. Kerry Cunningham, who leads research at 6sense, said the urgency for revenue teams is to "influence those early journeys before buyers reach out." By the time the demo is booked, the ranking already exists. You are either at the top of it or explaining why you should be.

 

 

How do B2B buyers use AI to research vendors?

They use it to do the work a salesperson used to do. Forrester's 2026 Buyers' Journey Survey, covering nearly 18,000 global business buyers, found that 94 percent used generative AI during their purchase, up from 89 percent a year earlier. More striking, twice as many buyers named generative AI and conversational search as their most meaningful research source than named any other, ahead of vendor websites, product experts, and sales reps.

Look at what they do inside those tools. Forrester reported that a majority now compare vendors and research products in AI before contacting anyone, and nearly half build their internal business case there too. G2's 2025 buyer research put generative AI chatbots as the single most influential source for building a shortlist, ahead of review sites, vendor websites, and peer recommendations. The comparison table you hoped a prospect would study on your site is now generated on demand by a model, using whatever it can find and trust about you.

This is the practical cost of sitting out, and it is why treating "we don't use AI" as a neutral position is already a losing one. Your absence from those answers is not neutral. It is a vote for your competitor.

Why this breaks the MQL scoreboard

Most B2B teams still measure marketing by form fills and lead volume. That scoreboard now tracks the wrong game. Gartner's research on the buying journey found that buyers spend only 17 percent of their total purchase time meeting with potential suppliers, and when they are comparing several vendors, as little as 5 to 6 percent with any one of them.

So the leads in your funnel represent a sliver of the journey, and often the least decisive part. If 95 percent of winners were already shortlisted on Day One, your MQL report is largely counting deals whose outcome was set before the form was filled. Lead volume has become a lagging, partial signal, while the decisive activity happens in the anonymous research phase your CRM will never log.

Does AI decide the deal, or just start it?

Here is where the hype overshoots, and where the real opportunity sits. AI builds the shortlist and picks the early frontrunner, but it does not close the sale on its own. Gartner found that even as buyers lean on AI, 69 percent still turn to a sales rep to validate the AI-generated insights they gathered, and they consult around seven sources before deciding. Forrester found that a fifth of buyers felt less confident in a decision after using generative AI, because they hit unreliable or conflicting information.

That gap is your opening. Preferences formed early are not always locked. A regional 6sense and MarketOne study of buyers in the UK and Ireland found that about a third shifted their top choice during the validation phase, the highest movement of any region measured. The frontrunner has the advantage, not a guarantee. Two moves follow. Get into the shortlist during the research phase, and equip your sales team to validate and de-risk rather than repeat what the model already said. A rep who adds nothing beyond the AI summary gives the buyer no reason to move you up.

How do you get on the AI shortlist?

You earn a place the same way you earn an AI citation: by being the source models can find, trust, and quote. That work is concrete.

• Publish content that answers the comparison and fit questions buyers actually ask, in clear, extractable language a model can lift into an answer.
• Back claims with evidence and specifics, since models and buyers both discount vague marketing copy.
• Show up on the third-party sources buyers and models trust, including review platforms and credible communities, not only your own domain.
• Close the information gaps that push a buyer elsewhere, especially the technical and capability detail competitors may be hiding behind a form.

This is where answer engine and generative engine optimization stop being a traffic tactic and become a sales strategy. If you have mapped how SEO, AEO, and GEO work as one system, this is the commercial payoff: visibility in the answers where shortlists are now built. Being the vendor the model recommends is the new version of being the vendor the analyst recommended.

Frequently asked questions

Do B2B buyers really choose a vendor before talking to sales?

Mostly, yes. 6sense's 2025 study of nearly 4,000 buyers found the winning vendor was already on the Day One shortlist 95 percent of the time, and the pre-contact favorite won about 80 percent of deals. Sales tends to confirm the decision rather than originate it.

How many B2B buyers use AI to research vendors?

Forrester's 2026 survey of nearly 18,000 buyers found 94 percent used generative AI during their most recent purchase, up from 89 percent the year before, with generative AI and conversational search named the most meaningful research source by twice as many buyers as any other option.

Has AI made B2B sales cycles shorter?

On average, yes. 6sense found the typical cycle compressed from 11.3 months in 2024 to 10.1 months in 2025, driven by faster AI-assisted research rather than less of it. Buyers move quicker but do not take on more risk.

Can you still win if you are not the Day One favorite?

Sometimes. Preferences can shift during validation, and one regional study saw about a third of buyers change their top choice late in the process. The odds favor the frontrunner, so the goal is to enter the shortlist early and give buyers a reason to reorder it.

What should you measure instead of lead volume?

Track your presence and framing in AI answers for your category, whether you make buyer shortlists, and pipeline sourced from the research phase your analytics cannot see directly. Pair those with buyer self-reporting to catch influence that never shows up as a clean referral.

Win the room you cannot see

The most important sales meeting in a modern B2B deal is one you will never attend. It happens between a buyer and a model, weeks before anyone books a call, and it decides who makes the shortlist and who leads it. You cannot sit in that room. You can shape what is said about you in it.

That means building content the AI can find, cite, and trust, closing the gaps that send buyers to competitors, and repositioning sales as the team that validates and de-risks a decision rather than the one that starts it. The vendors winning now are not the ones with the sharpest closers. They are the ones already recommended before the conversation begins.

Getting picked early is the whole game. Build for the shortlist, because that is where the deal is decided.

 

Copyright © 2026, Full Throttle Media, Inc. FTM #fullthrottlemedia #inthespread #sethhorne

AI Is Writing Your Code and Leaking Your Secrets

 

I use AI to write code, and I am not giving it up. Neither should your engineering teams. Teams are adopting AI assistance to ship faster, and that shift is not reversing. That is exactly why the security problem underneath it deserves a clear look. AI-assisted development can introduce hardcoded secrets and expand the number, privilege, and reach of the non-human identities working across your delivery pipeline. Most organizations are not governing either one, and that gap is where the next wave of breaches is forming.

None of this argues for slowing down. It argues for governing what AI-assisted development creates, so the speed you gained does not turn into exposure you never priced in.

The risk is not one thing. AI-assisted development expands risk in three connected but distinct places. The generated code can carry security defects. Prompts, repositories, logs, and output can expose credentials, in both directions. And the agents reaching your source control, cloud services, and data need identities with carefully bounded permissions. A secret scanner does not fix an over-permissioned agent, and least privilege does not catch insecure application logic. You have to govern all three.

 

How does AI-assisted development expose secrets?

AI-assisted development exposes secrets because the models reproduce the patterns they learned from, and public code is full of hardcoded credentials. When an assistant generates a working example, it can embed an API key, a connection string, or a token directly in the code, especially when the prompt, the repository context, or the surrounding code already normalizes that pattern. The code runs. The secret can ship.

The data released in 2026 shows how fast this grew in 2025. GitGuardian's State of Secrets Sprawl 2026 counted more than 28 million new hardcoded secrets in public GitHub commits during 2025, a 34 percent jump and the largest single-year rise on record. Leaks tied to AI services rose 81 percent in a single year. In the same analysis, commits co-authored by one popular assistant, Claude Code, exposed secrets at 3.2 percent against a 1.5 percent baseline across all public commits. GitGuardian is careful about that number, and so am I. The leak still runs through a human workflow. Developers decide what to accept, edit, or push. The tool did not fail. The process around it did.

Two forces compound the problem. AI increases code volume and change velocity, which makes manual-only review less reliable as the primary control. And the exposure runs in both directions. An assistant can write a secret into code, and a developer can hand one to the assistant, pasting a production log, a config file, or an error trace full of tokens into a prompt. GitGuardian found that roughly 28 percent of secret incidents now originate outside code repositories entirely, in places like Slack, Jira, and Confluence, where credentials get shared during urgent troubleshooting. Any policy that governs only the code misses half the problem.

None of that is a reason to stop. It is a reason to assume AI-assisted work may contain secrets until a scan proves otherwise, and to govern both what the tools can reach and what people can submit.

Every AI coding agent needs a governed identity

Here is the part that sits squarely in my field. AI-assisted development is not only a code problem. It is an identity problem.

Every AI agent that reaches your environment does so through one or more non-human identities: a service account, an OAuth client, an API key, a certificate, or a short-lived token. A coding assistant, a build agent, a deployment bot, each authenticates as something, and the more work you hand it, the more entitlements it accumulates. In agentic and multi-agent workflows, one orchestrator can create or delegate to additional agents, multiplying credentials and audit paths as it goes.

 

This is not a fringe concern. Reports through 2026 put non-human identities at anywhere from around fifty to one hundred times the number of human identities in cloud-heavy environments, with the exact ratio depending on what gets counted. The World Economic Forum has called non-human identities the new frontier of agentic AI risk, and analysts increasingly treat AI agents as a distinct identity type that is neither fully human nor fully machine. I covered the governance side in Non-Human Identities and AI Agents: The New Blind Spot in Your IAM Program, and AI-assisted development is where that blind spot turns operational.

The risk is not limited to the code an assistant suggests. Once an agent can read a repository, call tools, open tickets, invoke CI/CD, or connect through a Model Context Protocol server, it becomes an execution path into the enterprise. GitGuardian found more than 24,000 secrets sitting in Model Context Protocol configuration files on public GitHub, a pattern the setup instructions themselves often encourage. Add prompt injection delivered through a README, an issue, or a dependency's documentation, and the agent's permissions, allowed tools, and data boundaries need the same design discipline you give any privileged workload.

The uncomfortable pairing is this. AI writes code that leaks the very secrets these identities depend on, inside a system where the identities themselves are barely governed. Leaked credential, meet ungoverned identity. That is the attack path.

The productivity is real, so protect it

I want to be direct about where I stand, because the headline can read the wrong way. I am not arguing against AI-assisted development. I am arguing for keeping it.

The teams shipping with AI assistance are faster, and that advantage is not going back in the box. Telling engineers to slow down is both futile and wrong. The organizations that win will adopt aggressively and govern deliberately, and those two things are not in tension. Security is not the brake on AI development. It is what lets you keep your foot on the accelerator without wrapping the car around a tree.

Consider how a mature enterprise already treats any third-party dependency. You do not refuse open-source libraries because some carry vulnerabilities. You scan them, track them, patch them, and keep shipping. AI-generated code deserves the same posture. Treat it as untrusted input from a very fast contributor, verify it, and move on. That is not skepticism about AI. It is how you make AI safe to rely on at scale.

How do you secure AI-assisted development without slowing it down?

You secure it by governing the two things AI development produces, code and identities, with controls that run at machine speed instead of human speed. The goal is not more meetings. It is automation that keeps pace with the tools creating the risk.

A practical program rests on a few moves:

• Scan for secrets continuously, in the pipeline and beyond it. Run detection on every commit and every AI-assisted change, and extend it to the tickets, chat, and logs where secrets also land. Removing a key from code is not enough, since it can be recovered from history, so rotate or revoke it too.
• Give every agent its own scoped identity. No shared keys, no borrowed service accounts, outside narrow legacy exceptions you document and monitor. Each agent gets a named identity with least-privilege access to only what its task requires.
• Prefer short-lived, dynamically issued credentials. Replace long-lived static keys with tokens that expire in minutes where the platform supports it. A leaked credential that has already expired is close to a non-event.
• Keep an owned inventory of non-human identities. Every agent and service account needs a human owner, a documented purpose, and a decommission date. Unowned identities are where risk hides.
• Treat AI output as an untrusted contribution, and do not stop at review. Apply the same supply-chain controls you use elsewhere: dependency and infrastructure-as-code scanning, branch protections, code-owner review for anything touching authentication, authorization, cryptography, payments, data access, or deployment, and an audit trail that ties each material change to a user, an agent, and an identity.

These controls shift the security work from a late, manual gate to an early, automated one, which is the only model that survives contact with AI-speed development. Integrated into developer workflows, they cut late-stage rework instead of adding a release bottleneck, and they keep most of AI's delivery advantage while slashing the cost of remediation.

Detection without revocation is not remediation, and the data proves it. GitGuardian retested credentials it first confirmed valid in 2022 and still found more than 64 percent of them live in 2026. When a secret surfaces, rotate or revoke it, trace where it was used, assess what it could reach, and fix the control at the point it entered the workflow.

Where you sit on this path matters more than doing everything at once:

Stage	Minimum standard
Pilot	Approved tool list, no production secrets in prompts, user-level attribution, basic secret scanning
Team rollout	SSO and SCIM, repository and data-access boundaries, CI secret scanning, branch protections, named owners for service accounts
Enterprise scale	Short-lived federated workload identity, centralized secrets management, agent and tool allowlists, full audit logging, revocation workflows, continuous entitlement review

This is also where the commercial conversation lives, and it is rarely a technical failure that stalls these programs. It is that the person who sees the risk cannot translate it into a consequence the budget holder acts on. I worked through that exact dynamic in Why Identity Risk Loses the Budget Conversation, and it applies directly here. Frame AI governance as protecting the productivity leadership already values, and you get funded. Frame it as a brake, and you do not.

I write about where identity security and commercial strategy meet, because in AI-assisted development they are the same conversation. If your organization is working through this, connect with me on LinkedIn.

Frequently asked questions

Is AI-generated code less secure than human-written code?

Not inherently, but it should not be presumed secure. Results vary by model, prompt, language, task, and review process. A 2026 study across six leading models reported confirmed vulnerabilities in about a quarter of generated samples, while earlier research on one popular assistant found security weaknesses in roughly 40 percent of the scenarios tested. Those figures need their methodology to mean anything, and they do not add up to a universal defect rate. The operational answer is to test and review AI output under the same controls, or stronger ones, that you apply to any untrusted contribution.

What is a non-human identity in AI development?

It is the identity assigned to software, a workload, a service, a bot, a pipeline, or an AI agent, so it can authenticate and act without an interactive human login. Its authenticator might be a service account, a workload identity, an OAuth client, a certificate, an API key, or a short-lived token. The governance questions that matter are who owns it, what it can access, how long it lasts, how its activity is logged, and how it gets revoked.

Can developers paste production code or error logs into a coding assistant?

Only if your organization has approved the tool, understands its data-handling terms, and has defined what may be submitted. Production secrets, customer data, private keys, and regulated information should be blocked or redacted before they reach a prompt. The same policy should cover repository-context features and tool integrations, not just the chat box.

What should happen when a secret shows up in AI-assisted code?

Treat it as an incident, not a text edit. Revoke or rotate the credential, determine whether it was used, assess the access it carried, remove it from active code and configuration, and add or tune the control that should have caught it before production.

How do we let developers use AI without creating security debt?

Automate the controls so they run at the speed of the tools. Scan every change and channel for secrets, scope each agent to least privilege, expire credentials quickly, and review AI output like any third-party dependency. That keeps the productivity while closing the exposure.

The speed is worth keeping

AI-assisted development is one of the most significant productivity shifts enterprise engineering has seen, and the organizations leaning into it are right to. The mistake is treating the speed as free. It arrives with generated code that needs verifying, secrets that need detecting and rotating, and machine identities that need scoping, ownership, and observation, and the companies that build those habits early will keep their advantage while others clean up breaches they could have prevented.

AI is writing your code, and yes, it can leak your secrets. That is a solvable problem, and solving it does not mean making developers wait. Make secure behavior the default: credentials injected at runtime instead of written into code, short-lived access instead of permanent keys, and automated checks that catch problems before production. Govern the identities, protect the context, scan the code and the secrets, and let your teams keep building at the speed the tools finally made possible.

---

Navneet Lounsberry writes on cybersecurity compliance and commercial strategy, most recently with Idenhaus Consulting. She spent more than two decades in enterprise technology sales and business development across IBM, SAP, Manhattan Associates, and UKG.

 

Copyright © 2026, Full Throttle Media, Inc. FTM #fullthrottlemedia #inthespread #sethhorne