We looked at over 100 MCSTs in Singapore, and one thing kept showing up: the way a maintenance platform defines its roles decides whether the platform actually gets used. Most CMMS tools get this wrong for strata settings, and the gap shows up as unclosed work orders, unpaid vendors, and eventually a return to pen and paper.
Here’s what we found, and how we built Basementgrid’s role structure around it.
Why Digitalization of MCST Management Needs More Than a Typical CMMS
In a normal maintenance department, or a company whose business is maintenance, the role structure is simple. An admin has full access to work orders and assets. He creates a work order and assigns it to a teammate, who has limited access. The teammate does the fix, or calls in a contractor, records proof of work, and closes the case.
Budget approval sits outside the CMMS entirely. It happens in accounting software, where a director signs off once the amount crosses a threshold. Anything under that threshold gets done first, the vendor invoices after, and the manager submits it to accounting for payment.
The CMMS itself just tracks asset failure history. An internal technician records completion and closes the case.
This works because there’s always an internal technician in the loop. That assumption breaks down completely in a strata setting.
Ghost Maintenance: The Barrier to Digitalization of MCST Management
About half of Singapore’s MCSTs have fewer than 50 units. That means one managing agent, often juggling several other estates at the same time, running the whole show. There’s no budget to hire a technician to accompany every contractor and log the work.
That’s how ghost maintenance happens: work gets done, but nobody records it in a system the MCST can actually trust.
It gets worse when the CMMS itself is the obstacle. A contractor already juggling different CMMS tools across multiple estates isn’t going to climb a steep learning curve for one client. Work orders stay open, or never get logged at all. Eventually the MCST gives up on the software and the building manager, especially one trained the old-school way, goes back to pen and paper.
Handing the vendor a “limited user” role and expecting diligent record-keeping doesn’t solve this. It just moves the failure point.
More people are involved in an MCST repair than in a typical in-house maintenance job: admin, council, vendor manager, technician, accountant. More people means more places for a step to get skipped. Without a system that automates the handoffs between them, things fall through the cracks, and when they do, the blame lands on the building manager, whether or not the failure was actually his.
Basementgrid’s 5 Roles: The Framework for Digitalization of MCST Management
Basementgrid’s role structure starts from a different assumption: every role has exactly one job to do at each stage of the maintenance cycle, and the process itself enforces compliance. No role in Basementgrid is ever asked to do more than two primary actions across the whole process. Simple, clear, and easy to follow, even for a first-time user.
1. Admin (usually the building manager) Creates the work order and tracks its status. Can extend the role to an in-house technician if the MCST has one, or keep it limited to himself. No work order issued means no vendor gets paid, which is what keeps every job logged, especially the ones tied to payment.
2. Approver (usually council members) Gets notified once a work order crosses the amount threshold and votes for or against it. For a closer look at how threshold-based approval works, see our guide on the MCST maintenance approval process.
3. Vendor Manager Receives the approved work order and assigns a Vendor Technician to it.
4. Vendor Technician Travels to site, clocks in on arrival, and completes the job, including GPS-verified photos and any custom form fields required for that job type.
5. Admin verifies, Vendor Manager invoices, Approver reconciles Admin checks and verifies the completed work. Vendor Manager submits the invoice to the MCST for payment. Once payment is made offline, the Approver (usually an accountant) logs the payment and closes the loop.
| Role | Primary Action |
|---|---|
| Admin | Issues the work order, verifies completed work |
| Approver (Council) | Approve or reject above-threshold work |
| Vendor Manager | Assigns technician, submits invoice |
| Vendor Technician | Clocks in, completes the job with proof of work |
| Approver (Accountant) | Logs payment |
Why a Longer Process Delivers Real Digitalization of MCST Management
This process has more steps than a typical CMMS. That’s deliberate. Every role is accountable for one action, and every action is designed to be simple enough that if you know how to use WhatsApp, you can use Basementgrid.
The result: work that needs doing gets logged, work that’s completed gets verified with proof, and payment gets reconciled against actual work done. No ghost maintenance, no vendor chasing payment nobody agreed to, no manager stuck re-explaining a CMMS to a contractor who’s already juggling three others.
That’s the difference between a maintenance tool built for internal teams and one built for how MCSTs actually operate.
For a full breakdown of how each role works inside the platform, see our help center guide: Understanding Roles: Administrator, Collaborator, and Requester.
Leave a Reply