Describe how to price differently for a customer whose queries are ten times more expensive.

Squire prices every seat the same flat amount. One customer's tickets cost ten times more to answer than everyone else's, because of what gets attached to them, not how many seats they bought. Nobody is grading whether you know costs can vary by customer. They're grading whether you'll commit to one fix, say who gets hurt by the other options in real numbers, and name what would make you change your mind.

How to answer this, stage by stage

Nobody is grading whether you can list "raise the price, absorb it, or charge differently" as three options. They're grading whether you can commit to one out loud, say who pays for the other two, and name the number that would make you change your mind.

Let's learn

Squire is a tool Thrushgate sells to support teams. It reads an incoming ticket, works out what kind of problem it is, and drafts a reply an agent can check and send.

Before Squire, a support agent spent about twenty minutes handling a normal ticket by hand: read it, check the account, write a reply. With Squire, that same ticket takes about six minutes: read the draft, fix a line, send it. A twelve seat customer, paying ninety nine dollars a seat a month, costs Thrushgate about twenty five dollars a month to run through Squire. That's about two cents on the dollar. Healthy.

Same agent, same tool. What changes the cost isn't the person, it's what got attached to the ticket before Squire ever saw it.

Then Anthaven Logistics signed up. Anthaven runs freight support: shipment delays, damaged claims, customs holds. Every ticket that reaches Squire has a shipment tracking log stapled to it automatically, thousands of lines of timestamped events, because that's how Anthaven's own system hands off a ticket. Squire has to read that whole log before it can draft a reply that gets the shipment right. A normal ticket costs about a penny and a half to answer. An Anthaven ticket costs about fourteen cents, because the model reads roughly ten times as much text before it writes a single word back.

Here's the turn. Ten times the cost per ticket is not really the problem. The problem is what that number does once you multiply it by how many tickets Anthaven actually sends. Forty seats, thirty thousand tickets a month, most of them carrying that log. Answering Anthaven's tickets costs Thrushgate about four thousand two hundred dollars a month. Anthaven pays three thousand nine hundred sixty dollars a month for those forty seats.

At its worst: logistics was already Thrushgate's fastest growing part of the pipeline. Every account shaped like Anthaven, tickets carrying a big log by default, would lose money the same way, quietly, until a whole vertical cost more to serve than it ever paid.

One mistake is small and loud. The other is huge and silent, right up until someone finally checks the segment.

What I'd leave alone: Coombewick Property Group, and every account shaped like it, twelve seats, tenant maintenance tickets, costs about two cents on the dollar to serve. Nothing about their invoice should change, because nothing about how they use Squire is expensive. The fix should only ever touch the accounts that are actually heavy.

The lesson: a flat price is a bet that every customer costs about the same to serve. That bet holds right up until a customer's tickets are shaped differently, and a flat price has no way to notice when that happens on its own.

Now here is the same thing as a story

Read the longer version below when you want to feel why an average that looked fine almost let Thrushgate lose money for a whole year without anyone noticing.

Danilo Alcaraz has owned Squire's pricing for fourteen months, and the one thing he's proud of is that he's never had to explain a price change to a confused customer. Every renewal, the invoice looks exactly like the customer expects. Flat, predictable, no surprises.

For most of that first year, flat pricing looked like the obviously right call. Every customer's tickets were roughly the same size: a few paragraphs, maybe a screenshot. Compute cost barely moved account to account. Danilo checked the company wide numbers once a quarter, cost as a share of revenue, and it always sat around two, maybe three percent. Healthy. Boring, even.

Then Anthaven Logistics came on, forty seats, a nice sized deal for the quarter Danilo closed it in. A few weeks in, someone on Anthaven's side mentioned, almost as a compliment, that Squire was "really thorough," because it kept quoting exact line items from their shipment logs in its draft replies. Nobody at Thrushgate asked why a support draft needed line items from a shipment log. The company wide cost ratio still read fine, because Anthaven was one account among hundreds, and its number was buried inside an average built mostly from small, cheap tickets.

There was no single bad Tuesday. It built up one quiet quarter at a time, the way a slow leak does.

There wasn't a single bad moment. It built up the ordinary way, one quiet quarter at a time, until the finance team ran its usual quarterly review and split cost out by account instead of just looking at the total. Split out, Anthaven's line was impossible to miss. Thirty thousand tickets a month, average fourteen cents to answer, next to a revenue line of three thousand nine hundred sixty dollars. Danilo did the subtraction twice before he believed it: Thrushgate was losing about two hundred forty dollars a month answering Anthaven's questions, and had been for months.

It wasn't really about the two hundred forty dollars. Danilo kept wanting to say the real problem was the model, that it was reading too much, that someone should just make it read less. But the model was doing exactly its job, getting the shipment right by reading the whole log. The real problem was that the price had no way to know a ticket like that was different from a tenant maintenance request. And sales had just closed two more logistics deals shaped the same way.

The decision traced back to a meeting from Squire's first month, when someone asked whether pricing should account for ticket size. The answer at the time was no, because every ticket looked about the same, and building a metering system for a difference that didn't exist yet felt like solving a problem nobody had. That was true, for exactly as long as it stayed true.

Three real options, laid out the way Danilo actually weighed them, not the way a slide deck would tidy them up afterward.

Danilo laid out three ways to fix it. Meter every ticket for every customer, which would cover Anthaven's cost but put a price tag on the routine tickets that make up ninety four percent of Squire's volume, tickets that had never cost anyone a real bill. Leave the flat price alone and hope the next logistics deal wasn't shaped the same way, which wasn't really a fix, it was a bet against something already proven to happen twice. Or charge for the ticket, not the account: give every seat an allowance of five hundred heavy tickets a month, tickets over four thousand tokens of context, built into the flat price, and bill twelve cents for anything past that.

One option reads every ticket the same blunt way. The other weighs each one on its own before it ever touches a price.

He picked the third one. Not because it was the cleverest option on the page, but because it was the only one that fixed Anthaven's number without ever touching Coombewick's invoice.

The mechanism Danilo actually shipped. A token count decides the fork, not a customer's name or industry.

Run the same account back through the new price. Anthaven still sends thirty thousand tickets a month, twenty four thousand of them heavy. The first twenty thousand heavy tickets are free, built into the forty seats' flat price. The other four thousand bill at twelve cents each, four hundred eighty dollars. Compute cost hasn't changed, still four thousand two hundred dollars. Revenue has: three thousand nine sixty plus four eighty is four thousand four forty. Thrushgate goes from losing two hundred forty dollars a month on Anthaven to making two hundred forty.

One design let a customer's real cost hide inside an average until finance went looking for it. The other bills a ticket for what it actually costs, the moment it happens.

What I'd tell myself, back in that first month meeting: "every ticket looks the same" was never a fact about tickets. It was a fact about the two customers we happened to have signed so far.

PICK, spoken with the invoice still open

Not a lecture on tradeoffs in general. This is a live pricing call on one real account, and PICK is what stops "there's a tradeoff here" from quietly standing in for an actual decision.

Three things worth saying directly, since the real judgment sits here. The alternative Danilo actually turned down was metering every ticket for every customer, which would have fixed Anthaven's number but would also have put a price tag on the routine tickets that make up most of Squire's volume, tickets that had never cost anyone a real bill before. It lost because most customers pay for Squire precisely because the bill never surprises them, and metering everyone trades that away to fix a problem only a slice of accounts causes. The AI specific risk worth naming here is what happens later, if Thrushgate ever tries to shrink Anthaven's real cost instead of just billing for it, say by having a small model summarize the shipment log before Squire ever reads it. That kind of shortcut can quietly drop the one line that actually explains the shipment exception, and Squire would draft a confident, wrong reply with no warning at all. The guardrail is a separate eval built only from heavy, log carrying tickets, checked every time anyone touches how Squire reads a long one, because Squire's normal accuracy test is mostly short tickets and would never catch a mistake that only shows up on a long one. The trade Thrushgate is actually accepting: any real fix to Anthaven's underlying cost, not just its bill, means an extra step before the draft and more engineering time, in exchange for a lower bill later. Cheaper now and slower to fix would have been the easier choice. This one is neither, on purpose.

And if you want to be sure it really works, try it somewhere else

Same four letters, a different clinic, and this time the lever isn't a shipment log. It's how much case history a vet has to say out loud before a draft can even start.

Marrowline is Grovenhall Veterinary Systems' tool. A vet dictates notes during and after an exam, and Marrowline drafts the clinical record and discharge summary for the vet to check and sign. Tavita Aubuchon owns its pricing.

Most clinics see a routine appointment: a five minute dictation, a short record. Sable Ridge Specialty Referral Hospital takes the hard cases other clinics send over, and every dictation there starts with the vet reciting the whole prior case history out loud, sometimes twenty minutes of talking, before getting to today's exam. Marrowline has to listen to all of it to draft a record that doesn't miss something from the referral. Same shape as Anthaven's log: a routine dictation costs Grovenhall about two cents to turn into a record. A Sable Ridge dictation costs about twenty two cents, over ten times as much, because Marrowline processes roughly ten times the spoken content before it drafts a word.

Same mechanism, different meter. Minutes of spoken history instead of tokens in an attached file.

Same rank, different lever: the fix is still charge for the dictation, not the clinic, but the line isn't a token count on an attached file, it's minutes of spoken audio processed per visit. Past eighteen minutes of dictation, a visit counts as heavy. Sable Ridge still gets an allowance built into its flat price, and only the referral cases that run long past it bill extra.

Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to the pick: charge the ticket that's actually expensive, not the account, with a free allowance so nobody normal ever notices.
Cost: there's no budget this quarter to build both a usage metering pipeline and cut Anthaven's actual compute cost. Build the metering first. A customer losing money every month can't wait for an engineering project that might take a year.
The model got better, for real: say Squire's newest model reads long logs for less, not more, cutting the real multiplier from ten times to three times. The overage line and the allowance should both move, but the shape of the fix doesn't change. You'd still want a way to charge differently for a ticket that costs differently, you'd just set the numbers lower.

Where people run it wrong.
They let "it's just one customer" decide the timeline, and don't notice sales is closing three more shaped the same way.
They meter everyone to be fair, and lose the flat, predictable bill that most customers were actually paying for.
They fix the price and stop there, and never check whether the underlying cost itself could come down without hurting quality.

How to use it live. Say the real question out loud before naming a fix: "is this one strange account, or is it a shape my sales pipeline keeps producing." That buys a beat to actually rank the fix instead of reacting to the one invoice in front of you.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0