Feishu AI Operations Automation
Make meetings, reporting and project updates traceable.
Workflow diagram reconstructed from the project account.
The report is written. Why are we still asking everyone for updates?
Messages have been sent, reports written and meetings held. Yet finding out where a project stands still means asking people one by one. Information keeps accumulating while the next step and its owner remain unclear.
This Feishu AI operations project addressed that kind of problem for an enterprise client. We were a two-person team, implementing the work from June to August 2026 and delivering it in August. I handled client discovery, product design, and selected weekly-report and operations Agents. The client's identity and internal materials are not disclosed here.
I wanted meetings, reports and project updates to connect into records people could follow. Someone taking over should be able to see the current situation and what they need to do. A completed table may still leave them asking another round of questions.
Turn a business request into something the system can do
“Make reporting easier” needs more detail before it can become a feature. Who needs to know what, and when? Where does the material come from? Who handles an exception? Without those decisions, moving information faster still leaves the system without a clear recipient.
I broke meeting documentation, weekly reporting, and periodic project-update collection and checking into tasks, then worked through their inputs, outputs and writeback. The requirements and product-design work also covered OA workflows, Agent permissions, and drafting and checking contracts and qualification bid materials. Each case needed a place for the information, someone to confirm it, and a way to follow up.
I built some of the Agents and worked with the other team member on implementation and delivery. What follows focuses on the product decisions I owned.
Who confirms that a task is complete?
When a project status changes, who can make that change part of the official record? The answer determines when an Agent can write directly and when it needs to wait for someone.
Filling in missing material and changing a project plan can both involve updating a field, but they require different judgments. Marking something complete may also require its owner to check it. The technical operation can look the same while the business decisions differ.
I focused on distinguishing information organization, exception checking and decisions requiring an owner. Updates covered by established rules can follow those rules; judgments need to match actual responsibilities and permissions. A diagram can show that arrangement, but the business still has to assign the responsibility.
What else should we check after meetings get shorter?
Project records show that the client's weekly meeting fell from 60 minutes to 15 minutes, while core team members saved 30 minutes per person per week on reporting. The first figure measures meeting duration, not the time spent preparing minutes.
This shows a reduction in some coordination work. I also want to know whether information was missed, exceptions became easier to spot, and owners understood what to do next. My aim is to spend less meeting time repeating updates already in writing, leaving more time for disagreements, risks and decisions. Shorter meetings still need to do that work well.
We ultimately did not adopt Agent-based payroll
Payroll was technically feasible at first. In actual use, employees were frequently assigned temporarily to other cities. The applicable rules changed with those moves, and the hardcoded scripts needed repeated edits. The project ultimately did not adopt Agent-based payroll.
That decision made me pay more attention to how a solution would be used after delivery. Someone must explain the rules, maintain changes and check results. If those tasks remain and merely move elsewhere, automation may not be worthwhile. A demonstration can use a stable set of rules; the business cannot promise to stop changing.
For a similar request, I would start by working through a recent real exception: who needs to decide, who makes the change, and which results must be recalculated? Once that is clear, we can decide how much of the work the system should take on.