A spreadsheet importer looks like the respectful way to migrate a team. It also keeps the spreadsheet in charge. Describing the data on screen, in four answers, replaced the workbook instead of feeding it.
By Mohammad Jamnagarwala · Simply Five Studio
Every operational system eventually meets a spreadsheet it is meant to replace. The polite move is to build an importer. The team already has the data in a workbook, the workbook already has a shape, and an upload button respects the work they have done. We built exactly that for Evrnest Vista Associate, and it was the wrong door.
Evrnest is a real-estate channel partner in Chennai and Dubai. When a developer gives the firm a mandate, an exclusive book of units in a tower to sell, the inventory arrives as a developer's spreadsheet: every unit number, its floor, its carpet and saleable area, its undivided share of land, its car parking, and a cost sheet with a dozen charge heads.
The first version of the Mandates module, the developer side of the firm's real-estate inventory system, accepted that workbook. It mapped the columns, validated the rows, flagged the duplicates, and wrote two hundred units in a few seconds. It worked. It was tested. The desk used it.
Then we watched what the desk actually did. Before any upload, someone had to reshape the developer's sheet into our shape. Columns renamed. Merged cells split. Floors that the developer had written as a range typed out row by row. Charge heads moved into the order the importer expected. The import took seconds. Preparing it took an afternoon, in Excel.
The firm had commissioned a system so it could stop living in spreadsheets. The importer had walked the desk straight back into one.
An importer makes the spreadsheet the authoring tool and the system the storage. That arrangement has three costs that never show up in the demo.
The shape belongs to the template. Every developer formats a sheet differently, so the importer either accepts one shape and forces the desk to reshape everything, or accepts many and becomes a growing pile of special cases.
Corrections happen in the wrong place. When a unit is wrong after the import, the natural fix is to edit the sheet and import again, which raises the question of what happens to the rows already sold, held or attached to a buyer.
The skill stays where it was. The person who knows how to prepare the import becomes a bottleneck. The system is only as current as their last afternoon in Excel.
We rebuilt the module around a different question. Not "what is in your spreadsheet?" but "what is this building?"
A tower turns out to be four answers. How many floors. How many units on one. How they are numbered. What they cost.
The numbering answer is given as a single example. Type A101, and the
system reads it as block A, the floor in the number, two digits for the
unit, starting at one. From that one example it generates every unit
number in the building and draws them as a map, a grid of pills, one per
unit. The flat that does not exist on the ninth floor because of a
service duct is switched off, not deleted, so the numbering around it
stays right. Floors that hold car parking instead of flats simply skip
the letter, so A, B, parking, C falls out without anybody explaining it.
The cost sheet is authored once per mandate as rows, seeded with the developer's own twelve charge heads. Each row is filled across a floor or across the whole building with a figure, a rate per square foot, or the tax on the rows above it. A suggestion from a rate is shown and can be overtyped, and only the accepted figure is stored, for reasons we set out in Software that stores prices and does not do money. The payment schedule is one document for the building, and each sale takes its own copy.
Nothing is written until someone presses Create. Until then the whole tower is a plan on screen that can be adjusted freely.
The afternoon in Excel disappeared. Describing a two-hundred-unit tower now takes about as long as reading the developer's sheet once, because that is all it requires. The person entering it needs to understand the building, not the template.
Corrections happen where the data lives. A wrong area on a floor is fixed across that floor in the system, and a unit that is already sold is never touched by an edit to its neighbours.
And the importer still exists, for the developer who sends a clean workbook. It is simply no longer the way in.
This applies well beyond real estate. Whenever a system is replacing a spreadsheet, it is worth asking what the spreadsheet is a description of. A rate card is a description of a pricing policy. A stock sheet is a description of a warehouse. A roster is a description of shifts and rules. In most cases the underlying thing has far fewer degrees of freedom than the spreadsheet has cells.
When the system asks for the underlying thing, three good things happen. Data entry shrinks to the decisions only a person can make. Errors that come from copying, a typo on row 147, become impossible because row 147 is generated. And the knowledge of how the business is structured moves out of one person's workbook and into the system, where anyone on the team can read it.
We wrote about the same instinct from the warehouse side in Count the bag, not the balance: model the physical thing, and the arithmetic stops being somebody's job.
An importer is a fine migration tool. As the main entrance to a system, it tells the team their real work still happens somewhere else. If your team spends more time preparing data for your software than using it, the software has the door in the wrong place.
Most real-estate CRMs drop a paid lead straight into someone's pipeline and alert the whole team. Holding it in an unowned company pool until a director assigns it fixes ownership, the numbers, and the noise in one move.
Most stock systems keep one number per item and add or subtract from it. That works until a sticker is scanned twice, two identical bags share a rack, or a 19 kg bag hides among the 50s. Keeping one record per physical bag removes the whole class of error.
Most distributors keep product data and pricing in three places: Tally, the ERP, and the storefront. Keeping them in agreement is a chore nobody owns. Sync from Tally by GUID and the chore disappears, because the books become the source everything else reads.
The contact form takes about two minutes. The reply comes from the founder within two working days.
