Tuesday afternoon. You are not free for sport. You unlock your phone, open a booking app, search the club you always search, filter the sport you always play, and check whether next Sunday has materialised. It has not. You leave. Wednesday: same loop. Thursday: the row exists, so you race to book. Congratulations. You have performed a transaction after days of unpaid monitoring.

I want to play pickleball — not refresh the page in the stupid app.

That line is not a niche complaint about one club’s software. It is the shape of a competitive era. The service already knows when inventory flips from unreleased to released. What it does not hold is your durable intent: that you regularly want a particular class of session, that you are already booked next week, that you will not drive across the city for a brand you do not care about. Without the join between their state and your intent, the only integration layer left is you.

Conversion was never the same as low effort

For twenty years the industry success criterion was simple: keep friction below the abandonment threshold. Twenty clicks and the user leaves. Ten clicks and they swear but complete. Five clicks is “acceptable.” One click is excellent. If ten clicks still produced a booking, product management could say the product works.

The company saw conversion achieved. The customer experienced attention wasted. The waste never appeared in the accounting system. Human attention was a free external resource. A booking platform could effectively say: perform ninety seconds of unpaid inventory reconciliation for us twice a week — and the customer would do it, so the system was “functioning normally.”

Customer-effort research has been screaming this for more than a decade. In the CEB lineage that created Customer Effort Score, high-effort service interactions were associated with dramatically higher disloyalty than low-effort ones — on the order of ninety-six percent of high-effort customers becoming more disloyal versus about nine percent after a low-effort experience.¹ McKinsey’s personalisation work found that seventy-one percent of consumers expect personalised interactions, and seventy-six percent get frustrated when they do not get them.²

You do not need those figures to feel the architecture. You need them to stop treating friction complaints as taste. Effort predicts loyalty more reliably than delight theatre. Personalisation expectation means stable intent should not be re-entered from a blank search box every session.

You are the join algorithm

Look at what a “simple booking” actually demands of a regular customer. Provider state lives in the app: events, capacity, release windows, payment rules. Personal state lives in the customer’s head and calendar: preferences, existing bookings, energy after a late night, which club is worth the drive. Every session, the human reconciles the two.

OPENSPORTS STATE
       +
CUSTOMER MEMORY
       +
CUSTOMER PREFERENCES
       +
CUSTOMER CALENDAR
       +
EXISTING BOOKINGS
       ↓
CUSTOMER MANUALLY COMPUTES
       ↓
CLICK

Nielsen Norman’s classic usability heuristic is almost embarrassing in this light: interfaces should minimise memory load; people should not have to remember information from one part of a system to another.³ Habitual booking apps that force re-search, re-filter, and visual archaeology of tiny status badges are not merely “a bit clunky.” They are industrialised memory violations.

Friction arbitrage

AI changes the unit economics of that unpaid labour. Another system can absorb ten interactions once, understand the pattern, and spare the human from performing them forever:

I mostly want this club’s pickleball on Sundays and Wednesdays. Beginner-ish sessions. Keep an eye on it. Don’t double-book my calendar. Keep me in the next suitable sessions.

Traditional automation hated that sentence. It wanted rigid rules: day in Sunday or Wednesday, venue id equals X, level equals beginner. Real intent is semantic and slightly fuzzy. Maybe a Saturday appears when Sunday dies. Maybe the label says “social” instead of beginner. Maybe the customer progresses. AI can hold the continuity of intention without forcing a human to rewrite a rule engine every time reality wiggles. Deterministic systems can still do the booking. The translation tax collapses.

That question is the spine of this book. Every repeated translation step is a candidate for collapse. Every candidate for collapse is a place an AI-native entrant can attack while you are still celebrating that people eventually convert.

This is Terminal Value thinking at the workflow seam: not “how do we make the booking form faster,” but “which high-affinity customers leave first when cheap cognition removes the attention tax we never put on the books.”

What this book will and will not do

We will classify friction so you can stop treating all clicks as equal. We will give you a two-sided Human Touch Audit — customer appearances and staff presence. We will name the cognitive failure that makes “better than the last system” feel like “solved,” including the decision defence that answers criticism with screenshots.

We will not design the personal agent that holds intent, or the service surface that lets that agent operate your business without impersonating fingers on your UI. Those are sibling doctrines. We will not redesign your underlying market. We will not re-teach the full replace-versus-automate playbook. Diagnosis first. The map of unpaid attention is the deliverable.

You know an app is in trouble when “search things near me” is still the main door on visit twelve. Near-me search is a perfect first-session feature. For a regular who has exclusively booked one sport at one club for months, it is cognitive amnesia dressed as helpfulness.

Chapter 1 gave the diagnostic question: where do customers repeatedly translate stable intent into your required interactions? This chapter gives the sorting hat. Without a taxonomy, every team either defends all friction as “how the system works” or tries to delete physics. Both fail.

The three classes

Necessary friction — do not pretend AI deletes physics

Necessary friction is the class people reach for when they want to stop the conversation. “Someone has to confirm payment.” “Courts are finite.” “We cannot let people book six months solid and lock out everyone else.” Fine. Those constraints can be real.

AI does not magically remove authority or capacity. Someone must still be allowed to spend the money. A session can still be full. A cancellation window can still have teeth. The point of the taxonomy is not utopian zero-touch fantasy. It is to stop necessary constraints from laundering accidental and wrong labour.

When a club says inventory is scarce, that can be physics. When the club uses human attention as the allocation protocol — open the app on the right afternoon, refresh until the row appears, race the other regulars — that is no longer pure physics. That is architecture using nerves as a queue.

Accidental friction — the cloud-app hangover

Accidental friction is the tax of historical software. You already told reality, through behaviour: this city, this sport, this club, these days, this level band, I attend what I book. Yet each open restarts the ontology from near-me search and a multi-sport catalogue.

The app has data. It does not hold intent. That distinction matters. Data is rows. Intent is custody of a durable preference through time. Without custody, the interface must keep asking the human to re-express what behaviour already proved.

This is the cloud-app mentality in miniature: the last platform was a mess, so we swapped to a different cloud app that does five things better, migrated the sessions, and declared victory. Accidental friction often drops in the swap — fewer grotesque failures, clearer payments, less competition from unrelated events on a social network. Relief is real. Accidental friction that remains is still unpaid labour: re-select, re-navigate, re-interpret badges, re-check availability.

Wrong friction — the business model wearing a UX costume

Wrong friction is the competitive core. It exists because of how the provider (or the platform the provider rented) models its business — not because the customer’s outcome requires it.

A multi-sport aggregation play wants discovery inventory. Of course it does. Clipping tickets across basketball, volleyball, and pickleball is a rational platform strategy. It does not follow that a habitual pickleball regular should be forced through other sports, other suburbs, and acquisition-sized logos on every path to a transaction they have completed a dozen times.

Wrong friction is where incumbents get most defensive, because removing it can threaten a platform narrative (“we are a sports discovery network”) or a migration story (“we are modern now”). That is exactly why it is attack surface. An AI-native entrant does not need to win the multi-sport catalogue war. It needs to collapse the translation between “keep me playing suitable sessions” and a confirmed place on court.

How to use the taxonomy without lying to yourself

Walk a real journey with a highlighter:

1. Green: necessary — would still exist if we redesigned from scratch with cheap cognition.
2. Amber: accidental — exists because of how software was built, not because of physics.
3. Red: wrong — exists because of our (or our platform’s) commercial model of the customer.

If your page is mostly green, you may be less exposed than you fear. If your page is amber and red with a green fig leaf labelled “payment confirmation,” you are not looking at UX polish debt. You are looking at a map an attacker can read.

One more honesty test. When a process only works because staff explain it, because a WhatsApp group carries the announcements the app cannot route, because regulars teach new people the tribal workarounds — the taxonomy is incomplete until you count those supplements. A system that requires a shadow channel is already confessing.

Open the analytics. The user opened the app. Searched. Viewed an event. Clicked through. Booked. Funnel healthy. Engagement strong. Product working.

Now open the customer’s mouth. Twelve clicks of unpaid join work. Other sports they never play. Events they cannot book. A logo they already know. A return visit mid-week because nothing held their intent against inventory. Same facts. Opposite story.

Name the surface

Security people ask: what is exposed? Where can someone get in? AI-native strategists should ask:

Where is the customer currently tolerating friction because there has never been a cheap intelligence capable of removing it?

That is the Friction Attack Surface. It is not a metaphor for “we should improve UX.” It is a competitive claim. The incumbent’s wrong and accidental friction is the entrant’s product brief.

The attacker does not need to rebuild the entire category on day one. It can leave the incumbent system intact and arbitrage the attention tax: hold intent, collapse translation steps, deliver the terminal outcome. The booking system becomes a subordinate implementation detail. The promise shifts from “we make sports booking easier” to “we make you play.”

Incumbent competitors vs attacker question

Incumbents compare feature matrices. Payments? Waitlists? White label? Mobile app? Memberships? Their competitive set is other platforms that look like them.

The AI-native entrant asks a different question: how much customer attention does this category currently consume unnecessarily? That is not a feature comparison. That is a friction attack. It is the same altitude shift as asking what an AI-native startup takes first when cognition is cheap — customers who were already paying the highest unpaid tax for the least structural reason.

If you were doing a fantastic job — truly low unnecessary friction, intent held, outcomes delivered — there would be less oxygen for an entrant. When the product is only just good enough that it is not useless, you are not safe. You are inviting the next entrepreneur to notice the tax you never measured.

The engagement inversion

Here is the almost perfect disruption bait. The organisation’s instruments may interpret friction as health.

Scott opened app ✓
Scott searched ✓
Scott viewed event ✓
Scott clicked event ✓
Scott booked ✓

ENGAGED USER!

You had to fuck around for twelve clicks. Their analytics may score that as engagement. Session time rises when the architecture is dumb. Search frequency rises when intent is not held. Return visits rise when the customer is a polling daemon. Teams then optimise to preserve the very interactions that prove the design failure.

This is why “people still convert” is not a defence. Conversion can coexist with a loyalty cliff. High effort is a known disloyalty machine. The dashboard just was not built to see the cliff from inside the funnel.

Grease is not the same as remove

A predictable wrong response is to shave clicks off the inherited path: better filters, remembered last sport, fewer banners. Sometimes that is worth doing. It is still usually the wrong altitude if the path itself is wrong friction. Greasing an unnecessary translation step is not the same as removing it. Stop Automating, Start Replacing owns the full doctrine of questioning whether the process should exist; here we only need the competitive edge of that truth — an attacker will not politely optimise your click path. They will delete the need for the path.

McKinsey’s agentic-AI work lands in the same neighbourhood from the enterprise side: realising agent value means rearchitecting task flows and reallocating work between humans and agents, not layering automation on top of inherited workflows.⁴

What we are not building in this chapter

The personal agent that holds intent, and the service that becomes addressable to that agent without UI impersonation, are real. They are also sibling books. If you leave this chapter hungry for the replacement architecture, good — stay hungry. The job here is colder: map the exposed ports of attention. You cannot defend a surface you still call engagement.

Imagine reviewing every customer interaction the way an incident team reviews a production page. Not with a journey map that assumes the journey should exist. With a ticket.

Scott opened the booking app at 8:13 pm.

WHY?

Answer: he wanted to know whether a suitable future session had become bookable. Okay. Why did Scott need to inspect that?

The software already has event availability, release state, existing bookings, club, sport, session type, and a history of past behaviour. An intent-holding system could already know the preference pattern: Sundays and Wednesdays, this club, suitable sessions, do not double-book. So why did the human appear?

There is no good answer. He appeared because the architecture is dumb.

The audit tree

HUMAN TOUCH DETECTED
        ↓
why?
        ↓
Was judgement genuinely required?
Was new intent required?
Was authority required?
Was consequence exceptional?
        ↓
NO?
        ↓
DESIGN FAILURE

That is the whole method. It is brutal on purpose. White-glove service can be brilliant. Human contact is not the enemy. Unnecessary human operational interaction is a cost — paid in customer attention on this side of the ledger, and in staff ritual on the other (Chapter 5).

Full worked audit: the mid-week open

Incident: Regular customer opens multi-sport booking app mid-week.

Surface reason: Check whether next suitable session is bookable.

Deep reason: Inventory is released on a cadence the human must remember. Nothing holds durable intent against that inventory. The customer is a polling daemon and a semantic join engine.

Contrast a touch that can pass. The customer says: I am bored with Sunday; show me something weird. That is new intent. Browse is legitimate. Or: cancel if I got home after midnight and have an 8 am booking — that may require standing authority rules and an exceptional personal condition. The audit is not “humans never touch software.” It is “humans do not touch software to perform jobs the system already has the inputs to perform.”

What the club thinks it sold vs what the customer wanted

The provider’s north star is usually something like: people turn up, have a great social sporting experience, come back, and pay. The customer’s desired path is almost embarrassingly simple: arrive, park, walk in, play. Everything between stable intent and that arrival that is not physics or authority is a candidate for the red pen.

The cruel comedy is that many operators believe they already delivered low friction because they moved off a worse platform. They still ask the customer to log in every few days, find the spot, join, and pay per session — and they call that the product. From the audit’s point of view, that product is a long chain of human touches that fail the tree.

Shadow channels are confessions

When announcements about rain, cancellations, and admin still spill into a chat group; when staff must explain how to find the right screen; when regulars train newcomers in tribal workarounds — the system is incomplete. The WhatsApp-supplement pattern is not “community.” It is unpaid attention routing the product failed to do.

Broadcast mental models make this worse. Say it somewhere public; assume the right humans will self-select. That model was barely tolerable when human secretaries filtered life. It is absurd when every service claims the same right to poke you and none of them holds your intent.

The north-star question (audit, not architecture)

That question is a boundary case for diagnosis. It is not a permission slip to design the personal agent, the interrupt gate, or the service delegation surface in this book. Those are real problems with real sibling doctrines. If you skip the audit and jump to solution design, you will automate the wrong touches and call it transformation.

Use the question to stress-test each step: if this touch cannot survive a world where setup happens once and intent stays in custody, it is either necessary (authority, new intent, exception) or it is a design failure wearing a habit.

How to run the customer-side audit tomorrow

1. Pick one high-frequency outcome a loyal customer wants (book the usual session, reorder the usual SKU, renew the usual policy).
2. List every time a human must appear to make that outcome happen.
3. For each appearance, write one sentence: why did the human appear?
4. Run the four gates. If all are no, mark design failure — even if conversion currently works.
5. Tag failures as accidental or wrong using Chapter 2. Wrong failures are your attack surface shortlist.

Do not soften the language. “Opportunity for improvement” is how attack surfaces stay unowned. Design failure is accurate when the system already had the inputs and still conscripted a nervous system.

We have spent chapters asking why the customer appeared. Now ask the twin question with the same seriousness:

Why did the on-site staffer appear?

In the lived pickleball teardown, a session gathers on the order of thirty people. A thin per-player contribution — think something like five dollars times thirty for a rough one-hundred-and-fifty-dollar contribution before other costs — is not a market study. It is enough arithmetic to ask what labour is actually buying. Players put nets out. Players pack nets away. Players rotate themselves across courts. Players clear debris. Players play and socialise. The staffer arrives, unlocks or provides equipment, perhaps greets, plays a little, remains for two hours.

That presence feels like service. Sometimes it is. The audit demands we prove it.

Decompose the human

When the decomposition collapses to access control, the operational architecture is almost comically simple:

EQUIPMENT
    ↓
LOCK
    ↓
HUMAN WITH KEY
    ↓
drive to venue
    ↓
remain around for two hours

The employee may currently be a biological access-control system. That is an unbelievable business-process smell once you say it out loud. It is also provider-side wrong or accidental friction: human touch that fails the same gates as the customer’s mid-week open.

Run the tree on the staffer

Electric lock as mechanism, not gadget fetish

The fix pattern is not “buy a smart lock and call it innovation.” The fix pattern is architectural:

VALID SESSION
      ↓
one or more authorised attendees
      ↓
temporary access credential
      ↓
unlock equipment
      ↓
players setup
      ↓
players pack
      ↓
lock

Now labour becomes exception handling, not routine presence. Equipment missing? Someone did not pack up? Access fault? Incident? A human gets involved. Otherwise the market clears and people hit the ball.

Risk arguments deserve a clear eye, not a romantic one. Portable nets without courts and without a guaranteed player network are surprisingly low-value loot. Theft and breakage still happen in the real world; the question is whether the expected loss justifies two hours of routine human presence every session, or whether exception response plus cheap access control is the saner design. Many operators have never run that calculation because presence feels like care.

Why this is still the friction attack surface

Provider-side failed audits are not a side quest. They are the other half of the competitive map.

An AI-native operator does not only collapse customer translation steps. It also refuses to fund ritual presence that fails the tree. The incumbent pays for a body with a key and calls it service. The attacker pays for credentials, exception workflows, and outcomes. Cost structures diverge. Pricing power shifts. The customer who only wanted to play experiences one side of that shift as fewer pointless opens; the operator who still thinks the business is “drive down and unlock” experiences it as margin compression they did not model.

We are deliberately not redesigning the underlying market here — not liquidity, not session formation economics, not dynamic court bundling. Those are sibling problems. The audit only needs you to see that presence without judgement is exposed friction on the supply side the same way polling without new intent is exposed friction on the demand side.

Altitude mismatch (preview of decision defence)

When a customer complains about booking friction, an owner who just migrated platforms often hears a UI critique and answers with screenshots. The customer may be asking a different altitude question entirely: why am I polling, why am I reconciling, why is a human standing next to six courts for two hours if the product is the game?

Those altitudes do not meet in a screenshot. Chapter 6 names the psychological trap. For this chapter, hold one sentence: defending the booking UI while the audit is about ontology is how attack surfaces stay invisible.

How to run the provider-side audit

1. Pick a recurring operational moment where a staff member or owner must physically or digitally appear.
2. List every function that presence is supposed to provide.
3. Strike any function customers already perform, or that a credential/automation could perform without judgement.
4. Whatever remains must pass judgement / new intent / authority / exceptional consequence — or it is design failure.
5. Separate exception paths (keep humans) from routine paths (remove ritual presence).

A willing regular mentions, lightly, that the new booking system is still frictional. Not a campaign. Not a one-star review pile-on. A gripe after a session. The owner — or the partner who runs the operation — texts back with screenshots. Look. The announcement was here. You were told. Here is the flow. Here is the proof.

That moment is not primarily about manners. It is a named cognitive failure with two layers: the friction baseline trap, and decision defence.

55 versus 100 versus 0

The old system was horrendous. Call that pain 100. The organisation moves to a modern multi-sport booking app. Pain falls to something like 55. Everyone says: so much better. And relative to 100, they are right.

They are benchmarking:

55  vs  100

The customer who still wants zero unpaid translation of stable intent is benchmarking:

55  vs  0

Completely different analysis. Same product. Opposite conclusion about whether the problem is solved.

It feels really good when you stop hitting your head against a brick wall. Relief is not excellence.

You removed the brick wall. Congratulations. Why is the customer now crawling through blackberry bushes?

Friction acclimatisation

Horrible systems train organisations. People build workarounds. Staff explain the unexplainable. Customers learn tribal paths. A chat group carries what the software cannot route. Processes adapt to terrible until terrible feels like weather.

HORRENDOUS OLD SYSTEM
      ↓
workarounds + supplements + trained customers
      ↓
MIGRATION to "much better"
      ↓
massive relief
      ↓
cognitive search terminates
      ↓
"SOLVED"
      ↓
(still structurally bad vs what cheap AI makes possible)

The new system may still be a database UI that asks every regular to search twice a week. Measured against the brick wall, it is a spa day. Measured against a world where intent is held and exceptions are rare, it is still an attack surface wearing a progress story.

The boundary question that breaks the trap

Surely not: we will maintain an event database and ask every regular customer to search it twice a week. Stated from scratch, that is insane. You would say: we know our regulars, we know what they play, we know when they usually come, we know our inventory, we want them on the courts. Keep suitable sessions handled. Tell us if your routine changes.

That is a sports service. A multi-sport event browser is a different object. The baseline trap keeps you from noticing you still built the browser.

Decision defence

Now the psychological layer. The owner did not casually install an app. They paid a migration cost:

• • Researched alternatives after enough pain
• • Moved everyone
• • Explained the new process
• • Absorbed early complaints
• • Finally got the new system running

Then a high-affinity customer says: still a bit shit. The owner does not hear neutral product evidence. He hears: the painful decision I just made may not have solved the problem.

So he becomes emotionally invested in proving the migration was right. Screenshots appear. Walkthroughs appear. “We announced it here.” The goal of the conversation quietly becomes NEW_SYSTEM = GOOD_DECISION, not “what is the customer’s unpaid labour still doing?”

He has confused better than the last system with good. Because the last system hit him in the head with a brick, the blackberry bushes feel like a spa. Decision defence is how the spa story gets enforced socially — on the customer who brought the only signal that matters.

What the customer was actually saying

Listen at the right altitude. The valuable signal is not “I could not find the announcement.” It is:

Your process is getting between me and consuming more of your product. The friction might make me stop.

For a business owner, that should be terrifying. A willing repeat customer with money and high product affinity is describing churn risk from interaction cost unrelated to the actual product. Answering with proof that the announcement existed is like answering a fire alarm by showing the building permit.

This is not a sermon about small-business psychology for its own sake. It is an operating risk: the people who just paid the migration cost are the least able to see the residual attack surface, and the most likely to punish the messenger.

How to catch yourself

1. Write your last major UX or platform change as two comparisons: versus the old pain, and versus zero unnecessary touch.
2. If only the first comparison is celebrated in internal narrative, you are inside the trap.
3. When you reach for screenshots after a friction complaint, pause and name whose decision you are defending.
4. Invite one high-affinity customer to narrate unpaid steps without correcting them mid-sentence. Correction is defence. Transcription is intelligence.
5. Re-run Chapters 4 and 5 audits on the “solved” system. Solved systems fail audits all the time.

Look at a modern phone honestly. Hundreds of apps. We are trained to read that as ecosystem richness. From the friction lens it can look like something colder: hundreds of separate deterministic systems that periodically require the human to visit and manually translate intent into each domain model.

The precise claim is not “apps are dead.” That is too easy to knock down. The precise claim is:

Every app interaction must now defend why the human is present.

Some interactions survive: genuine browse, genuine new intent, genuine authority, exceptional consequence. The rest is attack surface — and AI is repricing the labour that used to hide there for free.

Week-one checklist

1. List ten repeat interactions

Pick one loyal customer outcome your business depends on. List ten human steps required to produce it on a normal week. Not the marketing journey. The actual thumbs-and-attention journey.

2. Classify each step

Necessary / accidental / wrong (Chapter 2). If you cannot defend necessary without smuggling in platform discovery goals, it is not necessary.

3. Customer-side Human Touch Audit

For each customer appearance: why did the human appear? Judgement? New intent? Authority? Exceptional consequence? If no across the board — design failure. Use the tree from Chapter 4 as written. Do not invent softer language.

4. Provider-side Human Touch Audit

For each staff or owner appearance: decompose functions. If presence collapses to access control, queue-watching, or re-keying what systems already know, you have found the key-holder pattern (Chapter 5). Separate routine paths from exception paths.

5. Metric inversion check

Which dashboards rise when customers do unpaid translation? Opens, searches, session time, return visits, support contacts that are really navigation help. Mark any KPI that treats attack surface as health.

6. Baseline honesty

Write the last migration as 55-vs-100 and as 55-vs-0. If your culture only tells the first story, you are in the trap. Watch for decision defence: screenshots, walkthroughs, “we already told them” — especially from people who paid the migration cost (Chapter 6).

7. Stop at the map

Do not design the personal agent. Do not design the service delegation surface. Do not redesign market liquidity. Do not run a full automation portfolio workshop under this banner. Those are real, and they are owned elsewhere. Your job this week is the exposure map: a shortlist of wrong friction, failed human touches on both sides, and metrics that lie.

What “good” looks like after one week

You should be able to put a single page in front of an operator or a board subcommittee that says:

• • Here is stable customer intent in one sentence.
• • Here are the repeated translation steps (the attack surface).
• • Here is the taxonomy colouring: green / amber / red.
• • Here are the human touches that fail the audit on both sides.
• • Here are the metrics that currently celebrate those failures.
• • Here is where we are still bragging about 55-vs-100.

That page is not a transformation programme. It is the precondition for one. Bain’s clean-sheet redesign work and McKinsey’s agentic reinvent arguments both rhyme with the same warning from different doors: productivity on the inherited path is not the same as redesigning the path.⁵ You do not need their full programmes to complete this week’s job. You need their humility about inherited process.

The competitive close

Security teams do not wait until after the breach to ask what was exposed. They map ports, privileges, and paths while the lights are still on. Friction works the same way now that intelligence is cheap enough to remove unpaid translation labour.

Your customers used to subsidise your architecture with attention. That subsidy is ending. Barely good enough is not a moat. It is an invitation. Wrong friction is not a UX backlog. It is the product brief for the company that wants your high-affinity regulars.

Find the attack surface before they do.