Community Discussion · Company Watch

Using WorkBuddy to Build a Lightweight Metrics Ledger and Clarify GMV Definitions

I am DapengI am DapengSep 112026/09/11 55 views

Recently I reflected on talking too much, but I couldn't help myself during Monday's retrospective meeting. Operations said East China GMV rose 15%, Finance said it didn't rise, and BI came up with a third number. Before the meeting adjourned, the boss asked just one thing: which one is correct? No one could answer. Behind the same term hang three sets of rules, and those calculating it each have their own metrics.

I scrolled past news of NetEase Zhiqui Shufan releasing Data Intelligence Platform V10.0, which mentioned that the biggest dilemma for enterprises is multiple answers to the same question.

Shufan connects data ingestion, governance, analysis, and intelligent decision-making, with the core being credible metrics and traceable data.

I agree with this judgment. But our group doesn't have that much budget, nor do we have a dedicated data platform. I've been using WorkBuddy for about a month; automatic weekly reports have been running. Later, I treated this metric argument as a requirement and threw it directly to WorkBuddy. I thought the requirement was simple: first, break down the algorithms of several reports into a runnable table.

Listen to me, don't complicate the operation. Open WorkBuddy, enter Workspace, click File Organization, create a new task, and name it East China GMV Metric Ledger. Then drag the materials in: Finance weekly report Excel, Operations daily report, Tencent Meeting transcripts, paragraphs defining metrics in the PRD, and two email attachments. I've actually only used Excel for 7 days and am not familiar with pivot tables yet, but WorkBuddy can read files first, extracting metric names, values, and notes that appear inside. This step doesn't require you to hand-write SQL or build a data warehouse; it's just feeding office documents to it.

Next, click Extract Structure, select Table, and write the Prompt, i.e., instructions for the AI. Don't be greedy here. The first time I wrote it too loosely, resulting in it mixing "Effective GMV," "Payment GMV," and "Confirmed Revenue" into a mess. Later I fixed the fields: Metric Name, Business Definition, Statistical Period, Data Source, Owner, Update Frequency, Conflict Flag, Version Date, Approval Status, Notes. Once the fields were fixed, WorkBuddy's output became much more stable. It extracts each metric from the document into a row, marking those it can't extract in red for me to supplement.

I let it run an incremental update once, taking about ten-plus minutes to produce results. After it comes out, don't trust it immediately. I clicked Rule Configuration and added three checks: Metric Name cannot be duplicated, Data Source cannot be empty, and if "To Be Confirmed" or "Finance Prevails" appears in Notes, mark it red automatically. WorkBuddy turns these rules into periodic tasks. Then I clicked Export, selected CSV, and sent it to Finance. This step is important; what the tool generates is just a draft. Without someone signing off, it remains material for arguments.

Permissions must also be set in advance. In Collaboration, I divided members into three categories. Finance and Data colleagues get Edit rights, allowing them to change definitions; Operations and I only get Comment rights, able to raise questions only; the Boss gets Read Only, able to view published versions. The key is who can change things. Previously, our shared folder allowed anyone to modify, resulting in definitions being changed with no one knowing. Now I require all definition changes to go through Create Draft first. WorkBuddy automatically puts the change content, original version, and changer into a comparison view, and the metric owner clicks Approve before it enters the published table.

For daily maintenance, I set up a clumsy method. Every Friday at 4:30 PM, WorkBuddy automatically scans the weekly reports and meeting transcripts synced to WorkBuddy, running only increments and not overwriting manually confirmed fields.

If a new document contains a metric with the same name but a different definition, it generates a Conflict Alert at the top of the ledger and @mentions the owner. I handle this once a week, no need to monitor daily. This frequency suits our small team; higher frequency becomes disturbance.

I've also stepped into pitfalls. Initially, I wanted it to do intelligent analysis in one step, asking directly "Why did East China GMV drop?" The result was it pieced together a paragraph from meeting records and Excel that looked like a conclusion, but the source fields were incomplete. Later I learned my lesson: let it build the ledger first, then do attribution. For data intelligence, first let AI know where the answer should come from, then ask it for conclusions. I previously wrote an article about using WorkBuddy to organize prototype input tables, thinking fixed fields were enough. My thinking has changed slightly now: fields are just the first step. Without permissions, approvals, and incremental sync, the ledger will rot quickly.

So if you're also annoyed by arguing over the same metric tomorrow, don't rush to deploy a platform. You can start by building a small ten-field table in WorkBuddy, picking the most controversial ones like GMV, Conversion Rate, and Retention Rate, and running a metric ledger once. After running it, you'll find the time-saving part is that it forces you to write down "whose number do we listen to" in advance.

2 replies

?
Ctrl + Enter to reply
Shua Ti Zhong

Will this logic come up in interviews? Inconsistent data metrics are indeed tough to handle. Feels more hair-raising than grinding LeetCode.

Jiayi_Xu
Jiayi_XuSep 11

This approach is pretty practical, but unifying metrics is harder than building tables. I suggest locking down data source ownership first.