From a single meeting recording to a system that runs every morning at 8:00 AM — automatically.
A real frustration from a colleague's day-to-day work.
Installation records had to be manually filtered and sorted to calculate each technician's commission — time-consuming and error-prone.
PJ, Balakong, and Glenmarie each had data in different tables, each with slightly different rules.
The same licence plate could mean a new install or a warranty repair — two very different commission scenarios.
Zi.Li, who handled this every month, asked: "Can we automate this?"
Two people and one AI tool. No IT department, no dedicated tech team.
Domain expert. Provided business logic and verified the final output was correct.
Business person, zero coding background. Communicated requirements and drove the AI tools.
Structured the requirements doc, explored the data, wrote and debugged all code.
No programming knowledge required. Click any step to read more.
A face-to-face session to walk through the complete commission logic: which positions are included, hours per installation position, how MaxShield products are treated, how OT is determined.
Since there was a lot to cover, Lark Minutes was used to auto-record and transcribe the session.
The exported TXT file was uploaded to Claude, asking it to extract: business process, calculation rules, data sources, and edge cases (e.g. how to handle repair orders).
The AI-generated doc needed to go back to the business owner for verification: Is the process right? Can we find the data sources? Is anything missing?
Some back-and-forth clarified a few ambiguous points — e.g. that HeatShield and ClearShield are treated the same as standard products.
The requirements doc and Lark Base table links were given to Claude Code, with instructions to explore the data structure and write the calculation program.
The program didn't run correctly on the first try. Each issue surfaced through real data and had a clear business meaning behind it.
A daily scheduled task was configured. Every morning the system automatically syncs repair records → calculates commissions for all three stores → writes results to Lark Base.
Key design decision: The program only reads from existing tables. Results go to a newly created output table. Original data is never modified.
Before any code was written, the AI program needed permission to access Lark's data. Thomas set this up independently — no IT support needed.
Log in to the Lark Developer Platform, create a custom app. Similar to signing up for any account.
Enable "Read Bitable Data" and "Write Bitable Data" in the app's permission settings, then publish.
Open the target Bitable → "···" → "Add App." The app can now access that table.
Copy the App ID and App Secret, tell Claude Code: "Use these to access Lark."
Attendance tracking, inventory checks, order summaries, report generation — anything that needs automated access to Lark Bitable can reuse the same mechanism.
Where the data comes from, how it's processed, and where it ends up.
Runs at 8:00 AM daily · Read-only on existing data · Results written to new table
Each time, the business person noticed "something looks wrong." The AI traced the cause and fixed it. No technical knowledge needed on our end. Click to see what happened.
Looking through the first run results, Thomas noticed a few licence plates appeared more than once in the same month — likely return visits for repairs, not new installations.
"These entries look like repair orders — they shouldn't count toward commission."
Designed an automatic filtering mechanism. Cases it couldn't resolve were compiled into a review list for Zi.Li.
The program ran without errors, but the MaxShield (premium product) column showed RM 0 for every person — impossible, since there were confirmed MaxShield installations that month.
"MaxShield can't all be zero — we had MaxShield orders this month."
Investigated the actual data, found the root cause, corrected the program. Numbers came back correctly.
During testing, every run took 4–5 minutes to produce results. If the daily run always took that long — and needed to be re-run — that wasn't practical.
"Each run takes 5 minutes — that's not usable in practice."
Redesigned the data retrieval approach. Runtime dropped from 5 minutes to a few seconds.
Zi.Li compared the output against her manual calculations — every person's number was lower, not by a little. It felt like an entire category hadn't been included.
"Everyone's number is less than what I calculated — feels like a whole section is missing."
Found the missing base rate layer, added it back. Numbers matched the manual calculations.
No databases, no APIs, no code. Just enough business knowledge to say "something's off here" — then hand it back to the AI.
From "manually compiled once at month-end" to "real-time daily processing of new records."
No need to wait until month-end. Every day's work counts that day — real-time visibility into monthly accumulated commission. Clear and transparent.
Data refreshes daily. No manual compiling — check the whole team's installation volume and commission status whenever needed.
The most valuable lessons from this project. Click to expand.
Start Lark Minutes recording → export TXT → hand to Claude to structure into a doc. Three steps that save significant time and ensure nothing gets missed.
AI output is a draft, not a final answer. Every step — requirements doc, calculation logic, run output — needs the person who knows the business best to confirm it.
Have the program read existing tables as read-only, and write results to a newly created table. Even if something calculates incorrectly, your source data stays intact.
Every error has a reason. Paste the error message to AI and it can usually tell you exactly what went wrong — then fix it.
The first version doesn't have to be perfect. Running + roughly correct + not breaking original data — hit these three marks and start using it. Optimise once you discover real issues.
Employee commission calculation is just Chapter One.