Can you show a live system you’ve shipped that’s still running in production?
Yes — ours. Rad Shift’s own CRM runs on the automated capture this build ships: every record in it arrived through the pipeline with campaign and owner attribution, and it has never been manually updated. On the scoping call we share a screen and walk it live — capture, record trail, and the approval queue as it ships in a client build.
What happens to our data during migration — can we lose anything?
A full snapshot is taken before anything moves and kept intact until you sign acceptance. The migration itself runs in staged batches with record-count reconciliation at every step — a mismatch stops the process rather than getting papered over. Nothing can be lost silently: any record that can’t be mapped cleanly is parked and surfaced for a decision, never dropped.
Can we roll back if something goes wrong?
Yes, at two levels. The pre-move snapshot is the rollback point for the migration, and it stays intact until you’ve verified the numbers and signed off. Inside the capture pipeline the same principle applies record by record: every write stores the value it replaced, so any change can be walked back without archaeology.
Will our reports and dashboards survive?
They’re part of the migration map, not an afterthought. Every report the team actually uses is inventoried during the two-day diagnostic, rebuilt on the destination, and verified against the pre-move snapshot before handover — you check the numbers yourself before signing acceptance. If a report exists that nobody uses, the findings brief says so and you decide its fate.
Will the team actually adopt it, or will it go unused like most rollouts?
Systems go unused when they add work, and the category’s standard rollout does exactly that. This build removes work instead: capture happens without typing, approving a write takes a click, and declining a suggestion is free — no write, and no record kept against the rep who declined. Handover includes hands-on training for the people who live in the CRM, not just the admin.
We’re mid-quarter. Will this stall the team?
No — the build is designed to run beside the quarter, not through it. The diagnostic is read-only, the destination is stood up in parallel while your live CRM keeps running, and the cutover is a scheduled, reconciled event you approve — not a weeks-long limbo. The team keeps selling the whole time.
Who touches our CRM instance?
Rad Shift’s core team always runs the diagnostic and the final acceptance QA. Where a delivery partner executes part of a Zoho-native build — TuvisTech, a premium Zoho partner — they are named in the SOW and you consent before any access exists, never silently. In a category where subcontracting is routinely hidden, the disclosure is the point: you know every set of hands on your instance, by name.
What happens when a step fails — and how do we find out?
Nothing in this build fails silently. Any write that can’t complete or reconcile is parked and raised to a named owner instead of vanishing; during migration, every batch reconciles record counts before the next one moves, and a mismatch stops the line. The runbook you receive documents each checkpoint — what the system does, and who gets told.
Which tools have you actually integrated before?
On the CRM side, by name: Zoho, HubSpot, and Salesforce — migration in any direction across the three. On the capture side, the stack we run ourselves: Apollo and Instantly wired into the CRM over a direct webhook. If your stack differs, the two-day diagnostic maps it before any build hours are spent.
How do you scope and price — fixed scope, time and materials, or retainer?
Fixed scope, fixed price, no retainer. The category norm is a custom quote at the end of a discovery arc; ours is a number that locks at the two-day diagnostic — the CRM + Data Foundation starts at $4,999 USD — and goes into the SOW before a build hour is spent. It doesn’t move mid-build, and nothing recurring follows it.
What if we’re already mid-migration, or half-finished?
Common, and not a problem. The diagnostic maps what’s done, what’s half-done, and what’s sound enough to keep — and the scope picks up from there rather than starting over. You pay for the distance remaining, not the distance already traveled.
What if the problem turns out bigger than we thought?
It often does — a cleanup surfaces a re-architecture, or an integration reveals a migration you’d been deferring. That’s part of why the two-day diagnostic comes first: it scopes the real job, not just the one you came in for. If the work is larger than the presenting problem, you see the revised scope and price before anything is committed — nothing expands mid-build without your sign-off. The same discipline that governs every write to your CRM governs the scope itself.
What if we don’t know which CRM we should be on?
That’s a diagnostic question, and it gets answered before the price locks. The two-day diagnostic maps your motion, your data, and your integrations, and the findings brief makes a recommendation with reasons — in whichever direction the evidence points. We implement across all three majors, so the recommendation isn’t steered by what we happen to be able to build.
What does handoff look like — are we dependent on you afterwards?
You’re handed a working data layer and everything needed to run it without us: the runbook, the field dictionary, an acceptance checklist you sign against, and every credential in your own accounts. There’s no retainer and nothing that phones home to us. Dependency after handover would be a defect.