> For the complete documentation index, see [llms.txt](https://docs.reo.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.reo.dev/playbooks/for-sdrs/turn-competitor-evaluation-signals-into-pipeline-for-your-target-accounts.md). # Turn Competitor Evaluation Signals into Pipeline for your Target Accounts * [Introduction](https://docs.reo.dev/playbooks/for-sdrs/turn-competitor-evaluation-signals-into-pipeline-for-your-target-accounts#introduction) * [Step 1: Set Up Your Competitor Signals](https://docs.reo.dev/playbooks/for-sdrs/turn-competitor-evaluation-signals-into-pipeline-for-your-target-accounts#step-1-set-up-your-competitor-signals) * [Step 2: Apply the Signals to Your Target Accounts](https://docs.reo.dev/playbooks/for-sdrs/turn-competitor-evaluation-signals-into-pipeline-for-your-target-accounts#step-2-apply-the-signals-to-your-target-accounts) * [Step 3: Gauge the Signal and Decide How to Act](https://docs.reo.dev/playbooks/for-sdrs/turn-competitor-evaluation-signals-into-pipeline-for-your-target-accounts#step-3-gauge-the-signal-and-decide-how-to-act) * [Step 4: Reach Out at the Right Time](https://docs.reo.dev/playbooks/for-sdrs/turn-competitor-evaluation-signals-into-pipeline-for-your-target-accounts#step-4-reach-out-at-the-right-time) * [Step 5: Set Up Slack Alerts](https://docs.reo.dev/playbooks/for-sdrs/turn-competitor-evaluation-signals-into-pipeline-for-your-target-accounts#step-5-set-up-slack-alerts) {% hint style="info" %} πŸ“Œ **Need help at any point?** If you need support implementing this playbook end to end, contact your **Account Manager** or write to us at . {% endhint %} #### Introduction By the time a prospect appears in your CRM, they may have already been evaluating your competitors for weeks. Reo.Dev surfaces this evaluation activity as it happens, giving you a window to engage before a shortlist gets finalized. This playbook shows you how to set up two types of competitor signal tags in Reo.Dev, layer them onto your existing working segment, and reach out in a way that is genuinely useful rather than generic. The **two signal** types covered are: * Developer activity on **competitor GitHub repositories** * Technographic data from a company audience built around competitor tech stacks. Both indicate **β€˜in-market’ signals.** Together, they help you identify which accounts in your pipeline are worth prioritizing right now. *Let's set this workflow in 5 steps.*
#### **Step 1: Set Up Your Competitor Signals** Before you can filter your working segment, you need to create the tags (custom signals) that carry the competitor intelligence. This is a one-time setup that runs in the background from then on. You will create two types of tags: one based on GitHub activity on competitor repositories, and one based on a competitor tech stack company audience
#### **Step 1a: Create a Competitor GitHub Activity Tag** > **🎯 Prerequisite:** Competitor GitHub repositories must be added and tagged as **`"Competition"`** in your Reo.Dev integrations before this step will work. Refer to the [GitHub repository setup guide](https://docs.reo.dev/integrations/connect-github-repositories) to configure this first. It is a simple 1-min setup process. Once your competitor repos are connected, go to Segments and create a new Basic segment for **Accounts.** Name the tag something short and descriptive that you will immediately recognize when you see it as a filter, for example: `Comp GitHub Active`. {% hint style="info" %} **Segment Criteria:** * **Segment:** Basic * **Segment Type:** Accounts * **Segment Filters:** 1. **Under Activity Group - GitHub Repository** - **Repository Owner** - Includes any - **{Select the Specific Competitor Repository Owner/s}** 2. **Under Activity Type - Github** - Includes any - Select **all** ('Fork,' 'Star,' 'Opened Issue,' 'Pull Request,' 'Watch,' 'Comment.’) 3. **Under Activity Type - Github Date Range**: is set to **"Last 60 days"** (you can extend it further, but we would recommend to not go beyond 90 days to factor in for recent engagement) 4. Use the "**Matches All**" operator so that all filters are applied collectively. {% endhint %} Save and exit. Reo.Dev will now automatically tag any account where developers have engaged with your tracked competitor repositories within that window. **Example:** Say you are building an observability platform that competes with Grafana, Prometheus, and OpenTelemetry. Your competitor GitHub tracking would include repos like: * `grafana/grafana` * `prometheus/prometheus` * `open-telemetry/opentelemetry-collector` Any account in Reo.Dev where developers have forked, starred, opened issues on, or commented in these repositories in the last 60 days will automatically receive the `Comp GitHub Active` tag. That tag is now available as a filter across your entire accounts view. > **🎯 Pro tip:** If you want more granular tracking, create separate tags per competitor (e.g., `Grafana Active`, `Prometheus Active`). This lets you tailor outreach messaging based on which specific tool they are evaluating. #### Step 1b: Create a Competitor Tech Stack Company Audience
The second tag comes from a company audience built around competitor technologies. This surfaces accounts that are already using or actively investing in a competitor's tech stack, even if no developer from that account has engaged with your assets yet. Navigate to Audiences and create a new Company Audience. Under the Technographics section, add the competitor technologies you want to target in the Technology field. **Example (continuing the observability platform example above):** Your company audience would include technologies like Grafana, Prometheus, Datadog, and New Relic. These are the tools your ICP is currently using that your platform either replaces or competes with directly. > **πŸ”—** [**Guide on How to Create a Company Audience**](https://docs.reo.dev/audiences/company-audience) {% hint style="info" %} πŸ“Œ **Pro tip:** Layer in the Hiring Intent section as well. If the companies in this audience are hiring for a specific role that signals investment in a competitor's tech, that is a strong buying signal worth capturing. {% endhint %} For an observability platform, the relevant persona is typically a **Senior Platform Engineer, Site Reliability Engineer,** or **Head of Infrastructure.** These are the same personas who would evaluate and champion your tool internally. Adding a hiring signal for these job titles inside the audience strengthens the quality of accounts surfaced. Once you have defined your audience, give it a clear, descriptive name that reflects the competitor context, for example: **`Competitor Observability Stack`.** Reo.Dev automatically creates a tag based on your audience name. That tag, **`Competitor Observability Stack`**, will immediately appear as a filter option in your accounts view, ready to layer onto your working segment. #### Step 2: Apply the Signals to Your Target Accounts With both tags now set up, go to your existing working segment. This could be your default account view, a named account list, or your territory segment. You do not need to edit the segment itself.
In the accounts view, click Add Filter and select Tags. Choose one or both of the tags you just created: `Comp GitHub Active` and `Competitor Observability Stack`. Accounts matching your competitor tags will now appear filtered within your existing working list. No new segment needed, no rebuilding your existing setup. **How to prioritize what you see:** Accounts tagged with both `Comp GitHub Active` and `Competitor Observability Stack` are your highest priority. They are using a competitor tool and developers are actively engaging with that competitor's OSS repo, which points to a live evaluation in progress. Accounts with only `Comp GitHub Active` are worth prioritizing next. Developer-level engagement with competitor repos is a strong, specific signal of active research. Accounts with only the company audience tag indicate technographic fit and potential competitive displacement opportunity, even without confirmed active evaluation. **Don’t have your list of target accounts setup yet?** Then we recommend this playbook first: [Find Net New Opportunities in your Territory](https://docs.reo.dev/playbooks/for-sdrs/find-net-new-opportunities-in-your-territory) #### Step 3: Gauge the Signal and Decide How to Act
Not all competitor signals carry the same weight, and the right action depends on which signal surfaced the account. #### **A) For accounts surfaced by the competitor tech stack company audience:** This is a technographic signal, not a behavioral one. It tells you the account is likely invested in a competitor's stack and is therefore a strong candidate for a competitive displacement play. You do not need to wait for deeper evaluation signals here. The right move is to **run a competitive takedown campaign** targeting these accounts. Depending on how your marketing team operates, this can take a few forms: targeted ads run against the account list, an email cadence to the right buyer contacts, or a LinkedIn outreach sequence. The accounts themselves are ready to hand off to marketing. #### **B) For accounts surfaced by the competitor GitHub activity tag:** This is a behavioural signal and it warrants a closer look before acting. Open the account in Reo.Dev and launch CoPilot with this prompt: > **✦** "Who are the active developers from **{Company Name}** engaging with {competitor} GitHub repositories? What is the recency, frequency, and type of their activity, and how deep does the evaluation appear to be?" What you are looking for is propensity, not just presence. A single star from an anonymous developer is very different from three de-anonymized engineers who have forked the repository, opened issues, and are submitting pull requests over the last 30 days. **If the activity is shallow** (a single star, one anonymous developer, no recent follow-up), there is no need to rush. Add the account to your watch list and let the Slack alert from **Step 5** tell you when the signal strengthens. **If the activity is meaningful** (multiple de-anonymized developers, a mix of forks, issues, and pull requests, activity within the last 30 days), you have a live evaluation window. Do not wait. **Move to Step 4** for direct outreach, and simultaneously loop in your marketing team to run ABM campaigns warming up these accounts in parallel. The same competitive takedown campaign approach applies here. Running both motions at the same time, direct sales outreach and marketing-led account warming, maximizes your chances of getting in front of the right people before the evaluation concludes. **The strongest signal of all** is a developer who is active on competitor repositories and your own product assets at the same time. That combination tells you the account is not just exploring, they are actively comparing, and you are already on the shortlist. These accounts skip the watch list entirely, go straight to **Step 4,** and are your highest priority for the parallel marketing motion described above. #### Step 4: Reach Out at the Right Time The propensity read on competitor GitHub activity from **Step 3** should directly shape how you engage and how urgently. **If the activity is shallow** (a single star, one anonymous developer, no recent follow-up), there is no need to rush. Add the account to your watch list and let the Slack alerts from **Step 5** tell you when the signal strengthens. **If the activity is meaningful** (multiple de-anonymized developers, a mix of forks, issues, and pull requests, activity within the last 30 days), you have a live evaluation window. Move fast & reach out to right contacts now. The accounts where both signals overlap, active GitHub evaluation and confirmed competitor tech stack, are your highest priority. Engage both the developer and the buyer in parallel, each with a message angle shaped by what you know about the competitor they are up against. {% hint style="info" %} ✏️ **An Important Note on how to go about the messaging:** When you do reach out, the GitHub activity should inform your timing and your messaging angle, not your message content. Do not reference what you have seen them doing on a competitor's repository. That can come across as invasive and will likely backfire. The signal is for you, not for them. What it does tell you is which competitor they are evaluating. Use that to shape the angle you lead with. You know your competitors better than anyone: where they fall short, what they cannot do well, what customers consistently run into when they try to scale with them. Lead with the pain points your product genuinely solves that the competitor they are evaluating does not handle well. That is your edge, and it is one you do not need to explain the source of. For accounts surfaced only through the competitor tech stack company audience, the same principle applies. Use the technographic context to inform which competitive angle is most relevant for that account's situation, then let your product's strengths carry the message. **Related case study:** [**22% LinkedIn Response Rate: How Kubegrade Used Reo.Dev’s GitHub Intent Signals**](https://www.reo.dev/customer-stories/kubegrade) {% endhint %} #### Step 5: Set Up Slack Alerts Competitor evaluation windows are short. You need to know the moment something significant happens at one of your target accounts on a competitor repository. The key word here is **significant.** A single GitHub star or a one-off repo visit is not a signal worth interrupting your day for. What you actually want to be alerted on is when an account has crossed a threshold that indicates a sustained, active evaluation is underway. This step sets up one focused automation alert built around that threshold, so every notification you receive is worth acting on. Before you begin, make sure your Slack workspace is connected to Reo.Dev under **Settings β†’ Integrations.** > **πŸ”—** [**Slack integration guide**](https://docs.reo.dev/settings/configure-slack-and-email-notifications) #### Step 5a: Create a Competitor GitHub Activity Developer Segment for your Target Accounts The threshold logic lives in the segment itself. This gives you the full power of Reo.Dev's advanced segment filters to define exactly what qualifies as meaningful competitor GitHub engagement before an alert ever fires. Go to Segments and create a new **Advanced segmen**t. Set the Segment Type to **Developers.** {% hint style="info" %} ✏️ **Segment Criteria:** * **Segment:** Advanced * **Segment Type:** Developers * **Segment Filters:** **Filter Group 1 (AND operator): Your target account list** * **Lists: (Accounts)** Includes any β†’ select your uploaded target account list (e.g. `John's Target Accounts - Feb 26.csv`) \*\*\*\*You can even do it via CRM owner field or based on your territory here **Filter Group 2 (AND operator): Competitor GitHub activity threshold** * **Repository Name** Includes any β†’ select your specific competitor repository (e.g. `Unleash`) * **Activity Type: GitHub** Includes any β†’ Fork, and all other relevant GitHub actions (Star, Opened Issue, Pull Request, Watch, Comment) * AND **Activity Count** Greater than **6** * AND **Last Activity Date** is **Last 30 days** {% endhint %} {% hint style="info" %} **✏️ A note on tracking multiple competitor repositories:** If you are tracking more than one competitor repository, create a separate filter group for each repository rather than combining them into the same group. The reason is that grouping multiple repos together pools the activity count across all of them. This means an account with three GitHub activities on one repo and four on another would qualify, even though neither repo individually crossed a meaningful threshold. Keeping each repository in its own filter group ensures the activity count threshold applies per repo, so every alert you receive reflects genuine sustained engagement on a single competitor's codebase, not scattered activity spread across several. {% endhint %} This segment criteria filters out shallow one-off interactions and surfaces only developers whose engagement is sustained and recent enough to indicate a live evaluation is in progress. {% hint style="info" %} ✏️ **Pro tip:** If you find you are getting too many alerts, raise the activity count threshold to **8 or 10** or more. If the list is too narrow, bring it down to 3 or 4. The right threshold depends on how actively your target accounts engage with your **competitor OSS repositories** in general. {% endhint %} Now, lets setup the automation to ensure nothing slips through the cracks. #### Step 5b: Setup the Slack Automation πŸ“Œ **Note:** You can only build automations on segments that you own, meaning segments you created yourself. Navigate to **Tools β†’ Automations** and click **Create Automation.**
* **Source:** The **developer segment** you created above * **Trigger:** New Developer Added to a Segment * **Conditions:** None * **Action:** Get Alerts via Slack > **πŸ”—** [**Automations setup guide**](https://docs.reo.dev/automations) Because the threshold logic is already baked into the segment, the automation itself is clean and simple. A developer only enters this segment once they have crossed the activity count and recency criteria you defined above. Every alert you receive therefore represents a de-anonymized developer at one of your target accounts who has demonstrated sustained, recent engagement with a competitor repository, exactly the signal that warrants your attention. This sets the stage for you to target them and build new pipeline before the evaluation window closes. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.reo.dev/playbooks/for-sdrs/turn-competitor-evaluation-signals-into-pipeline-for-your-target-accounts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.