Signal Router

Overview

Signal Router is the actionable view of the fast lane: the sub-five-minute path beside the daily schedule for signals that lose their value in minutes. An inbound form, a champion leaving, a usage spike, each arrives, is classified, and gets a play. This page shows what happened to each one and what it needs from you next.

The hand-off each play produces

Every routed signal produces a concrete hand-off, deterministically from its play. An inbound lead (route-and-book) drafts a reply proposing meeting times for you to approve and send. A usage spike queues a cscron expansion play; a usage drop queues a cscron save play; a champion change alerts the AE on salescron; a high-intent visit queues gtmcron enrichment and scoring. The router recommends and drafts, a human approves: nothing is booked or sent automatically, and route-and-book never holds a slot until the buyer picks one.

Signals from outside your own world

Everything above starts with somebody already knowing about you: your form, your product, your thread. Three more kinds start at a company that has not met you yet, and they are where new pipeline comes from.

Hiring. Three times a day the platform reads the public job board of each of your target accounts and checks the open roles against the buyer titles in your GTM dossier. A match raises a hiring signal naming the roles, and the account goes for enrichment and scoring. Not "they are hiring", which is true of everybody: a company hiring into the function you sell to has a budget and a gap. Set your buyer titles under GTM Context Dossier or nothing here fires, which is deliberate. An unfiltered feed is noise, and noise teaches you to ignore the page it arrives on.

Boards are found from the account itself when it names one and otherwise from one guess at the company's domain. A guess that comes back empty is remembered, so a company with no public board is asked once rather than forever. Only Greenhouse and Lever are read today, because those are the two that publish a company's roles without a login.

New funding. Every fortnight the platform asks your enrichment provider whether a target account has closed a round, and raises a signal naming the stage and the total when one is newer than what it already held. Funding runs on a tighter clock than hiring once it fires, because a round is contested news. A round we see for the first time that is more than four months old is recorded quietly rather than announced: it is a gap in our records, not something that just happened, and without that rule every account would raise a funding signal on its first sweep.

Job changes. Once a month the same provider is asked where each of your contacts works now. An employer that no longer matches the one on their record raises a signal naming both companies, and it alerts the rep who owns the relationship rather than starting an automation, because only they know what the old seat was worth. The comparison is on domain where both sides have one, so a company renaming itself is not reported as somebody leaving. The contact record then follows the person, which is what stops one move being announced every month.

What these two cost, and how that is capped. Hiring is free: job boards are public. These two are lookups against your enrichment provider, which bills a credit each, so all three gates apply before a single one is made. The deployment needs a provider key. Your enrichment budget has to have room, and every credit spent here is charged against the same cap the enrichment panel spends from. And each account or contact is only re-checked when its own clock is up, at most twenty lookups per account per run. Out of budget, or no key, and the free hiring feed keeps running while nothing is spent and nothing is invented.

You can also push either signal yourself from a source you already have. Post to /api/webhooks/signal/[source], naming your feed in the last segment, with type set to funding-round or job-change. Your ingest key identifies the account, so a feed can only write where its key points.

SLA and escalation

Each signal carries a target response time (five minutes for an inbound lead, thirty for a churn signal). The page tracks whether each met its SLA and reports the adherence rate. When a signal breaches its SLA and is still unhandled, it escalates: first notify the owner, then, once a full SLA window has passed, reassign it so a slow owner never sits on a hot lead. Mark a signal handled when you have actioned it, or reassign a breached one.

Nothing is fabricated

A signal with no play is recorded only, not acted on. The SLA status, the escalation, and the proposal draft are all derived deterministically from the signal, so the same signal always produces the same hand-off, and nothing here is a completed action the system did not actually do.

When an action fails

Marking a signal handled, or reassigning a breached one, tells you if it did not save. The row is left exactly as it was, and without a message that is indistinguishable from a click that never fired.

How it is shown

The board leads with four tiles (routed count, SLA adherence, notify-owner escalations, reassign escalations) and a routed-signals table: each row shows the signal and its subject, the play and owning lane, the SLA and escalation status, the hand-off summary with the proposal draft inline where the play produced one, and the handled or reassign action. Every value is the deterministic router's output, in the same design system as the rest of the app.