Revenue Engineering for B2B
Your CRM will be configured correctly. That is not the same as producing revenue.
Most B2B CRM projects are built by people who know the tool and have never watched one fail. I design the revenue engine first, then we install it on HubSpot or the platform that fits, so the system produces qualified pipeline instead of clean data nobody acts on.
I'm Alex Chiang. For 18 years I've built revenue systems from the marketing side, the sales side, the engineering side, and the data side. I was HubSpot's first partner in Taiwan and have run implementations from one-person companies to multi-billion dollar groups. What that experience gives you is not more features. It is foresight: knowing where a revenue system breaks before it does.
Do you recognize this moment?
The CRM went live eight months ago. The data is consolidated. Everyone has a login. The dashboard is beautiful. And the sales team still asks marketing, "where are the good leads?"
Or this one. Your marketing team has 400 tags. Nobody remembers who created half of them. Every contact who ever attended a webinar is marked "high interest," so segmentation means nothing, so campaigns go to everyone, so the unsubscribe rate climbs.
Or this one. An engineer at a target account downloaded two datasheets from the same product line in one week. The system saw it. Nobody was told. Three weeks later a competitor's distributor booked the design-in.
You bought the platform. You hired a partner. They configured it exactly as specified. Every item on the checklist was delivered.
The problem was never the configuration. The problem is that nobody decided what the system was supposed to do before it was built.
Why does this keep happening to well-run companies?
Because a CRM project is bought and scored as an IT project. Marketing pays for the software. IT pays for maintenance. Vendors are compared on certificates and hourly rates. And the layer that determines whether the system produces revenue, the design layer, has no owner, no budget line, and no line on the scoring sheet.
Every implementation has three layers. The first is the build: one customer ID, consolidated data, integrations, permissions, training. Any competent system integrator can deliver it. The second is the design: what gets tagged, what a score means, when sales is told, what happens after someone logs in, how the funnel is defined. The third is operation: reading the numbers after go-live, finding where conversion drops, testing the fix.
Most projects buy layer one, assume layer two comes with the software, and never budget for layer three. Then they wonder why the system is clean and quiet.
This isn't a failure of your team. It's a failure of the category. The people who sell the build don't know the design layer exists, and the people who know marketing have never had to design a system that runs it.
Picture a Tuesday morning six months after go-live.
Your marketing manager opens one report. Not fifteen. It shows last month's webinar: who registered, who attended, who stayed past the pricing slide, who downloaded the reference design afterward. Twelve of them crossed the threshold. Twelve were routed to the right regional rep within the hour. Nine were contacted. Three became opportunities. The report says so, because the reps closed the loop in the same system.
- 01Reads article
- 02Attends webinar
- 03Downloads datasheet
- 04Score crosses threshold
- 05Rep notified in one hour
Your IT manager hasn't heard from the vendor in three weeks. The identity adapter runs in your own cloud, with your keys, reviewed by your engineers. Nothing about the system depends on anyone outside the building.
And the tag list is still under sixty, because there's a naming rule and an owner, and the tags that should expire, expire.
Nothing about this is magic. It's what a revenue system looks like when somebody decided, before the build, what it was for.
How it works
Revenue Engineering is the discipline of designing how marketing, sales, data, and technology connect into a system that produces qualified pipeline. The tools change every few years. The design questions don't.
I run engagements in the same order every time, because the order is the method.
Step 1: Architecture before tools.
We start with fifty decisions, not a feature list. Who is the buyer at your customer's company? What is a lead in your words? Which key wins when two systems disagree about a person? What does sales do in the first hour after a hot lead appears? You bring the market knowledge. I bring the consequences of each answer, because I've watched every one of them go wrong somewhere.
Step 2: The failure review.
Before we design anything, I show you where your current plan will break. Social login with no journey behind it. Scoring with no feedback from sales. Tags with no decay. Dashboards nobody has to act on. These aren't hypotheticals. They're the five most common ways a B2B revenue system dies in month four, and every first brief I've ever read has at least three of them.
- 01
No journey after login
people log in, nothing happens, the feature is dead in sixty days.
- 02
No sales feedback loop
hot leads pile up, sales ignores them, marketing blames the model.
- 03
Tags with no decay
in a year every contact is high interest and segmentation means nothing.
- 04
No ownership across entities
two subsidiaries email the same engineer the same week.
- 05
Dashboard nobody acts on
beautiful, reviewed once, forgotten.
Step 3: Platform fit.
I don't care which software you buy. HubSpot for most B2B marketing and sales teams. Something heavier when the organization needs it. The architecture decides. Saying that out loud is what makes me the architect and not the software salesman.
Step 4: Build with the least custom code that works.
Your system should run on native features your own team can maintain. The one place custom code is unavoidable, usually identity resolution across channels like WeChat, we write it, your engineers review it, and it runs in your cloud with your keys. You keep it if we part ways.
Step 5: Operate the engine.
After go-live, we read the numbers together. Where does conversion drop? Is it the email, the offer, the routing, or the direction? We test, we adjust, we teach your team to do it without us. That's the part nobody budgets for and the part that produces the revenue.
What makes this different:
Most firms in this category are one of two things. System integrators who know the tool and have never run a marketing campaign. Or marketing agencies who know campaigns and have never designed a data model. I've been on both sides, plus the sales side, plus the engineering side. The value isn't that I do all four. It's that I know where the seams between them break.
I didn't set out to become a revenue architect. I set out to build a game.
Eighteen years ago, in a startup accelerator in Taipei, my co-founders and I built a Facebook social RPG. It passed a million downloads, we localized it into Traditional Chinese, English, Japanese, and Russian, and we ran it with distributors in several markets. I was the one reading the numbers every day: who installed, who came back, who paid, who quit at which level. That's where I learned that a product doesn't grow because it's good. It grows because somebody designed the system that turns attention into revenue and watched every step of it.
The game did well. What changed was the economics and the direction of the market. Acquisition costs climbed until the lifetime value of a player no longer covered them, and players moved to mobile. So we pivoted. That is where I learned that a revenue system lives or dies on the relationship between what a customer costs and what a customer is worth, and that the model matters as much as the data.
I went into B2B sales to learn how enterprises actually buy. I went into digital marketing across more than fifty industries to learn how demand is created. I became HubSpot's first partner in Taiwan and have run it for nine years, from one-person companies to public groups with billions in revenue. I learned to code because I got tired of engineers telling me a design wasn't possible. Along the way I built and ran customer service systems, sales pipelines, and multilingual AI agents for companies that sell hardware around the world.
Every one of those was a chance to watch a revenue system succeed or fail, and to understand why.
That's the asset. Not a certification. A catalog of what breaks, earned the expensive way, so your project doesn't have to earn it again.
Proof
[Proof section placeholder: two client stories to be added before publishing]
"He gives the most practical and sincere advice."
- HubSpot's first Solutions Partner in Taiwan, nine years, Gold tier
- Implementations from one-person companies to multi-billion dollar groups
- Fifty-plus industries on the marketing side
- Built multilingual AI customer service agents on HubSpot for a global hardware brand
Tell me a little about where you are.
Thirty minutes. I'll ask about your buyer, your sales motion, and your stack. You'll leave with at least two things in your current plan that will break and what to do about them. No slides, no pitch.
Is it worth thirty minutes when your team already knows marketing?
Your team knows your market. That's their job and I can't do it. What I do is the layer between what they want and what the system does, and it's the layer where projects quietly die. The conversation costs you half an hour. The rebuild in year two costs more than the whole implementation.
Book a 30-minute architecture conversation