Implementation Strategies and Solution Design
From discovery to a delivery plan
Implementation questions reward a repeatable method: discovery → current-state and future-state process maps → prioritized requirements with traceability → solution design → build in sandboxes → UAT with real agents → training and go-live → adoption measurement → iterate. Name the artifacts: requirements backlog, process flows, solution design document, test scripts, cutover plan, and a Center of Excellence.
Design principles: configure before you code, exhaust AppExchange before building custom, and design for the release you can maintain rather than the demo you can wow. Phased rollouts (pilot team, then region, then all) reduce risk; a big-bang launch is defensible mainly for small, single-process orgs. Environment strategy matters: separate development, QA/UAT, and production with a deployment path - changes are never built directly in production.
Change management is usually what fails in real projects. Mention executive sponsors, champions, role-based training, in-console guidance (quick text, macros, Knowledge), and a feedback loop after go-live.
Traps: options that jump to a data model before requirements are agreed; that treat training as a go-live afterthought; that conflate a prototype with a validated design; or that design everything at once when the business asked for a first release.
Rule of thumb (the 80% test): if standard configuration covers roughly 80% of a requirement, configure it and revisit later. Only when the gap is a genuine differentiator should you consider custom code - after checking AppExchange.
Worked example: A team wants a bespoke agent-scoring widget. Discovery reveals the real need is "supervisors see who is overloaded." Omni-Channel workload visibility plus a case report meets it in days rather than weeks of custom build.