Treepie Flow·Use cases

What Flow sets in motion.

Journeys that begin in Flow and end somewhere else entirely — without the record being copied at any boundary.

8 use cases · /flow/use-cases/

Why journeys

A journey is the only honest unit.

A feature list tells you what exists. A journey tells you what happens between the features, which is where every business system actually fails.

These three are the chains a deal sets in motion. Each names the boundaries it crosses and what stops being retyped at each one.

Software fails at boundaries. A feature list cannot show you one; a journey has to.

Flow journeys

8 use cases

Structure → routing → visibility → rollupMulti-team and territoriesTerritory routing and team visibility derived from the reporting structure rather than maintained by hand.Flow · NestFollow the path →Change → audit trail → review → evidenceSales audit and complianceEvery change to every record kept with its previous value, its actor and its timestamp, permanently.FlowFollow the path →Detect → review → merge → history keptDuplicate cleanupMerges that move every deal, ticket, invoice and note onto the surviving record, with the full merge recorded.FlowFollow the path →CSV → diff → approved import → owned leadsLead import and migrationA mapped import that shows exactly what it will create, update and reject before it writes anything.FlowFollow the path →List → sequence → reply → owned dealOutbound sequencesSequences enrolled from live segments and stopped by a detected reply, on the record that already holds the relationship.FlowFollow the path →History \u2192 risk \u2192 conversation \u2192 renewalRenewal to retentionWhat actually happened this year — delivery, support, invoices — in front of you before the renewal conversation.Flow · DeskFollow the path →Quote \u2192 accept \u2192 build \u2192 billQuote to deliveryWhat was quoted becomes what is built, without a scope document being rewritten in between.FlowFollow the path →Enquiry \u2192 deal \u2192 project \u2192 invoiceLead to cashThe whole chain on one record: enquiry, deal, delivery, invoice — nothing re-keyed between them.Flow · LoopFollow the path →

What they share

Three journeys, one row that never gets copied.

The feature list →

Lead to cash, quote to delivery and renewal to retention are the same record read at three different moments. What makes them work is that none of the moments involves a copy.

Every boundary in these paths is somewhere a conventional stack exports and re-imports: sales to delivery, delivery to billing, billing back to the account team. Each export is a chance to drop a discount, a caveat or a date.

The renewal journey is the one that reveals whether the others worked. An account team that can see delivery history and payment behaviour is having a different conversation from one working off the last phone call.

Copies madeNone. Each step is a view of one record rather than a synced duplicate of it.

Products crossedFlow, Loop and Books, with Desk picking up entitlement at the close.

Time to run oneAbout a week to walk a real record end to end with the team watching.

What stays humanWhether the deal is real, and what the customer was actually promised.

Four steps · about a week

Running one of these yourself

01Take one deal that closedA real one, recently, with a delivery team who remember it.

02Walk it to the invoiceNote every point where somebody opened a second system and typed something that already existed.

03Count the retyped fieldsThat count is the cost of the boundary, and it is usually larger than anyone guesses.

04Open the project from the dealOne switch. Then walk the same chain again and count the fields.

The boundary problem

Every one of these journeys used to break at a handover.

Not because anyone was careless — because the record stopped at the edge of the tool, and somebody had to carry it across by hand.

Who runs Flow →

Sale to deliveryScope retyped from a proposal into a plan, losing the caveats agreed verbally.

Sale to financeBilling schedules rebuilt from the contract by somebody who was not in the room.

Sale to supportEntitlement set weeks later, so the first ticket is answered on goodwill.

Where to start

How to judge a journey.

If you sell and deliver, read lead to cash first — it is the longest chain and the one with the most boundaries.

If your problem shows up at renewal rather than at handover, start with renewal to retention and work backwards.

Journeys for the other six

All seven products →

Nest journeys7 · HR & employee management Loop journeys8 · Project & work management Desk journeys8 · Customer support & ticketing Books journeys8 · Finance & accounting Growth journeys8 · SEO & growth intelligence Pulse journeys7 · AI customer & employee assistant

Questions

Flow journeys, answered.

See the features behind them →

Does lead to cash need all four products?

No, and each page says which ones its chain crosses. Flow and Books alone give quote to invoice; the delivery record joins later without redoing the first part.

How long does the first journey take to set up?

About a week, most of it deciding rather than configuring. The second is much faster because the record is already shared.

What if we sell products rather than projects?

The boundary is the same. Read where your record currently gets retyped — order to fulfilment, or deal to delivery — rather than the step names.

Where does a journey usually break today?

At the close. The deal is complete, and three other teams start rebuilding it from a proposal, a contract and an email.

Can two journeys run on one customer?

Yes. A renewal and an expansion are separate journeys against the same row, which is why neither has to be copied to exist.

Bring the journey that hurts most.

We will run it end to end on your own numbers in half an hour, and tell you honestly which parts Treepie does not improve.

Book a walkthrough Start free