How the work runs
Every week has a deliverable.
Including the first one.
Consulting goes wrong in the gap between the kickoff call and the first thing you can look at. This is what happens in that gap, week by week, and what you are holding at the end of each one.
The four phases
What happens in each phase?
The order matters more than the speed. Every phase ends with a document you keep, which is what makes the next phase arguable rather than assumed.
Discovery
Working sessions with the people who actually use the system, not only the ones who bought it. Objects, stages, roles, sharing and reporting, decided and written down. Where two teams disagree, that disagreement is recorded rather than silently resolved by me.
You receive: a written data model and a scope document listing what is in and, more usefully, what is explicitly out.
Build
Sandbox first, always. You get access from day one and a walkthrough every Friday, so the first time you see the system is not the week it goes live. Changes are logged as they are made, not reconstructed afterwards.
You receive: a working sandbox, a weekly change log, and a running list of decisions taken.
Launch
Migration dry run, then the real one. User acceptance testing with a written script rather than "have a look and tell me if it seems fine". Launch is never scheduled into quarter end, because the people who would find the problems are closing deals that week.
You receive: a UAT script with results, a migration report with row counts, and a rollback plan you hopefully never open.
Handover
A week of structured transfer, then sixty days of support while your team takes the wheel. The measure of success is not that the system works. It is that someone inside your company can change it without calling me.
You receive: administrator documentation, recorded walkthroughs, and sixty days where questions are answered at no extra cost.
The uncomfortable questions
What if something goes wrong?
What if the estimate turns out wrong?
The estimator gives a figure before anyone has seen your org, so it can be wrong. What cannot happen is the price moving upward after the scope is signed. If discovery uncovers work nobody knew about, it becomes a separate decision with its own price, and you are free to decline it.
What happens if the consultant is unavailable?
Everything is built inside your own org and documented as it happens, not summarised at the end. If I disappeared mid-project you would hold the data model, the change log and the sandbox, which is enough for another consultant to continue without starting over. That is the point of writing it down as we go.
Who owns the work?
You do. Configuration, documentation, flows, everything, in your org and under your licence. There is no proprietary layer, no managed package that stops working when the invoice stops.
Can the engagement be stopped early?
At any phase boundary, having paid for what was delivered. You keep the documents produced up to that point. A deposit taken before a scope is agreed comes back in full if the scope and your expectation do not meet.
Scope it before you talk to anyone.
Both estimators run in the browser and produce a document you can take to whoever signs the budget. No form, no call, no email address required.
Serhii Skrypnyk · RevOps Architect · 7 Salesforce certifications · on the platform since 2018