Assessing tools—determining when to optimize or replace technology

5.1 Introduction: The Role of Tools in Your Tech Stack

Tools are the software and platforms that enable your teams to carry out daily tasks, from customer relationship management (CRM) to analytics and marketing automation. While tools play a critical role, assessing them as the last step of your diagnostic process helps ensure that you avoid unnecessary replacements. Often, problems blamed on the tool itself can be solved by addressing team rituals or improving system connections. By assessing tools only after addressing these root causes, you can make informed decisions that genuinely support long-term growth and efficiency.

In this lesson, we’ll discuss signs that indicate when tools may be the root cause of issues, walk through steps to evaluate them, and explore ways to optimize existing tools before considering replacements. Finally, we’ll outline criteria for deciding when it’s time to invest in a new tool and provide a case study for a realistic, detailed example of a CRM migration.

5.2 Signs That Tools May Be the Root Cause

Even after streamlining workflows and reinforcing strong rituals, sometimes your software simply can’t meet your growing business needs. When that happens, the tool itself can become the bottleneck. Here are common signs that your tech solution may be the root cause:

1. You can’t do what you need without extreme complexity

If routine updates require complicated “hacks” or specialized coding, the tool’s architecture may be holding you back. No workflow optimization can fix missing core functionality or a rigid data model.

Example:

A popular CPQ solution promises flexible quote generation but forces users to build complex scripts for simple custom pricing rules. Every new pricing model becomes a week-long dev sprint instead of a quick field update, showing the tool’s inherent inflexibility rather than just a workflow issue.

2. Lack of Interoperability & Flexibility

Modern RevTech stacks depend on integrations between CRMs, automation platforms, data warehouses, and more. If a solution uses proprietary code or offers limited APIs, it can block key data flows and force “bolt-on” patches.

Example:

Salesforce is powerful but uses a custom Apex coding language. Integrating advanced logic or external data sources often requires specialized Salesforce developers, making even modest customizations an ongoing project. Over time, this friction can slow the pace of innovation—especially for smaller companies lacking dedicated Apex resources.

3. Performance & Scalability Issues

As your organization grows, tools must handle rising data volumes and usage. If a platform slows or breaks under increased load, you’re facing inherent scalability gaps—not just a data or workflow problem.

A marketing automation platform like Marketo can struggle with large databases (e.g., millions of records). Teams experience timeouts on segmentation queries and delayed email sends during peak campaign seasons. Despite cleaning inactive leads and optimizing workflows, performance problems persist, pointing to underlying scalability limitations.

4. Poor User Experience & Low Adoption

A clunky interface or convoluted navigation drives users toward workarounds. If training doesn’t solve the adoption gap, it’s likely the UI or design isn’t meeting their needs.

Example:

A customer support team tries a legacy ticketing system with an outdated UI. Agents complain about multi-step ticket creation and repetitive tasks. Even after multiple training sessions, they revert to private Slack channels for quick issue resolution. The system’s poor design, not a lack of ritual or training, is the real culprit.

5. Everything Feels “Broken” Without Specific Fixes

If you frequently hear “It’s broken!” but can’t pinpoint a clear solution, deeper architectural or vendor-related problems may be at play. Software that randomly fails, loses data, or creates untraceable errors often signals a fundamental product quality issue.

Example:

A mid-sized B2B company uses an eSignature platform that intermittently fails to generate documents correctly. Support can’t replicate the bug; it appears randomly and resolves itself after a few days. The repeated “ghost” errors sap confidence in the tool and waste team time—even the vendor struggles to provide a root cause.

5.3 Evaluating Your Tools

Once you suspect a tool may be causing issues, it’s important to conduct a thorough evaluation to confirm whether it truly requires replacement or if optimization could improve its performance. Here are four steps to help evaluate tools effectively.

Feature Gap Analysis

A feature gap analysis helps you identify critical functionalities that are missing from the current tool. This analysis can clarify whether specific features are essential to achieving business goals or if they are “nice-to-haves” that may not warrant a replacement.

• Example: A B2B company conducts a feature gap analysis on its CRM to determine whether it supports advanced lead scoring and segmentation. They find that while the CRM has basic segmentation, it lacks the necessary customizability for targeted campaigns. This missing functionality could justify considering a new CRM with more advanced lead management capabilities.

Guidance: List out essential features and compare them against what the tool offers. Determine whether workarounds or add-ons could bridge minor gaps or if the absence of key features significantly impacts productivity.

User Feedback

Gathering user feedback provides valuable insights into the tool’s usability, functionality, and alignment with day-to-day needs. Users who work with the tool regularly can often highlight pain points and identify where the tool may be holding them back.

• Example: A sales team expresses frustration that their CRM doesn’t support email templates, which forces them to manually draft repetitive emails. While this may sound like a minor issue, feedback from multiple team members reveals that this oversight wastes time and causes inconsistencies in communication. A CRM with built-in email template functionality would save time and improve customer outreach consistency.

Guidance: Hold feedback sessions and survey users to gauge their experiences with the tool. Ask about specific pain points, workflow interruptions, and any desired features that would improve their experience.

Vendor Assessment

Reviewing the tool’s vendor can offer insight into the tool’s potential to meet future needs. Assessing the vendor’s roadmap, support quality, and commitment to innovation can help determine whether the tool is likely to evolve with your business.

• Example: A manufacturing company relies on a niche inventory management tool, but vendor research reveals that the software hasn’t received updates in years, and the support team is slow to respond. The lack of updates and support indicates that the tool may become obsolete, making a switch to a more actively supported platform advisable.

Guidance: Evaluate the vendor’s long-term support, development roadmap, and reliability. Ensure that the vendor can provide timely assistance and plans to keep the tool current with emerging technology standards.

Switching Costs and Ease

Switching tools can be disruptive, both in terms of cost and time. While switching may theoretically be an option, the practical challenges—like internal resistance and mismatched data schemas—often mean it’s not worth the effort. Switching tools is rarely a quick fix and can introduce new complexities.

• Example: A B2C company considers switching from its existing CRM to a more modern tool. However, a data schema mismatch means they would need to reorganize customer records, which could lead to data accuracy issues. Additionally, team members are familiar with the current CRM, and switching would require retraining and temporary workflow disruptions.

Guidance: Consider switching only if the benefits clearly outweigh the costs and risks. A cost-benefit analysis can help evaluate whether the potential improvements justify the switch, taking into account both the immediate costs and the long-term return on investment.

5.4 Optimizing Before Replacing

In many cases, optimization efforts can extend the life of a tool and help it meet current needs, avoiding the disruption and cost of replacement. Here are some strategies for optimizing your existing tools before considering a replacement.

Configuration Tweaks

Sometimes, adjusting the tool’s configuration or making small changes to settings and workflows can significantly improve its performance and usability.

• Example: A marketing team struggles with a CRM that doesn’t automatically log customer interactions. Instead of switching CRMs, they explore configuration options and find that setting up custom workflows allows for automated logging. This configuration tweak solves their issue without requiring a new tool.

Guidance: Review the tool’s settings and explore configuration guides or support materials to ensure it’s optimized for your team’s specific workflows. Small adjustments can often solve issues that seem to require a new tool.

Third-Party Add-ons

Many tools support plugins or add-ons that extend their functionality, enabling you to bridge feature gaps without a full system overhaul.

• Example: An e-commerce company’s CRM lacks advanced reporting capabilities, but instead of replacing it, they integrate a third-party analytics tool that adds robust reporting features. The CRM and analytics tool work together, providing insights without replacing the CRM.

Guidance: Research add-ons or extensions compatible with your tool. Add-ons can often bring in critical functionality at a fraction of the cost and effort compared to replacing the tool.

Training

Sometimes, teams are unaware of the full functionality that existing tools offer. By investing in additional training, you can help team members leverage the tool’s features more effectively.

• Example: A customer service team believes the CRM lacks automated ticket assignment, but a training session reveals that this feature already exists. After training, team members use automated assignments to speed up response times, improving overall efficiency.

Guidance: Schedule regular training sessions to help teams stay current with tool features and learn best practices. This can help teams maximize the value of the tools they already have.

5.5 How to Make a Switch

If you’ve thoroughly optimized workflows and rituals but still face fundamental tool limitations, a structured approach to switching is crucial. Replacing any key system—be it a CRM, marketing automation platform, or customer success tool—can be disruptive if done hastily. Below is a generalized framework to guide you through a thoughtful, low-risk transition.

1. Document Why You’re Making This Change

• Historical Reasons: Capture the specific challenges (e.g., missing features, high cost, poor user adoption) so future teams understand why the switch happened. This context prevents a “pendulum effect,” where a new leader reverts to the old tool without realizing why it was replaced.
• Expected Outcomes: Clearly outline what success looks like—improved reporting, faster performance, better integrations, or all of the above. These goals act as a North Star throughout the migration process.

2. Develop a Change Management Plan

• Project Plan & Timelines: Lay out milestones (e.g., data migration, user training, final cut-over date) and assign owners. Include buffer time for unexpected hiccups.
• Success Metrics: Define how you’ll measure adoption, data accuracy, or performance improvements. Examples might include reduced manual work, fewer downtime incidents, or higher user satisfaction scores.
• Stakeholder Buy-In: Engage key users—sales, marketing, ops—early on. Gather input on critical workflows and incorporate feedback to minimize surprise roadblocks.

3. Backup Data in a Warehouse (or Equivalent)

• Preserve Historical Records: Before migrating, back up your data in a secure data warehouse (or other repository). This ensures you have a snapshot of everything if the transition hits snags.
• Confirm Data Mapping: Decide which fields must remain accessible (e.g., historical transaction data, engagement metrics). This clarifies how data will map into the new tool.

4. Run Both Tools in Parallel (If Feasible)

• Minimize Downtime: Operating the old and new systems simultaneously allows teams to get hands-on with the new tool without losing access to the old one.
• Phased Adoption: Gradually shift new leads, records, or interactions into the new system. This incremental approach eases the learning curve and reduces data mismatch risks.

5. Decide Where to Fix Data Quality

• Old Tool vs. New Tool: If data cleanliness is an issue, determine whether to cleanse it before migration (so the new system starts “clean”) or after (leveraging new tool features to streamline the process).
• Examples from the Field:
  • Sales Team Migration: One startup cleaned thousands of duplicate leads in their old CRM to avoid cluttering the new one.
  • Marketing Automation Switch: Another team waited to clean data in their new platform, which had AI-powered deduplication—a strategic move that saved time long-term.

6. End-of-Life the Old Tool

• Communication & Training: Provide a clear timeline for when the old system will be decommissioned. Offer training to ease any final reservations and ensure everyone knows how to do daily tasks in the new tool.
• Archival: If the old system contained specialized reports or custom objects, consider archiving them for reference. Keep read-only access for a set period in case users need historical lookups.

5.6 Case Study: Deciding to Replace a Slack Notification Tool

Situation

Provided by Justin Tung (Former Head of RevTech at Ramp)

At Ramp, we used a tool called Troops to integrate Salesforce notifications directly into Slack. Troops was originally inexpensive—sometimes effectively free—and gave our team real-time updates on key deals, pipeline changes, and other Salesforce activities without leaving Slack. However, once Salesforce acquired Troops, the pricing model changed, skyrocketing our costs. With a strict deadline to either pay the new fees or lose access, we had no choice but to evaluate replacement options.

In parallel, we also wanted to see if a new Slack notification solution could offer richer capabilities than Troops. For instance, we’d been using Troops for immediate deal notifications, but we hoped to also streamline certain operational workflows, provide sales reps with more autonomy in setting up their notifications, and possibly tie this tool into other RevOps processes.

Evaluation Process

1. Feature Gap Analysis
   1. Core Requirements: We needed real-time Slack alerts triggered by updates in Salesforce objects (e.g., Leads, Opportunities, Accounts). Our power users also wanted to filter by fields like opportunity amount, owner, or stage and receive notifications in specific Slack channels or via DMs.
   2. Wish List: Additional features such as consolidated or “compact” notifications for busy sales channels, advanced trigger criteria (e.g., multi-object triggers), and admin controls allowing “self-serve” creation of notifications for less technical users.
   3. Troops Shortcomings: While Troops covered the basics of posting updates to Slack, it lacked more sophisticated customization and reporting. The bigger deal-breaker was the drastic price hike after Salesforce’s acquisition.
2. Vendor Assessment
   1. Initial Options: We initially looked at two main alternatives:
      1. Rattle – Known for advanced Slack notifications and a strong reputation for reliability.
      2. Momentum AI – Similar in concept to Rattle, but at the time a younger product that appeared to be more flexible in negotiating pricing and feature development.
   2. Pricing Considerations: With Troops costing shifting upwards, both Rattle and Momentum AI offered more competitive tiers. Momentum AI, in particular, was motivated to win Troops customers, and provided significant pricing discounts to those willing to switch early.
   3. Product Roadmap & Migration Support: Momentum AI not only matched Troops’ key features but also offered direct assistance migrating existing Troops workflows. They had already been through this with multiple former Troops customers. Rattle, meanwhile, had a stable feature set and a strong support team but offered limited migration support compared to the very hands-on approach from Momentum AI.
3. User Feedback
   1. Sales & Marketing Needs: Our sales reps who heavily relied on Troops were concerned about losing real-time notifications. Marketing also used Slack notifications to track campaign-sourced leads. They wanted to preserve (and possibly improve) the format and frequency of notifications.
   2. Operational Complexity: Over time, we’d created more than 100 workflows in Troops—some crucial, others outdated. Our user community wanted clarity about whether we’d replicate them all, prune unnecessary ones, or standardize naming conventions and triggers along the way.
4. Risk Assessment
   1. Short Timeline: Salesforce gave us about two months to upgrade or lose access to Troops. We needed enough time to implement the new tool, migrate all workflows, and train users.
   2. Workflow Volume: With so many Troops workflows and uncertain metadata export capabilities, we worried some would get lost in transition. We identified a subset of “high-priority” workflows that must be live by the two month deadline to switch.
   3. Adoption & Downtime: Our biggest fear was that sales reps would miss time-sensitive deal notifications during the cutover. We documented the contingency plan in case new workflows malfunctioned or notifications failed to send.

Action

1. Change Management & Project Planning
   1. Project Justification: We clearly documented that the new Troops pricing was a non-starter. We also highlighted potential benefits of a more feature-rich Slack integration—making it easier for stakeholders to support the decision.
   2. Timeline & Milestones:
      1. By end of Week 2: Choose replacement (Rattle or Momentum AI).
      2. By end of Week 4: Migrate [insert number] core workflows.
      3. By end of Week 6: Train sales and marketing staff, finalize new naming conventions.
      4. By end of Week 8 (the two month deadline): Decommission Troops.
   3. Risk & Mitigation: The largest risk identified was incomplete workflow migration given the large volume. We dedicated a small SWAT team to auditing existing workflows, deciding which to keep, and standardizing their design. We also made sure to set up weekly check-ins with our selected vendor.
2. Data (Metadata) Backup & Preparation
   1. Since Troops primarily stored “metadata” (the logic behind each workflow, triggers, etc.) rather than extensive customer data, we exported or took screenshots of each workflow configuration. Where Troops didn’t offer a direct export feature, we relied on:
      1. Screenshots of the workflow logic
      2. Spreadsheet Documentation: For each workflow, we captured triggers, conditions, associated Slack channels, and owners.
      3. Priority Tagging: We labeled each workflow as “critical,” “nice-to-have,” or “outdated” to guide the order of migration.
3. Running Systems in Parallel
   1. Pilot in Momentum AI: Once we chose Momentum AI, we created a handful of pilot workflows in “low-impact” Slack channels to familiarize ourselves with the interface.
   2. Gradual Cutover: We launched critical workflows in the new tool after we were comfortable. For approximately two weeks, Troops and Momentum AI ran side by side. This allowed us to catch errors or misconfigurations in a small test environment without disrupting the entire sales org.
   3. Scheduling the Switchover: For major workflows that impacted multiple Slack channels, we turned off Troops late in the evening or over weekends to minimize user disruption.
4. Data (Metadata) Accuracy & Standardization
   1. Naming Conventions: We introduced standardized prefixes (e.g., [TEAM] – [Purpose] – [Trigger]) for each workflow, so users could identify what it did at a glance.
   2. Optimization & Clean-Up: During migration, we consolidated duplicative workflows and removed ones that hadn’t been triggered recently. We also refined trigger logic to reduce Slack spam (e.g., notifications only for deals over a critical threshold).
   3. Documenting Known Issues: We used an internal wiki for frequently encountered setup errors, known bugs, and short “how-tos.” Because Momentum AI was still evolving, we encountered a few initial bugs, which we tracked in a central list for quick resolution. But, one of the reasons we chose Momentum AI was their willingness to assist us with the transition - having a direct line of communication helped resolve any issues quickly.
5. End-of-Life for Troops
   1. Sunset Plan: Before the final shutdown date, we communicated extensively with all impacted teams. We shared:
      1. A timeline for the Troops shutdown
      2. Links to a new Slack #support channel or direct point-of-contact for issues with Momentum AI
      3. Training resources, including recorded demos, a live Q&A, and quick reference guides
   2. Validation & Sign-Off: After verifying that key workflows were functioning as expected in Momentum AI, we officially canceled Troops. No user downtime was reported beyond minor adjustments to Slack channel notifications.
   3. Ongoing Training & Feature Adoption: Our internal operations teams continue to refine Slack workflows, exploring advanced features in Momentum AI, such as multi-object triggers, advanced filtering, and expanded reporting.

Result

By switching from Troops to Momentum AI within just eight weeks, we successfully avoided Troops’ new high licensing fees. Our sales, marketing, and customer success teams maintained—and, in many cases, enhanced—their real-time Slack visibility into Salesforce data.

• Cost Savings: We reduced annual spend substantially [exact figures redacted].
• Enhanced Features: The new tool offered more flexibility in building and managing Slack notifications. Users could self-serve new workflows, which cut down on manual tasks for the RevOps team.
• Streamlined Adoption: Thanks to the parallel run, naming conventions, and thorough documentation, user disruption was minimal. Many workflows were improved or consolidated during the migration, reducing channel clutter.

Ultimately, the project showcased how a forced transition, triggered by a vendor’s price change, can become an opportunity to optimize processes, implement better tooling, and ensure robust documentation for future growth.