The Situation
A property services firm in Zug was burning serious staff time pulling data out of land registry (Grundbuch) sources by hand and typing it into internal spreadsheets. The work meant cross-referencing parcel numbers, ownership records, area dimensions, encumbrances, and easement data, all of it done manually, page by page.
That process ate roughly 6 hours a day of one experienced staff member’s time. Transcription errors ran an estimated 3-5%, and those errors created real downstream problems when the firm leaned on the data for valuations and client reports. The spreadsheets had grown unmanageable, with no consistent structure from one project to the next.
What I Did
Process mapping. Before writing a single line of code, I spent two days mapping the existing workflow in detail: what data was collected, from which sources, in what order, and how it was used downstream. That step surfaced several fields that were being collected but never used, and several that were needed but routinely missed.
Semi-automated data collection. I built a Python tool that connects to the relevant cantonal data sources, pulls the required fields by parcel identifier, and structures the output into a consistent format. The tool does the repetitive retrieval; the staff member reviews and confirms each record instead of typing it in from scratch. That keeps human judgment in the loop for cases that need interpretation while removing the mechanical transcription step entirely.
Data normalisation and validation. Raw cadastre data arrives in inconsistent formats depending on source, canton, and record age. I wrote a normalisation layer that standardises address formats, area units, date formats, and ownership name conventions. A validation step flags anything that falls outside expected parameters (for example, an area value that differs sharply from neighbouring parcels) for human review before it enters the firm’s system.
Database restructuring. The old spreadsheet system moved to a structured SQLite database with a consistent schema. Each project has its own set of records, linked to source data and timestamped. Queries that used to mean scrolling through a 4,000-row spreadsheet now return in under a second.
Documentation and handover. I wrote operational documentation for the tool: how to run a collection, how to handle flagged records, how to export data for client reports. The goal was simple: any staff member should be able to run it independently, without needing to understand the code underneath.
Results
- Daily data processing time: 6 hours → 1.2 hours (80% reduction)
- Transcription error rate: 3-5% → ~0% (validation catches format issues before entry)
- Data retrieval for queries: manual scrolling → under 1 second
- Consistency across projects: all records now follow a single schema, searchable and exportable
- Staff dependency: tool runs independently; no developer involvement needed for routine operations
The firm now processes considerably more parcels per day with the same staffing, and client reports come from clean, structured data instead of manually assembled spreadsheet exports.
What Made the Difference
The key call was keeping the process semi-automated rather than fully automated. Cadastre data sometimes needs interpretation: a record with an ambiguous ownership entry, a parcel boundary dispute, an easement with non-standard terms. Full automation would either choke on those cases or quietly produce incorrect output.
By automating the mechanical retrieval and structuring while keeping a human confirmation step, the tool ends up both faster and more reliable than either a fully manual or a fully automated approach. The staff member’s time now goes to judgment calls instead of data entry.
The database migration came with a second benefit: the firm now has a searchable, auditable history of every parcel it has processed. Before, if a client asked about work done two years ago, the answer was buried in a spreadsheet somewhere. Now it’s a five-second query.