Most companies treat the org chart as a seating plan. Boxes with titles in them, arranged by who reports to whom, redrawn whenever someone leaves. It describes the furniture. It does not describe the work.
I spent years building one that did the opposite, for reasons that had nothing to do with automation, because automation was not available. In late 2024 that turned out to matter more than anything else I had done, because an org chart built from functions and workflows is a specification, and a specification can be handed to a machine. An org chart built from titles cannot. There is nothing in it to execute.
This is an account of what that made possible, written at the level of method. It is not a product and it is not for sale.
How a 197 person organization across three continents was structured
At its largest the organization I ran was 197 people in 11 teams across three continents: Chennai, Mumbai, Beijing, Europe and Silicon Valley. I visited every office, hired into every team myself and trained them.
Three rules held it together, and only the first one is unusual. All three are downstream of treating go-to-market as an engineering problem rather than a creative one.
Functions were defined, not titles. A team was specified by what it was accountable for producing, which skills that required, and the sequence of steps it ran. Titles were attached afterward, as compensation and career artifacts. Nobody’s scope was defined by their business card.
Vertical lines were solid, horizontal lines were dotted. Accountability ran up a single line. Collaboration ran sideways with no authority attached to it. That distinction prevents the most common organizational failure, which is work that two teams both touch and neither owns.
Every workflow was written down. Not as policy documents. As the actual sequence of steps a given function performed, in order, with the inputs each step needed and the output it produced.
The third rule is the one that felt like bureaucracy at the time. It was the only one that mattered later.
Why buying AI tools produces nothing and converting a workflow does not
By late 2024 the tooling had arrived. Most of the market responded by buying something: a platform, a data vendor, a sequencer. That is a reasonable instinct and it is why most of those projects produced nothing. A tool automates a step. The step most companies skip is the one that would have told it what to do. It cannot automate a workflow it has never been told about, and in a title-based organization nobody can tell it, because the workflow lives in the heads of the people performing it and changes shape every time one of them is replaced.
I had the workflows already. Written down, step by step, because of a decision made years earlier for completely different reasons. The conversion was not an act of invention. It was transcription.
What came out of it is a signal based revenue acquisition infrastructure. It is not purchasable and not subscribable, because what it encodes is a specific organization’s definition of its own work.
How a marketing data team was replaced by an automated workflow
The first team converted had been the marketing database function. Several tools, manual research, manual verification, people cross-referencing sources to decide whether a company was worth contacting and whether a contact was real.
That entire sequence now runs without a person in it. A signal is detected. Based on what kind of signal it is, new data is pulled. That data is cross-checked against the existing database. Each resulting company is graded against the ideal customer profile and prioritized. A message is written for the specific situation and sent to the priority list.
Note what did not happen. The function was not replaced by a tool that does research faster. The function was replaced by the workflow it had been performing, executed by software, including the judgment calls, because the judgment calls were already written down as decision rules rather than living as professional intuition.
What an SDR actually spends the working day doing, measured
The second was deliberately done at the same time, because automating data production without automating what happens downstream of it just moves the bottleneck.
The baseline was measured before anything changed. A warm reply arrived in a chat channel and whoever typed “on it” first owned it. Each lead then cost roughly 17 minutes of work that was not a phone call: five to ten minutes researching across browser tabs, five to ten minutes typing the call into the CRM, three to five minutes writing the confirmation email. At fifteen leads a day, 31 percent of the day went to calls and 56 percent went to research, data entry and writing email.
That is the real finding, and it is worth sitting with. The function was defined as a calling function. It spent a minority of its time calling. What that time costs per appointment, and what an appointment is worth, is a separate calculation.
Now: every reply is read and graded by the system and posted to the chat channel with the email thread attached and the CRM record already created. A neutral reply from a real person becomes a card that says “call to qualify.” At 7am a dial sheet lists the ten hottest accounts with the name, the title, the number and the reason the account is hot. After a booking, the caller posts it once and the system researches the company, routes it to the right territory, sends the calendar invite, the internal briefing and the prospect’s confirmation, and updates the CRM. The day before each meeting, a confirmation list is generated.
The two purely clerical steps, CRM logging and the confirmation email, came to about 2.2 hours a day and are no longer done by hand.
One deliberately human piece remains. Qualified replies surface in a shared channel where callers compete for them, and the lead goes to whoever claims it first, on the condition that they are dialing within three seconds. Speed to first dial is the one variable where a person still outperforms a queue, so it was left alone.
What counts as a buying signal in B2B outbound
A signal is a public event that changes what a specific kind of company is worried about this week. The system runs at 7am on weekdays and posts a single brief.
A peer is attacked. A breach or ransomware disclosure involving one company is used to find structurally similar small firms in the same state and industry. The outbound message never names the victim and never references the specific incident. The relevance is categorical, not voyeuristic, and the distinction is not a courtesy. A message that names a victim is a message about somebody else.
A software flaw is being actively exploited. The flaw is tagged with every industry that runs the affected software, and those industries are contacted nationally.
A rule changes. A new regulation or enforcement action affecting a specific industry becomes a campaign for that industry.
A company starts hiring for a technical role. The job posting is itself the signal, and the decision-maker at that company is approached directly.
A company shows interest on its own. Email replies, form submissions, visits to high-intent pages. These are graded and they decay: flagged as stale after 21 days, dropped after 60.
The source list expands on a schedule. Consumer protection enforcement, federal health data breach reports, state registries and local business press are specified and queued.
How a signal is cross-checked before anyone is contacted
Signals are the easy half and the half everyone focuses on. The hard half is the cross-check, because an untested signal produces volume, and volume in outbound is worse than silence.
When an external event arrives, it is first screened for relevance: does this touch small businesses in the served markets, and which industries and states. Then a database lookup, not a language model, converts a named victim, who is usually far too large to be a prospect, into a count of structurally similar small firms in the same state and industry.
A contact only comes out the other side if all of the following hold. They work at a company in the target market. They are senior enough to decide. The phone number resolves. They have never been contacted before. They are not on the do-not-contact list. And they are not already somewhere in the sales process.
That last check runs live against the CRM and it covers the entire company, not the individual. If any colleague at the firm already has a meeting booked, has declined, is already a customer or has opted out, the firm is dropped. Two further limits: nobody is contacted for two signals on the same day, and an account appears once per signal.
Most of the design effort went here. Most of the value did too.
Why industry codes and job titles are the wrong way to target a market
The organizational principle, functions rather than titles, turned out to apply to the market as well, and this is the finding I would most want a skeptical reader to test.
Companies were being classified by their official industry code, and the code is wrong. Measured against live data for one target industry, the code was wrong about 25 percent of the time on firms that were in fact targets: adjacent businesses had filed under that code. It was wrong about 50 percent of the time in the other direction, meaning half the real firms in that industry had filed under something else and were being missed entirely. The classification now reads each company’s own description of itself and grades on a single question: would this firm buy what is being sold.
People were being classified by job title, and a title is only meaningful at scale. A technical manager title is treated as the technical buyer only above 20 employees, because below that the title exists without the authority. An office manager counts as the operations buyer only above 15. In owner-operated firms under roughly 50 people, the owner is the buyer regardless of who else holds a title.
Both of these are the same move. Stop trusting the label. Grade on the function.
Why a first party data loop compounds and a purchased list does not
Every interaction writes back. Replies, form fills, identified visitors, call transcripts, what converted and what did not. The database is better this month than last month and will be better next month, and the improvement is a property of running it rather than a project someone has to schedule.
This is the part that cannot be bought, and it is also the part that cannot be caught up on. A competitor who starts today starts with an empty table.
How website testing connects to outbound messaging
Outbound and the website were two separate disciplines in every organization I have worked in, and the separation is indefensible. The same person reads the email and then lands on the page, which makes conversion rate optimization a continuation of the message rather than a discipline of its own.
So the site runs its own instrumentation, built as a custom extension rather than assembled from plugins, using AI coding tools, which is the only reason a marketing function could own it without a development team.
What it measures is behavior, not sentiment: pages viewed, which sections were actually scrolled to, clicks on buttons and phone numbers and email links, forms seen and started and submitted, and which campaign, referrer and device brought the visitor.
What it changes: one element of a page, a headline or subheading or button, is swapped for half of visitors, and each visitor keeps their version across the session. A version wins on click and form-start rate once it is more than 90 percent likely to beat the original, with a minimum of 300 visitors per version. Every form submission carries the version the visitor saw into the CRM, so a page variant can eventually be matched to a booked meeting rather than to a click.
Testing is live and running.
The next build joins the two halves. A visitor who arrives from a given email sequence is shown the page version that matches the email they just read. Outbound messages are tagged by persuasion stage, persona and the cue they lead with, and reply and meeting rates are compared by tag, so the page and the message stop being separate experiments and become one.
Why a signal based revenue system cannot be bought
It is one organization’s definition of its own work, written down over several years for reasons unrelated to automation, then executed by software.
The reason it is not purchasable is not that the components are exotic. The components are ordinary: a scheduler, some scripts, a database, a language model doing classification, a CRM. The reason is that the specification is the asset, and a specification is the one thing a vendor cannot sell you, because it is a description of you.
Which brings it back to the org chart. If the work is defined by who sits where, there is nothing to transcribe. If it is defined by what each function produces and in what order, the transcription is mechanical and the hard thinking was done years ago by someone drawing boxes for entirely different reasons.
New writing, when there is some
No schedule, no forwarding your address, one click to leave.