By KYN AI Advisory Team — AI implementation specialists, Singapore
A property operations reporting pack usually starts as a set of spreadsheets that someone assembles each month from the building system, the tenant ledger and the maintenance log. The automated version reads those sources on a schedule, checks them against each other, flags what does not match and waits for a named person to release it. This article walks through the before and after for an office-tower operator. It is a design scenario, not a client report, and it carries no performance figures.
What does the pack look like before?
Take an operator of a multi-tenant office tower. The monthly pack for the owner contains five parts:
- Occupancy and expiring leases.
- Rent billed, rent collected and arrears.
- Maintenance requests: opened, closed, overdue.
- Utilities and service charge against budget.
- Contractor and vendor payments.
Each part has a different owner and a different source. Leasing keeps a tenant sheet. Finance keeps the ledger. The engineering team logs requests in a messaging group or a shared sheet. Utilities arrive as PDF bills. The pack is assembled by whoever has time in the first week of the month.
The problems are structural, not personal.
- Different dates. The ledger closes on the 30th. The maintenance sheet is updated when someone remembers. The pack mixes them.
- Different definitions. "Overdue" means 14 days to one team and 30 to another.
- No trace. A figure in the pack cannot be traced to its row. When the owner asks why arrears moved, the answer takes a day.
- No flag for missing data. If a vendor bill has not arrived, the number is low, and nobody sees the gap.
What does it look like after?
The same five parts, with a different spine underneath.
One data layer. Tenants, leases, units, charges, requests, bills and payments live in one database. Each record has an owner and a timestamp. The spreadsheets become imports, then are retired.
A rule for every definition. Overdue is a field with a threshold, written once and shown on the page. Occupancy is units let divided by units available, and the list of units excluded, such as under refurbishment, is explicit.
A scheduled build. The pack is assembled from the data layer on a set day, with a draft available earlier. Each table links to its rows, so a reader can click from a total to the lines behind it.
A completeness check before release. The system compares what it expected with what it received. Bills expected from each utility and vendor, ledger entries for each lease, requests with no status. Gaps appear at the top of the draft as a list, not buried as a low number.
A release step. A named person reads the draft, resolves or accepts each flagged gap, and releases it. The pack goes to the owner by the channel they use, with the date and the person who released it.
Which parts need a person?
| Step | Automated | Person | |---|---|---| | Read ledger, requests, bills | Yes | | | Match bills to vendors and budget lines | Yes | Confirms unmatched | | Calculate occupancy, arrears, overdue | Yes | | | Draft the pack | Yes | | | Flag gaps and outliers | Yes | | | Release to owner | | Yes | | Send arrears reminders to tenants | Drafts | Approves | | Approve vendor payments | | Yes |
Anything that sends a message in your name, moves money or deletes a record waits for a person. The pack follows the same rule: the system prepares it, and a person sends it.
How is the daily view different from the monthly pack?
The monthly pack is for the owner. Operations needs something faster. A short daily report for each department, delivered on WhatsApp early in the morning, covers what changed since yesterday: new requests, requests past their threshold, rent received, notices due.
We run this pattern for a manufacturer: a 06:30 morning report to each department on WhatsApp, at about S$0.05 per report. A property operator's departments are different, but the mechanism is the same. The report reads the data layer, writes a few lines per department, and sends. If the data is missing, the report says so instead of showing zero.
The daily view also shortens the monthly close. If arrears and overdue requests are visible each morning, the month-end has fewer surprises.
What does the build involve?
- Review. The first 14 days: inventory the sheets, ledgers and message groups, and interview leasing, finance and engineering.
- Model. Define units, tenants, leases, charges, requests, bills and payments, with the definitions agreed in writing.
- Import and check. Load a sample, compare totals with the last signed-off pack, and list the differences. Fix the model or the source.
- Pack and daily report. Build the draft pack and the department reports.
- Parallel run. Run one month with both packs. Compare. Retire the old one only when they match or the differences are explained.
A full build ships in under 90 days. The parallel run is the step that earns trust, so we do not skip it.
How do you check the pack against the old one?
Pick the last pack the owner signed off. Rebuild it from the data layer for the same month. Compare each total line by line: occupancy, billed, collected, arrears, overdue requests, utilities, vendor payments. Record every difference with a cause. The usual causes are a unit counted twice, a credit note posted to the wrong month and a request closed without a date. Each one is a rule to write down or a record to fix. When the rebuilt pack matches or every gap is explained, the new pack is ready for a live month.
What can go wrong?
- A definition changes mid-month. Version the definitions. The pack states which version it used.
- A source system has no export. Some building systems expose data only as reports. We read those on a schedule and treat the file as the source.
- Tenant data is sensitive. Leases and payment records need row-level security so leasing sees leases and engineering does not see rent.
- The pack is read as final when it has gaps. The draft shows its gaps first. The release step records who accepted them.
Where KYN fits
KYN builds operations systems that run in a cloud account in your name, with named accounts, row-level security and an audit log of every action. The manufacturer example above moved eleven systems to three on one AWS account and sends a morning report to each department. The same structure carries over to property: a data layer, scheduled reports, and releases that wait for a named person. Rights in the custom code and configuration pass to you on full payment. See operations, integrations and the related article on daily WhatsApp operations reports from an ERP.
Frequently asked questions
Can the pack replace the monthly owner report?
It can produce the draft and the supporting tables. A named person still reads it and releases it, because the owner relies on it.
What if the building system has no API?
Most still export reports. We read the exported file on a schedule, check it against the last one and flag anything unusual. The file becomes the source of record for that feed.
Does the daily report need WhatsApp?
No. It can go by email or sit on a dashboard. WhatsApp suits teams who already coordinate there, and it removes a login.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
