How Mason handles meter reading requests for a Dutch property manager

The problem: scattered meter reading requests across Outlook, Bloxs and personal agendas

The firm manages residential and commercial property in the Netherlands and uses Bloxs as its central ERP. Every working day, the shared meter readings mailbox received requests from utility suppliers including Dunea (water), Eneco, Vattenfall, Greenchoice (gas and electricity), Audax and Eteck (heating). Each supplier wrote its requests in a different format, and each request named a property address that had to be matched to a tenant.

For every inbound supplier email, an employee performed the same sequence. Open the email, read the address out of free-form text or an attachment, search Bloxs for the matching tenant, draft a tenant email asking for a meter reading and a meter photo, and then track in a personal Outlook agenda when to send a reminder. If the tenant submitted a reading, the employee copied it into the Bloxs meter-reading record by hand. If the tenant ignored two or three reminders, the employee scheduled a physical on-site reading.

Three problems made the workflow unstable. First, address formats rarely matched between supplier emails and Bloxs records. 131A in an email might be 131-A, 131 A or 131A front in Bloxs, and each variant broke the manual lookup. Second, with more than one hundred unanswered messages routinely sitting in the firm's wider inbox, meter requests competed with other priorities and slipped. Third, the workflow had no central status overview. Request state, tenant responses, reminder phase and physical-reading escalations lived in three different places (Outlook, Bloxs, personal notes), so requests got lost between them.

The solution: Mason as a workflow layer around the firm's existing systems

Mason is Sorrato's AI digital intern deployed at the firm. Mason is not a chatbot and not a replacement for Bloxs. Mason is a workflow layer that sits around the firm's existing tools (the shared Outlook mailbox, the Bloxs ERP and the firm's tenant communication channel) and performs the repetitive operational steps between them.

Mason reads the shared meter readings mailbox via the Microsoft Graph API and identifies the supplier and the property address. It normalizes that address to the canonical Bloxs format, looks up the active rental contract and tenant in Bloxs, and sends the tenant a secure token-link in the correct language. It tracks the response, sends automatic reminders if the tenant does not respond, and escalates non-responders to a physical-reading queue. The firm's staff keep control of the final step: verifying the submitted reading and finalizing the record in Bloxs.

The design principle is narrow scope and clear handoff. Mason handles the parts of the workflow that are repetitive, rule-based and time-sensitive. The firm's staff handle the parts that require human judgment: verifying that a meter photo matches the typed reading, deciding when an address mismatch needs a manual override, and finalizing the data in the Bloxs meter-reading field that the Bloxs API does not yet expose for direct write.

The 6-step process: how Mason works

1. Reading and recognizing inbound requests. Mason scans the shared meter readings mailbox via the Microsoft Graph API, identifies the utility supplier (Dunea, Eneco, Vattenfall, Greenchoice and others), and extracts the property address, supplier name, utility type and request reference.
2. Normalizing addresses and matching in Bloxs. Mason applies an address-normalization layer that resolves variants such as 131A, 131-A, 131 A and 131A front to the canonical Bloxs format. Mason then queries the Bloxs API for the active rental contract at that address and retrieves the tenant's contact details.
3. Emailing the tenant via a secure token-link. Mason drafts an email to the tenant in the correct language and includes a unique token-link. The tenant submits the meter reading and a meter photo through the form behind that link, with no account required.
4. Verifying the submission. When the tenant submits, Mason runs an AI check that compares the typed meter reading against the uploaded meter photo. Mismatches are flagged on the dashboard for human review before the record is finalized.
5. Sending automated reminders. If the tenant does not respond, Mason sends reminder emails on day 10, day 15 and day 18 without any human tracking.
6. Escalating non-responders to a physical reading queue. If the reminder cycle ends with no response, Mason moves the request into a "schedule physical reading" list on the firm's central dashboard, where staff can plan an on-site reading.

Mason vs. a traditional chatbot

A chatbot answers a question. Mason runs a multi-system workflow with a fixed handoff to a human at the verification step.

Old flow vs. new flow: a side-by-side comparison

Old flow at the firm

1. An employee opens a supplier email in the shared Outlook meter readings mailbox.
2. An employee searches Bloxs by hand for the address, often retrying multiple format variants before finding a match.
3. An employee drafts and sends a tenant email asking for a meter reading and a meter photo.
4. An employee adds a manual entry to a personal Outlook agenda to remember when to follow up.
5. An employee sends individual reminders by hand whenever the agenda flags a missed reply.
6. An employee copies the submitted reading into the Bloxs meter-reading record by hand.

New flow with Mason

1. Mason reads the shared Outlook meter readings mailbox via the Microsoft Graph API and identifies the supplier and the property address.
2. Mason normalizes the address and matches it to the active rental contract in Bloxs.
3. Mason sends the tenant a token-link email in the correct language, and the tenant submits the meter reading plus a photo through a login-free form.
4. Mason runs an AI cross-check between the typed reading and the meter photo and surfaces mismatches on the central dashboard.
5. Mason sends reminders automatically on day 10, day 15 and day 18 if no response arrives.
6. The firm's staff verify the prepared submission on the central dashboard and finalize the record in Bloxs.

The results: from end-to-end processing to final verification

The most concrete change for the firm is the shift in human role. The firm's staff no longer carry out intake, address matching, drafting, reminder tracking and chasing. They verify Mason's prepared output and complete the final write into Bloxs. The repetitive parts of the workflow run on a fixed protocol (day 10, day 15, day 18) that does not depend on anyone's memory.

The qualitative improvement sits in three places. Address normalization removes the failed-lookup loop that previously sent staff hunting through similar-looking address variants in Bloxs. The login-free token-link reduces tenant friction, which is the single biggest determinant of response rate in this workflow. The central dashboard collapses three previously separate surfaces (Outlook, Bloxs, personal notes) into one view of request status, tenant response, reminder phase and physical-reading escalations.

What becomes possible now that Mason handles the work: the firm can extend the same pattern to additional suppliers (Eneco, Vattenfall, Greenchoice) without re-architecting, and the workflow can serve as the foundation for further property management automation around the same Bloxs and Outlook stack.

Key outcomes

• 100% automated reminder sequences on day 10, day 15 and day 18, with no manual agenda tracking.
• 0 login friction for tenants, who submit meter readings and photos through a secure token-link without creating an account.
• 1 central dashboard for request status, tenant responses, reminder phase and physical-reading escalations, replacing three scattered surfaces.
• Up to 50% reduction in repetitive manual processing time is the benchmark Gartner cites for organizations deploying intelligent automation in real estate operations.
• Coverage extensible per supplier. Mason starts with Dunea and is designed to extend to Eneco, Vattenfall, Greenchoice and others without re-architecture.

The developer's take: working around the Bloxs API and Microsoft Graph

"Most property managers hit a wall when their ERP's API does not let them push specific data, like meter photos and meter readings, directly into the right tabs. Bloxs has an open API, but not every field is writable yet, the meter-reading record is one of those fields. On top of that, Microsoft Graph permissions on a shared mailbox are different from a personal mailbox and need explicit access setup. The obvious path of integrating Bloxs and Outlook directly was closed. Instead of waiting for an expensive Bloxs roadmap update, we built Mason as a smart layer on top of both systems. Mason reads the messy supplier emails via Microsoft Graph, completely cleans up the address data (131A, 131-A, 131 A, 131A front all collapse to the same canonical form), handles the entire tenant communication loop, and runs the reminder schedule without anyone tracking dates manually. About 90% of the grunt work disappears. The team reviews the final, perfectly formatted data and finalizes the record in Bloxs. That last manual step is a deliberate handoff, not a limitation."

Vito Kloots
Lead Developer at Sorrato
Updated 21 September 2026
LinkedIn

Frequently asked questions