IT consulting, software and support · Dhaka
Where it breaks
This is not a selling problem. It is a record keeping problem that looks like a selling problem.
Sales and customers
Every enquiry depends on who received the call
Enquiries come from Facebook, bikroy, the sign board and references, and they go into different people's phones.
Follow-up is kept in memory, not in a schedule, so a serious buyer is left alone while a casual one gets two calls.
Availability is confirmed by calling the office, and sometimes two people book the same unit.
The price depends on which marketing person is talking, not on one approved rate.
When a buyer asks how much he has paid, somebody has to open a file to answer him.
Payments and handover
The ledger is correct only after somebody checks it
Instalment schedules are in Excel, one file for each project, kept by one person.
Payments come by cheque, bank transfer and bKash, and they are matched with buyers by hand.
Overdue instalments are noticed when the file is checked, not on the day they were due.
Construction progress is told in meetings, but buyers ask about it every week.
Handover, registration and utility papers are kept on paper, unit by unit.
What we build
Not a full property ERP from day one. Usually the inventory and the ledger, on one project.
Unit inventory
Every unit with its status, size, facing and approved rate. Availability can be told without calling anybody.
Enquiry and follow-up
All enquiries in one place, with the next call fixed in the system instead of kept in memory.
Booking and allotment
Booking against a unit, so double booking cannot happen at all.
Instalment ledger
A schedule for each buyer, made from the agreement, with due and overdue seen every day.
Payment reconciliation
Cheque, bank and mobile payments matched with the buyer's schedule as soon as they come.
Buyer portal
The buyer can see his own schedule, payments and receipts, so your office does not answer the same question daily.
Construction progress
Progress for each project and each floor, entered once and shown to both management and buyers.
Handover and documents
Registration, utility and handover papers kept unit by unit, so nothing is found missing at the end.
Illustrative pattern
Where most developers start
Enquiries in personal phones, availability confirmed by call, instalment schedules in one Excel file for each project, and progress told in the monthly meeting.
What we check first
We do not talk about software first. We take one project and follow one buyer from his first enquiry to his last instalment, and see how many people had to be asked in between.
What we build
One unit inventory with approved rates, an enquiry list with follow-up fixed in the system, and an instalment ledger made from the agreement instead of kept by hand.
How we roll it out
One project first, usually the one selling now, keeping the existing Excel file running beside it until both match.
What it looks like after
Availability and price come from the system, overdue instalments are seen on the day they are due, and the buyer can check his own payments without calling your office.
The gap we usually find
Three people
have to be asked before a buyer gets a clear answer about his own payments.
Nobody is hiding anything. The record is just kept in three places.
What we ask to see
This is an example, based on how development projects are generally run. It is not any particular client project.
Read the case studyOutcomes
Enquiries in personal phones
One pipeline for the company
Follow-up remembered
Follow-up scheduled
Availability confirmed by call
Answered from the system
Price depends on who is talking
One approved rate
Overdue found on review
Seen the day it falls due
Buyers calling for their ledger
Buyers check it themselves
Why this sector is different
Five things that decide whether the system lasts beyond the first project.
Condition 01
One unit is sold once
This is not a shop selling stock. A double booking is not a stock mistake, it becomes a legal problem and a name problem.
So the system must
Booking locks the unit, and that lock stays in the system, not in a register.
Condition 02
The sale runs for years
A buyer pays instalments for three or four years. He stays with you longer than the marketing person who sold to him.
So the system must
The buyer's record has to belong to the company, not to whoever handled him.
Condition 03
Money arrives in every form
Cheque, bank transfer, bKash, and sometimes part cash, against a schedule agreed on paper.
So the system must
Every payment entered against the buyer's own schedule, and the receipt given from there.
Condition 04
Trust is the product
A buyer who cannot get a clear answer about his payments will tell other buyers. In this market that decides your next project.
So the system must
A buyer portal, so the answer does not depend on your office being free.
Condition 05
Approvals and papers decide handover
RAJUK approval, registration, utility connection and handover papers all have to be ready, unit by unit, at the right time.
So the system must
Papers tracked unit by unit from the booking stage, not collected at handover time.
How we start
Nothing is switched off, and no sale has to wait for us.
One project
We follow one buyer from enquiry to instalment, and see who had to be asked.
Pick the costliest gap
Usually the enquiry pipeline, or the instalment ledger.
Run it on that project
Beside the existing Excel file, until both match.
Then the rest
Once the numbers match, the file is retired.
Get in touch
Plot 22, Road 17, Sector 13,
Uttara West, Dhaka 1230, Bangladesh