You're moving into a virtual warehouse. Miles runs the move.

Every new business arrives with its own mailbox formats, its own client list, its own parts catalogue — none of it in TOWR's rules yet, because it doesn't exist until your data reveals it. Miles turns that into a rollout project in PEM: sequenced, chased, and visible to you. Prefer to do it yourself? He sits this one out.

Onboarding is the only part that can't be pre-written.

Everywhere else in TOWR, deterministic rules win. Moving in is different — producing the rules is the job. A language model earns its keep exactly here: reading your history, proposing what to keep, and stopping when only a human can answer.

01Your mail, clients and catalogue arrive in their own shapes — not ours

02Miles proposes; a person reviews; accepted proposals become ordinary data

03When you're live, the project closes — no ongoing AI tax on every job

Miles sequencing a TOWR rollout: steps proposed, awaiting review, and marked done

A bounded list — not “an assistant.”

Sequencing, chasing, setup guidance, and an import walkthrough — the same line the product already draws. Nothing about credentials, autonomous changes, or a support SLA pretending to be magic.

Mail rules from your history

Reads mailbox history and proposes sender, subject and intent rows — tested against your own messages before anyone accepts them.

Clients, found not guessed

Surfaces clients from mail and your backend — including ones that never made it onto a tidy list.

Mappings per client format

Field mappings tested on that customer's historical messages, not a generic template. Site, task-type and priority mappings from your own reference data.

Smart Parts on the catalogue

Dedup detection, naming cleanup, size and weight when you have them — and graceful defaults when you don't. Never leaves you stuck because a field is blank.

The rollout as a PEM project

What's done, what's blocked, what needs a human decision — the project-manager part, visible in the same tracker you'll use every day after.

Ask, then stop

Never guesses past a real unknown. When only a person can answer, Miles waits — the same discipline PEM already uses for every other kind of work.

A PEM Moving In project: steps done, stocktake in progress, remaining work still visible

The move is a project you can see.

Your rollout becomes a real project in PEM — scoped, sequenced, and chased the same way Miles runs TOWR's own builds. You watch it happen in the tool you're adopting, not in a side spreadsheet about the move.

→Steps visible: done, in progress, blocked, awaiting you

→Chased like any other project — not left to drift

→When you're live, the project closes and the keys are yours

The catalogue you actually have — not the tidy one on the brochure.

Parts arrive misspelt twice, blank where a supplier field should be, and half-measured. Smart Parts assumes that mess is normal: find duplicates, normalise names, use size and weight when they're there, and default conservatively when they're not. Machine grouping then runs against the cleaned catalogue — not the messy one.

01Lookup, rename, group — dedup and naming cleanup, aided by size and weight once those exist

02Machine grouping — already in the Warehouse, run on the cleaned set

03Recategorise — push corrected categories back once grouping knows what a part belongs to, human-confirmed

Bring your data across: spreadsheet upload and other import paths for Moving In

Never let the move get stuck.

A business that won't measure every part can't be told the feature doesn't apply. Miles degrades visibly and honestly — never invents silently.

→Size class missing — defaults to the largest class: the conservative assumption, never silently “small.”

→Weight class missing — defaults to heaviest; low-shelf logic stays inert until shelf levels exist for that bay.

→Both missing at scale — derive from description text where it can, or an external lookup where you allow it — so “we won't measure thousands of parts” doesn't mean “this doesn't apply to us.”

Miles is for the move — not a permanent dependency.

Delete the AI key and everything that was accepted keeps working forever, unchanged. Every proposal is reviewed once, accepted once, and becomes ordinary durable data — no per-message cost forever, and no product that stops if the API is down. A human can type the same result in by hand and get it. Miles never writes behind your back: human-confirmed changes only, through the same real paths the product already uses.

What he does not do.

Stated plainly so the promise stays inside its lines.

→Does not write backend adapters — proposes a mapping to one that already exists

→Does not remove the need for a human on the move — changes what they spend time on, from writing parsers to reviewing proposals

→Does not get smuggled into day-to-day mail judgement after you're live — that would be a runtime dependency, and the hard rules forbid it

Rather do it yourself?

Good. Every Miles job has a manual way out — the same rule the product applies everywhere else. The built-in help guide covers the day-to-day, end to end.

Need more than the guide?

That's where paid support comes in — stated plainly here, rather than found out partway through the move.