Delivering a client's custom platform: sales and engineering in one workspace

The most expensive part of a custom platform project is not development — it is rework.

Three weeks into the Nova project, the approval flow engineering built was not what the client wanted. Looking back, the requirement had warped through three rounds of relay: account manager Chen Xi's meeting notes said "approvals should be flexible," pre-sales consultant Wu Tong's notes said "support custom nodes," and the schedule spreadsheet said "approval flow (see above)." Nobody was wrong, and nobody agreed — engineering had received three contradictory "requirements."

The problem was not carelessness; it was that definitions had no single home. Once the sales team and the product engineering team moved into one workspace, client requirements became issues with acceptance criteria: one source of truth, no more relay — because relay was no longer needed.

---

Project profile

Both agents run on the local runtime inside the company network: client code and API docs never leave the intranet, and each agent's environment variables are visible only to its owner. On client work, that is the baseline.

---

How far a requirement used to travel

The old path: the client explains requirements on a voice call → Chen Xi writes meeting minutes → Wu Tong translates them into technical notes and emails them → engineering copies the email into the schedule. Four steps, three losses of meaning.

Nova's first requirement was lost exactly this way. The client's actual words: "after the workshop manager approves, equipment maintenance needs to countersign; if the countersign fails, send it back to the requester." The minutes kept "approvals should be flexible." Wu Tong's notes kept "support custom nodes." The schedule kept "approval flow (see above)." Two weeks later engineering delivered a beautiful visual approval flow — with no concept of countersigning. The client asked "where are the countersigns we talked about," and the team asked "when did anyone mention countersigns."

Two weeks of rework. No single step was at fault: every relay compresses, and compression loses information. What was missing was a carrier that does not require relaying.

---

Now: requirements have exactly one form

In the new process, a requirement has one form — the issue. Chen Xi pastes the client's original words into the #client-nova-custom-platform channel, converts them into an issue in one click, writes the acceptance criteria into the description, and attaches the client email and kickoff minutes as linked references on the same issue.

OPE-201 was this project's first issue — as written:

OPE-201In Progress

Nova custom platform

Nova custom platform: requirements breakdown & schedule

Assignee · Pre-sales agent

Client needs the proposal and schedule by Friday. Original wording in the linked email (Sep 23).

Acceptance criteria

• MES data interoperability: tickets carry equipment work-order numbers; two-way sync latency ≤ 5 minutes
• Visual approval flow configuration: business admins can build three-level approvals without engineering help
• Proposal and milestone schedule delivered to the client by Friday 18:00

References：Client email Sep 23 · kickoff minutes

"Approvals should be flexible" became three standards that can each be judged true or false. Engineering builds against them, sales reviews against them, the client signs against them — three parties, one document.

---

The Pre-sales agent: one big requirement in, one schedule out

The moment the issue was created, Chen Xi @-mentioned the Pre-sales agent in the channel. It read Nova's MES open API docs, checked auth and field mappings, wrote feasibility conclusions and risks into a pre-study report, and split the big requirement into dependency-ordered issues under the "Nova custom platform" project:

client-nova-custom-platform

Nova Inc. custom platform delivery

9

• CX
  Chen Xi10:15

  @Pre-sales agent Client needs MES integration and configurable approval flows. Proposal and timeline due Friday — turning this into an issue now.

Type a message, supports Markdown, images and @mentions

The breakdown came out the same day — five issues, four phases of work:

The pre-study report and milestone plan landed back on OPE-201, with @Zhou Hang asked to confirm backend capacity. The old path took three days for this schedule (write a doc, send an email, book a review); now it closed the same day — and Chen Xi sent the schedule to the client that same day. For the first time, sales and engineering looked at the same plan and both said "good."

---

Milestones, dependencies, and changes

The five issues form a dependency graph in the project: API integration → core features → approval flow extension → joint testing → acceptance. Downstream work stays blocked until upstream passes review — this gate makes slippage visible in week one, not week six.

The real test arrived in week 3. The client said: "Approval flows need countersigning; a failed countersign returns to the requester." In the old world, that sentence would travel through sales relay, pre-sales assessment, and engineering scheduling, and end in rework.

This time, the sentence happened in a channel and became issue OPE-209 (client's original words, scope of impact, and acceptance criteria included), inserted into the dependency graph between OPE-207 and OPE-212. Core features passed review first, the countersign work unblocked, and the joint-testing date visibly slid one week out in the project view.

Nova custom platform

Version 2

Active

3 nodes · 0 ready · 1 done · 1 blocked

OPE-205

MES integration

Done

OPE-207

Core ticketing features

In review

Wait for issue completion

OPE-209

Countersign approval flows

Blocked

Candidate issues

Unpublished candidate · OPE-212 Joint testing & acceptance

Chen Xi took that graph to the client to negotiate priority — not "we'll try our best," but "add countersigning and delivery moves from week 6 to week 7; or drop the permissions matrix and keep week 6. Your choice." The client chose the delay. The whole decision is on the record: who asked, what it affected, who decided. Nobody had to "take the blame," because there was nothing to blame.

Engineering benefited equally: Zhou Hang never has to answer "when will that API be ready" in standup — who is blocked by whom, at which step, is visible in the project view in real time, and the answer lives on the issue.

---

Two teams, two views, one dataset

One project, two sets of concerns. The key to frictionless collaboration is not forcing both teams to read the same pile of information — it is letting each take what it needs from the same data.

The view is the alignment. The weekly project meeting shrank to one agenda item: walk the dependency graph for risks.

---

Review gates: every deliverable carries its evidence

At the end of each milestone, the QA agent works through the acceptance checklist and posts results back to the issue. M2 (core ticketing features) looked like this:

The last item failed, so M2 was not complete, project progress stayed un-green, and the joint-testing node stayed blocked. The QA agent opened the follow-up issue itself and assigned it to frontend engineer Li. Everything delivered to the client has a source — at the acceptance meeting there is no "should be fine," only evidence one click away.

---

The client report is a document that already exists

Every Friday, the Pre-sales agent compiles the week's progress and posts it to the project issue, with a reminder delivered to DingTalk; Chen Xi reviews it and forwards it to the client. The report looks like this:

Nova custom platform · Week 4 progress Completed: MES integration (OPE-205, accepted); core ticketing features (OPE-207, under review, 4/5 passed) In progress: approval flow countersign extension (OPE-209, on the revised plan) Milestones: delivery date holds at the revised plan, acceptance in week 7 Risks: none blocked

When the client asks "how are things going," the answer is always a document that already exists — not a hastily organized act of remembering. Chen Xi's only job: check for internal details the client should not see, then forward.

---

Reminders land in DingTalk and Feishu

Each team keeps its own daily habitat: sales talks to clients in DingTalk, engineering runs daily updates in Feishu.

Review requests, schedule changes, @-mentions — each reminder lands on its recipient's own turf. At the client site, Chen Xi's DingTalk pops "OPE-201 pre-study report is waiting for review" while at the client site; handling it back at the desk is fine. Historical proposals that already live in Feishu are browsed read-only in the workspace through the connector, with no export-and-re-upload.

Definitions worth keeping — the Client System Integration skill and the Acceptance Checklist Template — are written into skills, so they take effect automatically at every pre-study and acceptance. When this project ends, the next custom project starts from those skills, not from a fresh email.

---

What changed

One source of truth. Requirements have exactly one form — the issue — with acceptance criteria written in the original words; "see above" disappeared from the schedule.

Same-day closure. Requirements to schedule went from 3 days to same-day; the client saw the milestone plan the day it was made.

Traceable changes. The countersign change went from one sentence to a decision recorded on the dependency graph — who asked, what it affected, who decided, all on the record.

Evidence-backed acceptance. Four milestones, four acceptance records; every pass has measured data or a recording. Rework during joint testing dropped from the old 3–4 items to 1 — and surfaced in week 2 instead of week 6.

---

Feature map: a cheat sheet for the presenter

---

Replicate this in your team

Start with the next custom requirement: paste the client's original words into a channel, turn them into an issue with acceptance criteria, and let the pre-sales agent produce the first breakdown report. The moment sales and engineering say "good" to the same schedule, and the first change gets negotiated on the spot against the dependency graph — this way of working is established.

---

Further reading

• Issues
• Projects
• Agents
• Skills