MoveAnchor
Private alpha: operations and sales
Pipeline, dispatch, and the numbers, all in one place.
MoveAnchor is a web app for moving sales and operations in one system: pipeline through dispatch on the same records you report on, without retyping into another tool or living in a calendar that is not tied to the job.
MoveAnchor is in private alpha: the app is complete end to end, and we are gathering feedback on layout, navigation, and options before a broader launch.
The product is designed for phone and tablet use, not as a desktop site you pinch to read. It runs as a progressive web app. Add it from the browser and use layouts meant for small screens. You should still have customer data in hand without desk only flows.
I spent seven years in the moving industry, including as sales director for one of the largest movers in the Twin Cities, so this comes from running that side of the business, not a generic CRM spec.
I built MoveAnchor as a solid base for small moving companies, often just a couple of trucks, not a stripped down lite you are expected to outgrow. Pricing is aimed at shops that cannot stomach enterprise line items but still need a real CRM. Month to month, no onboarding fee; support and updates are part of the subscription, and the roadmap follows what working movers ask for.
- Each company’s data stays in its own lane
- Reports use the same numbers your team already entered
- Connection points you can hand to IT
Open the product tour on the Features tab, and use Join the alpha in the bar above to get in touch.
At a glance
One system of record
Sales, jobs, and money stop living in three spreadsheets. One place to work. Each company’s data kept separate. An API your IT person can actually read.
Faster, clearer handoffs
Dispatch lives in the same app as the rest. Texts, reminders, and paper all sit on the job, so dispatch and the office are not playing telephone about who said what.
Reporting you can interrogate
Heavy reporting sits off the live ops path so exports and dashboards do not slow down the screens your team uses all day.
Who it is for
A moving shop is usually a similar cast: the owner or GM, ops and dispatch, sales and estimating, customer service and claims, crews in the field, and an accountant or bookkeeper who has to make the numbers line up. MoveAnchor is for groups that want one place where sales and ops actually match, not four logins that only line up when someone stays late to fix it. We build it the same way we build our own internal tools, not a weekend hack.
What breaks when software is not built as one system
- Sales lives in a CRM, dispatch in a calendar, and accounting somewhere else. Nobody is looking at the same job as the single source of truth.
- Reporting is either a PDF nobody trusts or a spreadsheet only one person can maintain.
- Storage or vault work is tracked in side systems, and billing for it becomes a fight between teams.
- Permissions are a spreadsheet of who knows the admin password, not a model you can hand an auditor or an enterprise buyer.
Why not “just a CRM” and a stack of sheets?
Moving is not the same as selling software licenses. The three points below are what we kept in mind so the app follows jobs and trucks, not a generic deal object from a template you have to fight all day.
Deals and moves are not the same object
A generic CRM thinks in people and deal stages. We think in accounts, jobs, dispatch, and a path that bounces, because real moves do. The point is the office and the field both mean the same thing when they say a job, not the same deal record bent until it breaks.
Reports from the real data model, not a new extract every time
Spreadsheets are fine until you are the only one who can refresh them. Reports here pull from a single list of fields you keep in the app, and we only add heavy joins when your question actually needs them, so the Friday number is not a new export every week.
Storage and warehouse get real rules, or stay out of the way
If you run storage, you need rates, periods, and billing that are not a tab in a spreadsheet the billing manager guards with their life. You can turn that module on per customer, and if you do not use it, we do not flash warehouse screens to people who will never care.
How work usually flows (when it isn’t stuck in five tabs)
From sold to paid on one thread. Each company’s data stays separate on the back end.
- 1
Win & stage work
Your stages, your leads, then jobs with a real lifecycle. You know what is sold before it lands on a truck board.
- 2
Schedule & communicate
Dispatch and the calendar live in the app. Templates, scheduled emails and texts, and a paper trail of what went out, all on the same job, not in someone’s side inbox.
- 3
Bill and document
Invoicing, repeat billing, and PDFs for what you actually send out the door. When you need accounting or payment tools hooked up, we work from what is already in your stack; we’re not pretending every install looks the same.
- 4
Measure and govern
The report side gives you real rows to sort and chart. Roles, SSO, and customer isolation are there ready for when the owner and IT start asking who can see what.
Main areas in the product
Open a row if you want the longer version.
Sales & pipeline
Your company defines the stages. Leads and opportunities sit in the same system as jobs, so a closed deal is not a retype into another tool.
Pipeline, accounts, and jobs share one thread of data with the same scoping and auth rules as the rest of the app.
Customers, jobs & notes
Accounts and jobs share one relationship model: who you are moving, what is scheduled, who owns the work. That record anchors documents, messages, money, and reporting when those are on.
Notes are a first class screen (threads, @mentions, job vs full customer scope) with one component everywhere. Follow ups and reminders use the same task data reporting can read.
Dispatch & scheduling
Day board and scheduling views tie to jobs and crew, not a disconnected busy/free calendar.
Job-related events can sync to Google or Microsoft calendar where that integration is enabled for the org.
Inventory
Per job: itemized and free form tabs, rooms, master list, and import when you need it, on the job instead of a fresh Excel export every time.
Partner style flows (e.g. Yembo) are documented; what is on depends on how that tenant is configured.
Messaging & templates
Templates and scheduled email/SMS live in the product; wiring uses your mail/SMS providers (e.g. company mail, SendGrid, Twilio) per tenant configuration.
Message traffic can be modeled in reporting alongside jobs, money, and operations when you build for it.
Automations
Visual canvas: waits, branches, email/SMS sends, and CRM updates, grouped so the next person can read the flow.
HTTP, accounting sync, and calendar steps exist as capabilities. What is live depends on the workspace.
Documents, forms & revenue
Layout, fields, formulas, variables, and signatures, with customer preview before publish. Paperwork stays aligned to estimates and BOLs, not a side PDF app.
Customer forms run in a branded shell separate from staff chrome. Invoicing supports recurring where you need it; PDFs render from backend generation in common paths.
Accounting connections follow usual OAuth style sign in (QuickBooks, Xero, Stripe, and similar patterns); availability follows your deployment.
Reporting & insights
Data-source registry and shared query engine: dimensions, metrics, filters, saved definitions, and tabular runs for tables and charts via the product API.
Analytics storage is separate from the transactional path crews use all day, so heavy dashboards do not fight the same rows as live entry. Chart types (table, stat, bar, pie, line, area) and domains follow the spec for your modules.
Runs are scoped per company; joins stay tight to the question so simple views stay fast.
Warehouse (optional)
Opt-in per tenant: when off, warehouse navigation and APIs stay out of the way for users who do not run vault work.
When on: receiving, shipment groups, dispatches, allocations, storage rates (daily/weekly/monthly cycles and common unit styles), periods and accrual so billing matches the building. Customer shares use revocable links and optional PINs; permissions split floor, billing-sensitive data, and homeowner-facing views.
Claims, fleet & org controls
Claims are a structured workflow and a reportable domain when the module applies: traceable files instead of inbox threads. Fleet data arrives via webhooks/provider hooks; which vendor is active is per org.
RBAC on the token, org admin, fine grained navigation permissions, and optional sales/estimator/dispatcher splits. The SPA loads a large server driven config so stages, fields, and options can change without client only rewrites.
OIDC sign in from common idPs (with sane discovery hardening), LDAP paths where you still use them, and OpenAPI you can hand security or IT. Before you promise a specific connector or screen to a customer, confirm what is enabled for that tenant. Production varies.
The real product menu may group this differently. This list is for reading, not for guessing the exact tab order in your tenant.
Glossary
Quick definitions for people scanning the page.
- Lead / pipeline
- Stages you define for sales work before and after a job becomes real work in operations.
- Dispatch
- Scheduling and assignment of jobs and resources so the field and office stay aligned.
- Tenant
- Your company’s isolated data and configuration in the product. That wall between tenants is there so the wrong people cannot see the wrong company’s work, and it is part of the security design, not an honor system. Access is driven from identity, not ad hoc client fields.
- Warehouse module
- Optional receiving, storage, dispatch from vault, and billing patterns for when you run that part of the business in software.
- Report run
- A saved or ad hoc execution of a report definition against the engine, with the right scope for that customer on every run.
- Automation step
- One step that actually runs in an automation (for example a branch evaluated, an action sent, or a wait advanced). Usage counts steps, not just whether an automation is turned on.
- Document template
- A signable, layout first definition of paperwork: fields, calculated values, and signatures, with preview that mirrors the customer view when you are ready to publish.
- Customer form branding
- Colors, fonts, banner, and logo that apply to customer facing web forms and document links, separate from the look of the staff application.
MoveAnchor ·
Join the alpha or book a walkthrough when the link is up.