An internal retrospective that hit a nerve with every office worker

In early June 2026, a long essay titled Inside DingTalk (《置身钉内》) started circulating on external platforms. It's an insider retrospective on the DingTalk ONE project — according to multiple media reports, written by an AI product manager who worked on ONE.

It went viral fast, treated by many as a case study of "how AI office products actually land inside enterprises." But the discussion also picked up a lot of embellishment along the way: claims like "a pressure index exceeding the liberation index by 1.8x triggered collective resistance," "7-day retention fell below single digits," "messages auto-ranked by seniority weight." None of these actually appear in the circulating original — they read more like packaging added by second-hand reposters.

So let's draw the verification boundary up front, to avoid spreading the same noise. This essay is based on the circulating retrospective and media reports, including 36Kr's English summary, Pandaily's coverage, and public DingTalk 8.0 launch reporting such as Sina Finance. Non-official materials are treated as media accounts, not primary DingTalk statements.

What can be confirmed: multiple media reports describe Inside DingTalk as a 70,000+ character retrospective on ONE; DingTalk 8.0 was launched on August 25, 2025; claims about ONE's peak DAU and later contraction come from media reporting.
What is only a media attribution: the author's real identity comes from press reports and reposts, not an official byline.
What should not be cited as fact: the "pressure index," "single-digit retention," "automated monitoring reports" — none of these land in the original text; they're conceptual summaries from commentators.

Filter out that noise, and the core that remains is actually clearer — and worth a hard look from anyone building ToB products or managing a team.

ONE started from the right place

To be fair: ONE's direction wasn't absurd.

What it set out to build was an "AI-era work feed" — taking information scattered across group chats, to-dos, meetings, docs, and spreadsheets, and having AI rank and summarize it into cards, so you could process work the way you scroll a feed. A shift from "people chasing tasks" to "tasks finding people."

Anyone who has drowned in dozens of work groups and hundreds of unread messages will admit that goal hits a real pain point. AI entering the real workflow and collapsing noise into an orderly next step — that part is right.

The question was never "should AI enter the workflow." It's this: once it's in, whose side does it speak for?

An organization never contains just one kind of person

This is the sharpest cut in the whole essay. The retrospective keeps returning to three "misalignments" — and the tragedy of office software usually hides inside them:

Boss vs. employee: the boss initiates, approves, and chases tasks; the employee receives, executes, and fills in the forms.
Sender vs. receiver: the sender wants certainty that you got it and will act; the receiver wants to handle it with preparation and at their own pace.
Payer vs. user: the person who pays for the software and the person ruled by it every day are often not the same person.

DingTalk's product DNA, from the early days, was better at standing on the sender's side — it perfected reach, read receipts, DING pings, attendance, and approvals. These features serve the sender's certainty, and the cost of that certainty lands on the receiver.

ONE's external story was "help employees do less," but as long as the underlying value scale isn't recalibrated, the product keeps tilting — unconsciously — toward the sender and toward "managerial certainty." A feature designed to "make managers feel safe" will almost inevitably "make the managed feel unsafe" — because safety and unease are two ends of the same transaction.

"Read" is not a UI state. It's a responsibility state.

If the essay has one emotional anchor, it's the detail of the "read card."

The retrospective notes that ONE's IM cards triggered a read status the moment you scrolled past them. The team internally debated softer options — "viewing the card doesn't count as read," "only opening the detail page counts as read" — but those didn't ship, with the reasoning ultimately pointing back to the sender's interest and DingTalk's foundational logic.

Why does this sting? Because it turns a seemingly neutral interaction into a premature transfer of responsibility.

The same word, "read": to the sender it's certainty — "good, they saw it, it's on them now." To the receiver it's a countdown — "I haven't figured out how to respond, but the clock is already ticking."

Before you've even decided whether you can or should handle it, the system has announced to the world on your behalf: you saw it, so you're responsible. "Read" thus shifts from a UI state into a responsibility state. That one-word gap is exactly the line between "assistant" and "overseer."

Enterprise software is never a neutral tool

This is the real, underlying lesson of the ONE story — and it reaches far beyond DingTalk:

No enterprise software is neutral. It redistributes four things — visibility, priority, responsibility, and the right to explain.

Whose work the system sees, and whose disappears into the background;
Whose message the AI ranks first, and whose sinks to the bottom;
Which person the states "read," "overdue," "not updated" push responsibility onto;
When the data and facts are laid out, who still gets to explain, and who is simply labeled by the conclusion.

A tool's choices about what to illuminate, in what order, and who bears the consequences of being illuminated — none of these are technically neutral decisions. They're expressions of a value stance.

Adding AI only makes this redistribution faster, finer, and harder to argue with. AI won't automatically side with the weaker party; on the contrary, it defaults to amplifying whatever bias the product already had. If the product already leans toward the sender, AI only deepens that lean.

From DingTalk, back to what I think about every day in sales management

I work in sales enablement, so this isn't a spectator sport for me.

Sales management has the exact same tension: managers do need process visibility — who's following up on which customer, where it's stuck, why a deal won't move. That need is entirely legitimate. But if a system serves only that managerial anxiety, the outcome is predictable:

Frontline reps treat it as pure burden. They start backfilling records — fudging a few fields after the fact to clear the checkbox; gaming fields — entering content that looks good but means nothing; and ultimately avoiding the system — using it as little as possible, keeping their real customer judgment in their own heads, their chat apps, their personal notes.

So the system you paid a fortune for ends up collecting a pile of data filled in to satisfy inspection. Managers stare at a screen full of green "updated" lights, drifting further and further from the actual sales floor. That's how the "overseer logic" backfires — what it squeezes out isn't truth, but performance.

Same data. Two completely different product philosophies.

The key to breaking the cycle hides in a question of order: do you let the frontline gain first and then let managers see — or do you satisfy managerial visibility first and make the frontline pay the cost?

The same body of sales data can grow into two entirely different products:

A surveillance-first one: the dashboard highlights "who didn't update," reminders become nagging, and AI watches everyone's activity frequency on the boss's behalf.
An enablement-first one: every record a rep writes earns back a next-step suggestion, customer memory, reusable quotes and follow-up scripts; the dashboard shows not just "who's slacking" but "whose repetitive work the system saved, and which deals it moved forward."

Both run on the same underlying data. The only difference is: whom that data serves first.

This is exactly where KnowSales keeps wrestling with itself in product design. We've set ourselves a few principles that aren't easy to walk, but that we have to hold:

Let the frontline rep gain first, then let managers see. The order cannot be reversed.
Every field we ask a rep to fill must map to a return the rep can feel — a suggestion, a piece of customer memory, a reused script — not just being inspected.
AI reminders default to suggestions, not commands. Give the frontline the power to "explain, defer, dismiss, and correct," instead of a red countdown that keeps closing in.
The management dashboard tracks the quality of deal progress, not just the frequency of employee activity. Watch "where the deal got to," not just "who didn't log in today."
Customer knowledge is captured to win and reuse, not to monitor. A rep should never be turned into a passive reporting machine.

These principles are simple to state and hard to keep — every one of them fights the gravity of "surveillance is easier to build, and managers are easier to sell." But Inside DingTalk is precisely the reminder that once you stop resisting that gravity, even the best AI assistant eventually grows into an overseer.

A good product knows where to shine a light, and where to leave room

Back to the original question: why do AI office tools turn from assistant into overseer?

Not because AI is evil, and not because product people are bad. It's because — when a product defaults to serving the certainty of the payer, the sender, the manager, while making the user, the receiver, the frontline bear the cost of that certainty, it's already on the road to becoming an overseer, no matter how lovely the slogan.

A good AI office product doesn't illuminate every gray area. Quite the opposite — it knows where to shine a light and where to leave people room. Room to hesitate, room for their own pace, room for "I haven't figured out how to respond yet."

For work as dependent on rapport, judgment, and tact as sales, this matters most of all. Quantifying every gray zone of customer follow-up into red and green lights looks "comprehensive," but it squeezes the most valuable judgment right out of the system.

We build KnowSales with this question always in front of us: is the AI helping the boss watch people, or helping the rep win deals? Those two answers decide whether the same technology ends up an assistant — or an overseer.

The system your team is using right now — is it helping the frontline win, or helping managers watch?

The answer usually isn't written in the product brochure. It hides in whether the frontline chooses to open it on their own.