Loading
Feature lists are usually a way of losing an argument slowly. Every CRM has pipelines, contacts and a forecast, so a longer list proves nothing except that somebody had time to write it.
What differs is what each feature is attached to. A pipeline that writes to a record delivery and finance also read is a different object from one that writes to a sales database, even though both are called a pipeline.
Every entry below names the products it is joined to. Those joins are the specification, not a footnote.
The part people open the product for: stages you define, deals that carry their own history, and a forecast that is a view of the rows rather than a rebuild of them.
One company row the whole platform reads, including the unglamorous parts — duplicates, subsidiaries and who has actually consented to be emailed.
Priced off the rate card finance owns, approved by whoever actually has to approve discounts, and signed without leaving the record.
Calls, mail and meetings recorded against the account rather than against a person who has since left the company.
Everything between a stranger arriving and a named person owning them, with the page that made the lead still attached to it.
Numbers that show their own arithmetic, including the forecast that was submitted and how wrong it turned out to be.
The things that decide whether this survives contact with your actual company: fields, permissions, audit, and an API somebody can build on.
Read the list as one path rather than six products. Intake creates an owned lead with follow-up already scheduled; contacts and companies give it somewhere to live; the pipeline gives it a stage and a probability; quotes price it against the catalogue delivery will actually work to; the timeline keeps what was said; and the handover turns the whole thing into a project and a billing schedule.
The forecast is the clearest evidence that the joins are not decoration. A weighted number is only worth reading if the stages behind it mean something, so hygiene rules sit on the pipeline rather than in a monthly review, and when a deal slips the delivery plan pencilled against it moves too.
Nothing here is a tier. Custom fields, automations, permissions, the API and the audit trail behave the same on the smallest plan as on the largest, which means the list below is the whole list.
Open a deal and the customer underneath it is the same row Loop plans against, Books invoices from and Desk answers tickets for. Changing the stage here changes what those products see, because there was never a second copy to update.
Not add-ons and not an enterprise tier. These behave the same whether you run one product or all seven.
If you are comparing this against a standalone CRM, compare the joins rather than the boards. Ask what happens in the other tool at the moment a deal closes, how the renewal conversation gets delivery history, and who reconciles the invoice against what was sold.
If you are already running a CRM that works, start with close to delivery. It is the feature that changes the most for the least, because it removes the one step everybody currently does by hand.
Yes. Every feature listed here works with Flow alone. Where one says it joins another product, that join simply waits — switching the other product on later needs no migration, because the record it wants is already there.
No. Custom fields, permissions, automations, the audit trail and the API behave the same on the smallest plan as on the largest. The list on this page is the whole list.
Work backwards from the handover that costs you most. The feature that removes a manual step between two teams is worth more than the one with the longest description.
Fourteen days, every module, no card. Or half an hour with someone who will use your own numbers.