Loading
Because the deal stops being one deal. An offer accepted in March completes in November through a chain of three, and the CRM was built for a sale that closes once.
So the chain moves into a spreadsheet, the CRM shows a stage nobody trusts, and the person who knows the truth is whoever last spoke to the solicitor.
Stages carry exit criteria you write, so "offer accepted" means a specific, verifiable thing rather than a hopeful phone call. A deal keeps its full history, including every time the completion date moved and who moved it.
The property, the applicant and the vendor are separate records that reference each other, rather than one row with everything typed into a notes field.
It is not a property portal and it does not publish listings. It holds the transaction, not the marketing of it, and integrates with whatever you already advertise on.
It also will not chase a solicitor. It will show you, with a date, exactly how long you have been waiting — which is usually the more useful half.
Books drafts the fee invoice from the agreed terms when completion is recorded, rather than from somebody reading the memorandum of sale. Loop opens the conveyancing checklist from the same record.
So the question "where is this one actually up to" has one answer, and it is the record rather than a person.
Products, not integrations. Each one reads the same record, so a join is a permission rather than a sync job with a mapping screen behind it.
Yes, as linked deals with their own dependencies. A delay upstream is visible on every deal below it.
Yes, as separate pipelines with their own stages and probabilities, which is usually how they actually run.
Yes, against the property or applicant record, with expiry dates and field-level permissions.
Half an hour on your own numbers is usually enough to say whether Flow is the right place to start.