Executive summary: redesign responsibilities before adding tools
FDE transformation changes how work is owned, executed and checked. One accountable owner coordinates responsibilities previously distributed across acquisition, content, sales operations, delivery coordination and routine reporting. AI workflows carry repeatable execution. A customized Feishu CLI checks agreed rules, gathers evidence and escalates exceptions. Locally deployed business systems hold customer and operational records.
The structural change has three parts: one owner coordinates multiple departmental responsibilities; routine acceptance becomes an executable workflow; and local systems progressively take over agreed CRM functions. This is a target operating model for a suitable business scope, rather than a claim that every company can operate with one employee or that every CRM has already been replaced.
The design should be judged by the amount of accepted work one person can oversee, how quickly exceptions become visible, and what it costs to sustain the operation.
1. One owner coordinates the department; workflows carry execution
A traditional process often moves between a salesperson, a coordinator, a reviewer and a manager before the customer receives an answer. Each person may copy context, update a separate system and ask the next person for progress. The work crosses job boundaries even when many steps follow stable rules.
In the target model, the owner sets goals, priorities, review standards and exception thresholds. Workflows prepare content, structure leads, draft quotations, route tasks and update records. The owner manages a connected queue of business outcomes instead of reconstructing progress through a series of individual reports.
One-person coordination requires a deliberately chosen scope. Routine work must be documented, inputs must be available, and execution must be observable. Specialized judgment remains with the relevant professional, while the accountable owner decides when it is needed. Delegation to software does not remove responsibility for business outcomes.
| Responsibility | Traditional arrangement | Target arrangement | Human accountability |
|---|---|---|---|
| Goals and priorities | Separate departmental plans and reporting | One accountable owner and a shared work queue | Approve objectives and trade-offs |
| Repeatable execution | Staff copy, prepare, route and update | Rules and AI workflows execute defined steps | Maintain standards and resolve ambiguity |
| Routine acceptance | A dedicated person checks files and chases progress | Feishu CLI checks rules and records evidence | Approve business results and exceptions |
| Customer records | Per-seat CRM plus spreadsheets and chat | Local records, event history and integrations | Control access, data quality and migration |
2. The acceptance role becomes a Feishu CLI workflow
The proposed organization no longer needs a separate role devoted exclusively to checking whether expected files arrived, comparing fields, reminding colleagues and assembling reports. Those responsibilities become an explicit acceptance workflow.
Here, Feishu CLI means an enterprise-specific command-line workflow entry point built around authorized Feishu integrations. The automation runs in the business's execution environment. Feishu provides connected messages, events or records; acceptance rules and business logic are configured for the project.
The workflow checks delivery completeness, required fields, agreed counts or formats, source links and other measurable rules. It records the result against the task, notifies the owner of missing evidence, issues reminders and escalates unresolved exceptions. Subjective quality, unclear evidence and consequential business decisions return to the appropriate person.
An illustrative acceptance event
A content task requests platform-specific drafts, source material and an approval record. Completion creates a task event. The CLI checks the agreed deliverable list and evidence links, then records a pass, a request for correction or a request for human review.
The event record should contain the task ID, delivery version, applicable rule version, evidence references, check results, owner and next action. If a correction is submitted, the system checks the new version while retaining the earlier record. This is an illustrative process, not a report of measured project performance.
The organizational benefit is continuous visibility: the owner sees unresolved exceptions and approval requests directly. Routine status reconstruction no longer consumes a separate person's day.
3. Local systems progressively take over CRM functions
The starting point is a map of customer-management responsibilities. Lead capture, deduplication, customer records, stage assessment, follow-up tasks, complaint alerts and activity summaries can be implemented as a connected local system when they fit the business's needs.
A local deployment makes these functions adaptable to the organization's own fields and processes. It can connect authorized mail, forms, Feishu or DingTalk tasks and existing ERP through supported interfaces. The business defines the record structure, event history, manual corrections and further development.
Replacement follows verified scope. Keep the existing CRM available while importing records, comparing field mappings and running the new workflow alongside it. Retire only the modules or seats whose required functions, permissions and history have been validated. Products with additional sales, finance or industry-specific capabilities need their own assessment.
The important change is that customer data, tasks and evidence follow the business record across tools. Re-entering the same update in several disconnected places becomes a design problem to remove.
4. A shared business record connects execution and management
Each lead, project or order needs a stable identity. Its source, owner, status, delivery evidence, acceptance result and next action should remain connected throughout the process. Events update the record and trigger the relevant checks or reminders.
This gives the organization three views of the same work: an execution queue for workflows, an exception queue for people and an outcome view for the owner. The views answer different questions without requiring separate manual reports.
The operating rules should specify who can change a record, what evidence qualifies as completion, when a task requires review and how a failed action is retried. Rule changes need a recorded version so a later reviewer can understand why a task passed or failed.
5. Measure cost and productivity over the complete lifecycle
The first one to three months usually include process mapping, integration, sample testing and training. An experienced service team may show faster early execution. The FDE model aims to make its longer-term value visible over months six to twelve through reusable execution and greater accepted output per employee.
Compare total operating cost at equivalent volume and quality, including implementation, subscriptions, models, infrastructure, maintenance and human review. Subscription savings alone do not describe total savings. Capacity released from repetitive work is useful only if the business can put it to productive use.
Previously supplied business reference inputs include ¥200 per CRM seat per month, lead-recognition accuracy above 85%, and a 50%–80% reduction in comparable subscriptions. These are reference parameters to validate for the actual project, not universal vendor prices or guaranteed performance. For example, 20 seats at ¥200 per month produce ¥48,000 in annual subscriptions; replacing a subset of that spend still requires a separate local-system cost calculation.
6. Implement in stages, beginning with one complete workflow
- Baseline: select one business process, assign its owner, record current costs, task time, rework and response delays, and define acceptable quality.
- Pilot: connect real inputs and a small set of execution steps. Run the Feishu CLI checks in observation mode and compare their results with human review.
- Transition: enable agreed reminders and routing, migrate the validated customer records and preserve manual correction and exception paths.
- Scale: expand volume or responsibilities only after the pilot meets its criteria. Review the rules, integration maintenance and owner workload as the process grows.
The scope grows when the organization has evidence that the workflow works reliably. A wider automation footprint should reduce coordination burden rather than create an invisible maintenance job for the owner.
7. Acceptance criteria should describe the organization, not just the software
| Measure | What to compare | Evidence |
|---|---|---|
| Accepted output per employee | Completed work at the same quality standard | Accepted task records and staffed hours |
| Founder or owner workload | Time spent coordinating routine work | Time samples and exception volume |
| Acceptance latency | Delivery-to-check and delivery-to-approval time | Task and check timestamps |
| Rework and missed checks | Corrections, false passes and false alarms | Human-reviewed samples and history |
| Customer-data quality | Field completeness, duplication and recognition errors | Validated samples and correction records |
| Complaint response | Time from a detectable signal to an assigned action | Event, notification and action records |
| Total cost | Comparable volume and scope over time | Subscription, infrastructure, model and maintenance costs |
A successful implementation leaves the owner able to understand what happened, why the workflow accepted it, and what needs a decision. The long-term outcome is a smaller coordination burden and a reusable operating capability within the business.
8. What remains with people
Goals, material commitments, disputed quality, customer relationships and final business approval require accountable owners. New rules and exceptional situations require judgment. These responsibilities should be visible in the organization model rather than left to an unspecified person watching the automation.
The proposed structure is therefore practical: one owner coordinates the chosen scope, workflows execute, the Feishu CLI checks and escalates, and local systems retain the business record. The implementation starts with one process and earns its broader scope through measured acceptance.
9. Technical foundations and scope
Feishu provides event and messaging integrations; the business must implement its own acceptance logic. The sources below support these implementation paths. The organizational model is FDE's proposed design, rather than an established industry-wide outcome.
- Feishu bot overview: application bots connect messages and interactions for notification and human confirmation.
- Feishu general event trigger: events can trigger downstream business logic, messages and records.
- Frappe CRM installation documentation: self-hosting is one available CRM deployment path; actual scope and costs depend on implementation.
Start with the work your team does today.
Bring your roles, one real delivery and acceptance criteria to identify which responsibilities can become workflows.
Plan an onsite diagnosis ↗