How value gets priced, shared and moved across a company

A single pattern connects the day's announcements: the software a company buys is increasingly judged not by what one person can do with it alone, but by how value moves across a whole team and by how that value is charged for. Two of today's most useful reads are about pricing, one is about AI that works as a group rather than a set of individuals, and the rest are about the quiet plumbing that lets tools from different vendors meet in the same place.

What your bill says about what you are buying

Most pricing arguments are really arguments about what a product is for. A usage meter that counts raw units of computation tells the customer how the supplier's machine works. A price tied to an outcome tells the customer what they are getting. These are not the same thing, and the gap between them is where a lot of buyer frustration lives.

Stripe published a candid piece today about trying to remove token-based billing and deciding to keep it anyway [1]. The distinction it draws is worth carrying into any tool evaluation: token billing is useful plumbing between a vendor and its own costs, but it is usually a poor thing to put on a customer's invoice. The argument is that an invoice should describe the value a product delivers, not itemise what it cost the supplier to produce. For a business choosing tools, that is a practical test you can apply to any pricing page. If the meter counts something you cannot plan around — tokens, compute seconds, opaque credits — you are being asked to carry the supplier's cost variability yourself. If the price attaches to a unit of work you recognise, such as a closed deal, a published site, or a seat that does real work, you can forecast it.

This matters more as AI features spread, because AI costs are lumpy and hard to predict. We have written before about how a pricing page can quietly shift risk onto the buyer in how pricing pages fail, and about reading a plan for what it actually sells rather than what it advertises in what a subscription plan is really selling. Stripe's note is a clear restatement of the same idea from the supplier's side of the table.

AI that works as a team, not as a person

The first wave of workplace AI was built around the individual. Each person got an assistant, and the gains were counted one desk at a time. Salesforce's piece today argues for a different frame, which it calls multiplayer AI: the shift from making individuals smarter to making a company smarter [2]. The opening premise is simple — work is a team sport — and the point it builds on is that something changes when a group focuses on the same problem at the same time rather than each person working alone.

For a buyer, this reframes a question you should already be asking. A tool that makes one person faster can still leave the team no better off if the faster person's output just piles up in someone else's queue. The useful version of AI at work is the one that coordinates — that shares context, hands work between people and systems, and keeps everyone looking at the same facts. That is harder to demo and harder to sell than a single clever assistant, but it is the version that changes a company's results rather than one person's afternoon. When you evaluate an AI feature, it is worth asking where the shared state lives and who else sees it, not only how good the single-user answer is. The companion question — which decisions you should let it make at all — is one we covered in what AI should and should not do in your business.

When tools from rival vendors have to meet

No company runs on one vendor's stack. The meeting that matters often has people from two organisations using two different platforms, and historically that has meant someone dialling in awkwardly or giving up on the room's hardware altogether. Google Workspace announced today that device-level interoperability between Google Meet and Microsoft Teams on Android (AOSP) conferencing devices is now generally available, having previously been in preview [3]. In plain terms, a meeting-room device built for one platform can join meetings hosted on the other.

The lesson for buyers is not about these two products specifically. It is about where lock-in actually bites. A platform that only works cleanly when everyone in the room has chosen the same vendor imposes a hidden tax every time you deal with an outside party — a client, a supplier, a partner. Interoperability at the device and protocol level removes a small but recurring friction, and it is a feature worth checking for before you standardise on anything that other people will have to join. We have written about the broader version of this problem — tools that will not talk to each other and the cost of that silence — in why your tools do not talk to each other.

Shorter contracts in the age of AI

Buying posture is part of tool selection, not just the tool itself. The usual sales instinct is to push customers toward longer commitments, because a multi-year deal looks like certainty on a supplier's books. SaaStr pushed back on that today with advice aimed mostly at vendors but useful to read as a buyer: for most companies, stop pushing for multi-year contracts in the age of AI [4].

The reasoning behind that line is about how fast the ground is moving. When the capability of tools is changing quickly, a long lock-in is a bet that today's choice will still be the right one in two or three years — and that bet is getting harder to win. For a buyer, this cuts in your favour. It is a reminder that the premium a supplier offers for a multi-year signature is compensation for giving up your option to switch, and in a fast-moving category that option has real value. Shorter terms cost a little more per month and keep you free to move when something better appears. The discount for committing is only worth taking when you are confident the tool will still fit your needs at the end of the term.

Making the secure option the easy one

Security features fail quietly when they are hard to turn on. An admin who has to work through a long, fragile setup to enable encryption will often leave it for later, and later rarely comes. Google Workspace addressed exactly that friction today, introducing an option that can make the initial setup of Client-side encryption significantly easier and faster for administrators [5].

The general principle is more important than the specific feature. The security posture a company actually ends up with is rarely the strongest option available; it is the strongest option that was easy enough to switch on. When you evaluate a tool, it is worth looking not only at whether a protection exists but at how much work it takes to enable and keep running. A protection that is off by default and awkward to configure protects very few people in practice. Lowering the setup cost of the secure path is one of the more honest things a vendor can do, because it narrows the gap between what is possible and what most customers will really have.

Taken together, today's news rewards the same habit on every front: look past the demo to how value is counted, shared, carried between systems, committed to, and protected. For yesterday's items, see the previous briefing.