A buyer-operations layer changes a townhome builder's week by moving routine post-sale work (document chasing, deposit reminders, status questions, possession checklists) into a governed process, so the customer-care and sales-administration team spends its time on exceptions. The scenario below is an illustrative composite built from common Alberta builder workflows, not a description of a specific customer, and the numbers are examples rather than measured results.
Key takeaways
- In a typical townhome builder, the post-sale work for one buyer is spread across the CRM, the ERP, email, and spreadsheets.
- Most of the weekly volume is repetitive: missing documents, upcoming instalments, and "when is my possession?" questions.
- A buyer-operations layer connects to the existing systems, runs approved follow-ups, and turns disagreements into owned exceptions.
- People keep every consequential decision: pricing, possession dates, funds, conditions, and anything legal.
- The useful measure is the post-sale backlog: incomplete files, open questions, and homes possessing soon that are not ready.
The builder in this example
Picture a Calgary builder of front-garage and rear-lane townhomes:
- Three active communities, one in presale, one under construction, and one with quick-possession homes.
- About 40 firm buyers at different stages, plus a few conditional sales.
- Systems: a CRM for sales, a construction ERP for lots, pricing, and payments, a shared drive for agreements, and email for everything else.
- Team: two sales managers, one sales administrator, one customer-care coordinator, and a controller.
What does the week look like before?
Monday. The sales administrator exports a list of firm buyers and checks, one by one, which files are missing an amendment, a co-buyer ID, or FINTRAC fields.
Tuesday. The controller sends the customer-care coordinator a list of instalments due. Reminders go out by hand. Two buyers who already paid are chased because the sales file was not updated.
Wednesday. Construction moves three possession dates. Buyers hear from different people at different times.
Thursday. Fifteen buyers email asking about possession, deposits, or the GST rebate. Answers vary by who replies.
Friday. A quick-possession home shows "available" in the sales tool after it went firm. Two agents bring offers.
Nothing here is unusual. It is what happens when each system is right about its own data and nobody owns the connections between them.
What changes with a buyer-operations layer?
| Work | Before | With a buyer-operations layer |
|---|---|---|
| Missing documents | Manual weekly audit | Per-buyer checklist, approved requests, completeness view |
| Instalment reminders | Built from a controller list | Read from the ERP, sent with approved templates, paid items skipped |
| Possession date changes | Ad hoc calls and emails | Approved date read from the schedule, buyer notice drafted for approval |
| Buyer questions | Whoever answers the email | Approved answers; everything else routed to a person |
| Inventory status | Copied between tools | Read from the ERP; mismatches opened as exceptions |
| Possession readiness | Final-week scramble | Weekly review of homes possessing in the next 30 days |
Which exceptions still go to human review?
In this example, the team still decides, every week:
- A buyer asking to move a possession date or change a selection after the cut-off
- An incentive or price question outside the approved sheet
- A deposit that does not match the buyer or the schedule (see Alberta condo deposit rules for condo projects)
- A conditional sale approaching its deadline
- A FINTRAC question, such as a third party funding the purchase (see FINTRAC obligations for Alberta builders)
- Anything legal, financial, or warranty-related that is not already approved
The difference is that each exception arrives with the buyer, home, documents, and history attached, and an owner.
How would the builder measure it?
Before starting, the builder records a baseline, then compares after 30 days:
- Firm buyers with an incomplete file
- Buyer questions open for more than two business days
- Instalments that were chased after already being paid
- Homes possessing in the next 30 days that are not ready
- Inventory mismatches open and their age
These are the measures to watch. The results depend on the builder, its data, and its process; this example does not claim specific outcomes.
How would a pilot start?
- Pick one community, usually the one with quick-possession homes.
- Connect the CRM and ERP read-only.
- Approve message templates, answers, and escalation owners.
- Start with document follow-up and status questions.
- Review every exception for the first two weeks, then decide what to extend.
For a full buying framework, read how Alberta homebuilders choose buyer-operations software.
Where Asterisko fits
Asterisko is the buyer-operations layer described here. It builds a persistent context for each buyer and home from the CRM and ERP a builder already uses, runs permissioned workflows for documents, payments, approved questions, and possession readiness, and escalates anything outside policy to the responsible person. It does not set prices, approve sales, or make financing or legal decisions.
