In the dynamic world of customer relationship management, having a clear Salesforce strategy and roadmap is essential to achieving your business goals. At Oblytech, we understand that Salesforce isn’t just a software platform, it’s a strategic tool that can transform the way you interact with your customers, streamline your sales processes, and drive revenue growth. We offer guidance to help you develop a comprehensive Salesforce strategy and roadmap that aligns with your unique business objectives and can support a successful implementation.
We begin by conducting in-depth discussions with your team to understand your current challenges, pain points, and goals for Salesforce. We’ll explore your existing sales, marketing, and customer service processes, identify areas for improvement, and define key performance indicators (KPIs) for measuring success.
We’ll evaluate the different Salesforce editions, features, and functionalities available to determine the best fit for your business requirements and budget. We’ll also assess your existing technology stack and identify any potential integration needs or challenges.
We’ll work closely with you to develop a comprehensive Salesforce strategy that outlines your vision, goals, and priorities. This strategy will serve as a roadmap for your Salesforce implementation and ongoing optimization.
We’ll translate your strategy into a detailed roadmap, outlining key milestones, timelines, and resource allocation. This roadmap will provide a clear path for implementation and help keep your project on track.
We’ll collaborate with you to develop an implementation plan that addresses key considerations like data migration, user training, change management, and ongoing support.
We believe in continuous improvement. We’ll schedule regular reviews to assess your Salesforce performance, identify areas for optimization, and ensure your CRM strategy remains aligned with your evolving business needs.
A Salesforce roadmap is a sequenced plan that connects the business outcomes a leadership team wants to a set of platform initiatives, each with a reason for its position and a condition for finishing it. It answers the question that most steering groups eventually face: given limited administrator time, limited budget and limited tolerance for disruption, which changes should happen first? A roadmap is not a list of features the platform could deliver, and it is not a release calendar. Teams that confuse the three produce documents that look thorough but do not change which work gets funded.
The roadmap is most valuable when it is commissioned before the business has committed to a large number of initiatives. Once several projects are already underway, a roadmap tends to become a justification for decisions that have already been taken. Buyers who want the document to shape investment should request it while the choice is still open, and should expect it to say no to some requests that have internal sponsors.
The starting point is the outcomes, not the platform. The useful outcomes are specific and measurable in principle, even if the baseline is not yet recorded. Examples include a shorter period between first contact and a qualified opportunity, a higher share of service cases closed without re-assignment, fewer billing disputes caused by inconsistent customer data, or a forecast that leaders trust enough to commit a budget against. Each outcome should have an owner who will be asked whether the roadmap delivered it.
The next step is to trace each outcome to the processes and data that influence it, and then to the Salesforce capabilities that could change those processes. This trace is where many roadmaps first reveal a dependency. A forecast initiative depends on consistent stages, which depend on a sales process decision, which depends on agreement between sales and finance about revenue recognition. The roadmap has to show these links, because they decide the order of the work.
The output of this stage is usually a long list of candidate initiatives, each linked to one or more outcomes. The list is then reduced by scoring, not by discussion alone. Discussion tends to favor the initiatives whose sponsors speak most confidently.
A roadmap needs a method for comparing initiatives that have different value, cost and risk profiles. A simple model scores each candidate on five criteria: the value of the outcome it serves, the readiness of the data it depends on, the number of teams whose work it changes, the dependency it creates or removes for other initiatives, and the risk to live operations if it goes wrong. Each criterion should be rated against an explicit description, so that two people scoring the same initiative reach similar results.
| Criterion | Question the score answers | What a low score signals |
|---|---|---|
| Outcome value | Does the initiative move a measure the leadership team already tracks? | It serves a preference rather than a stated outcome |
| Data readiness | Is the data the initiative needs accurate and owned today? | Data work must come first and should be scheduled as its own item |
| Change load | How many teams must change how they work? | The rollout needs more change management than the budget shows |
| Dependency position | Does it enable other initiatives, or wait on them? | It sits on the critical path and should be sequenced earlier or split |
| Operational risk | What breaks for users if the change fails? | It needs a rollback path and a pilot group |
Sales-related initiatives in particular often need decisions about the sales process itself before they can be scored for readiness; the sales process optimization and automation page covers that area. The scores do not produce the roadmap automatically. They show where the disagreements are, and the steering group must still decide how to weigh value against readiness. A high-value initiative with low data readiness may still be first, if the data work it requires is itself a valuable result. A low-value initiative that enables several others may also come early. The model makes those decisions visible rather than deciding them.
A roadmap that ignores the license position will be revised within a quarter. The features an initiative needs may depend on the edition the organization holds, and some capabilities are sold as add-ons. The roadmap should list, for each initiative, whether it requires a capability that the current license does not include. This check does not need to be a commercial negotiation. It needs to be accurate enough that a funding decision does not depend on a feature the business has not paid for.
The estate around Salesforce matters at the same stage. The integration architecture page treats each connection as needing a defined business handoff and a named owner, which is the information a roadmap needs in order to schedule those connections. Marketing automation, finance systems, service platforms and data warehouses each constrain the order of work. An initiative that changes how opportunities are passed to finance may depend on a finance-system change that has its own timetable. The roadmap should record those external dependencies with their owners, so the steering group can see when a date depends on a decision taken outside the Salesforce team.
The roadmap becomes useful when each priority carries three things: a finishing condition, a named business owner, and a first increment that can be delivered and measured. The finishing condition should describe what users can do, or what report can be trusted, once the initiative is complete. A condition such as configure the approval flow is a task. A condition such as a discount above the agreed limit cannot be entered without a recorded approval is a result.
The roadmap should also set a review cadence. Quarterly review is common, but the review should be about outcomes and assumptions rather than status. The questions to ask are whether the outcome measures have moved, whether the assumptions behind the sequence still hold, and whether any new request is important enough to displace an existing priority. A roadmap that is never revised stops describing reality, and a roadmap that is revised every week stops being a plan.
A roadmap sets direction and sequence. It does not design the detailed process, specify the configuration, or estimate the build with precision. Those belong to discovery, design and implementation work that follows. Where the roadmap must be read alongside a service-management plan, the ServiceNow strategic IT roadmap development page describes roadmap work on the IT service management side. A roadmap also does not settle questions of organizational design, such as who should own the Salesforce platform inside the company, although it should identify where that ownership question blocks progress. Buyers who expect the roadmap to produce a fixed budget for each item should be told plainly that the budget depends on discovery, and the needs assessment and discovery page describes that stage of a Salesforce implementation.
Plan in detail for the period the organization can realistically fund and staff, and sketch the later period with fewer commitments. Long roadmaps with precise dates for distant items are usually wrong about the dates and right about nothing else.
The executive sponsor for the Salesforce platform should sign it off, with the functional leaders whose outcomes it serves. Signature by a single department head, without the others, tends to produce a roadmap that the other departments will not fund.
Score it with the same criteria, and place it in the sequence openly. Adding requests outside the scoring process is the fastest way to lose the trust that the roadmap depends on.
Gather the outcome owners, the list of initiatives already requested and the current license position before the first working session. With those three items, the first pass can be completed in a focused set of meetings rather than an open-ended series.
Grooming is the routine that connects a Salesforce roadmap to its backlog. The roadmap sets the order of outcomes over several quarters, and grooming makes the next items clear enough to build. Without a roadmap, the backlog fills with requests from whoever asked most recently or most loudly.
| Question | Roadmap | Backlog |
|---|---|---|
| What it answers | Which outcome should come next? | What is the next piece of work, and is it ready? |
| Unit of work | An initiative linked to a business outcome | A story or change with acceptance criteria |
| What changes it | A shift in priority or a moving dependency | A story is refined, split or dropped |
| Usual reviewer | The steering group, quarterly or monthly | The product owner, weekly |
A grooming session that works in most implementations runs in a fixed order. Start at the top of the backlog and check that each item names the outcome it serves. Park any item that cannot name one and send it back to the requester with the question the roadmap asks. Then confirm the data and dependencies are ready, because an item blocked by a missing field is not ready, however clear it reads. Only after that should the team size the item and write its acceptance criteria.
The common failure is grooming that only refines. Teams spend an hour rewriting stories the steering group would never fund, so run the roadmap check first. A second failure is a backlog with no ceiling. When far more work sits in the backlog than the team can build in a few iterations, most of it never ships. Data-heavy items need the Salesforce data quality and migration checks before they count as ready.
A simple readiness rule keeps the loop honest. An item enters the next iteration only when it has an outcome, an owner, acceptance criteria, and dependencies that are finished or scheduled. Items that miss one stay in the backlog and go onto the next agenda with the missing piece named. Teams that cannot sustain this internally can hand the standing work to Salesforce support and maintenance.
A Salesforce roadmap usually stalls at the funding decision, not at the writing. The document is approved, the steering group agrees with it, and the same requests return at the next budget round because nothing in the plan changed what gets paid for. One practical test is this: when two initiatives compete for the same administrator or developer hours, the one with a named outcome owner who controls budget goes first.
Strategy and roadmap are often written as one deliverable, but they answer different questions. The strategy states which customer and revenue problems the platform exists to solve. The roadmap states what happens first and why. Teams that skip the strategy tend to end up with a roadmap full of features. Teams that skip the roadmap tend to end up with a strategy that nobody can fund.
In most implementations the same four mistakes appear before the first review:
The last mistake does the most damage. A roadmap that places a forecast or service-level initiative ahead of the data it depends on can report a delay that looks like a platform problem. Give the data work its own item and its own finishing condition, and the team can see whether a slow result comes from the data or from the configuration. Once the process decision is made, sales workflow design with clean handoffs is a useful next step.
Before the steering group signs off, check two things in order: that each initiative names the team whose daily work changes, and that the first increment can be measured with reporting that already exists. Service-side initiatives follow the same test for case handoffs, and service workflows with clear ownership is a useful next read. If the internal team cannot hold the roadmap together between reviews, the question of who owns the plan matters more than the document. The broader decision about how to organize that work sits within Salesforce consulting for planning the investment.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.