I build the product
behind the product.
B2B SaaS companies obsess over the product customers buy — but customers experience much more than the product.
They experience your support paths, knowledge base, community, AI answers, escalation workflows, account data, internal handoffs, and the quality of every system behind the scenes.
I'm a CX Engineer and Systems Architect. I design and build the post-sales infrastructure that helps technical teams scale customer experience without creating operational drift, shadow processes, or brittle AI.
Your customers experience your systems,
not your org chart.
To your company, support, success, product, community, documentation, AI, and operations may be separate functions.
To your customers, they are one experience.
When those systems are disconnected, customers feel it immediately. They get different answers in different places. They repeat context. They wait for escalation. They search docs that do not reflect the product. They ask the community questions your knowledge base should have answered. They lose trust in your AI because the underlying content and data are unreliable.
That is not a customer success problem.
It is an architecture problem.
When CX is not engineered,
Shadow CX takes over.
Shadow CX is what happens when customer experience depends on hidden spreadsheets, tribal knowledge, Slack favors, one-off automations, outdated help content, disconnected CRM fields, and escalation paths only three people understand.
It works — until it does not.
Then support gets noisy, AI gets unreliable, customers lose trust, and teams spend more time routing problems than solving them.
CX Engineering replaces Shadow CX with observable, intentional, governed systems.
The product behind the product.
I design and ship the infrastructure behind post-sales customer experience, including:
Support workflows
That reduce avoidable escalation.
Knowledge systems
That stay aligned with product reality.
Community experiences
That capture signal, not just engagement.
AI support patterns
Grounded in trusted content and clean data.
CRM and customer data structures
That make context usable.
Escalation paths
That preserve trust under pressure.
Feedback loops
That turn customer friction into product and operational insight.
Governance models
That keep systems from drifting after launch.
Product engineering
for the post-sales experience.
I work like a product engineer inside the post-sales experience.
That means I do not stop at recommendations. I map the system, identify the highest-friction paths, design the operating model, build the workflows, instrument the signals, and help teams iterate.
The goal is not a prettier process diagram.
The goal is a customer experience system that actually runs.
Product engineering for the full
customer experience.
Product engineers build the core product experience.
CX Engineers build the systems that help customers adopt it, learn it, trust it, request changes to it, recover when they get stuck, and keep moving.
That work does not live only outside the product. It often shapes in-product journeys too, because the best CX work is informed by the places customers struggle after launch: support cases, search failures, community questions, Academy engagement, documentation gaps, escalation patterns, feature requests, and customer feedback.
Sometimes the work is connecting what already exists. Often, it means building the missing CX features companies should have had all along: feature request systems, closed-loop feedback, Academy/LMS pathways, self-service journeys, support intake, escalation visibility, AI answer flows, and customer signal loops.
| Product Engineer | CX Engineer |
|---|---|
| Builds the core product customers use | Builds the adoption, resolution, learning, and feedback layer customers rely on to succeed |
| Designs in-product workflows and features | Designs customer journeys across product, support, docs, community, Academy, AI, and escalation |
| Ships product features | Ships CX features like feature request systems, closed-loop feedback, Academy/LMS paths, self-service flows, support intake, escalation visibility, AI answer patterns, and knowledge capture |
| Owns user friction in the product | Owns customer friction wherever it appears across product, support, success, education, community, content, AI, or operations |
| Uses product analytics and user feedback | Uses product analytics plus support data, search behavior, community signals, Academy engagement, CRM data, case trends, feedback, and escalation patterns |
| Improves activation, adoption, retention, and usage | Improves adoption, resolution, trust, self-service, feedback quality, escalation quality, and post-sales scalability |
| Turns user feedback into product improvements | Builds closed-loop systems that turn customer signals into product, content, education, support, and operational improvements |
| Connects engineering, design, and product | Connects product, design, engineering, support, success, education, community, content, RevOps, data, and AI |
Selected systems outcomes.
These outcomes came from treating support, knowledge, community, and AI as one operating system instead of separate surfaces.
226%
growth in problems resolved before reaching support by moving help upstream through predictive signals, inline guidance, and community-based routing
$192K
in annual operational efficiency gains, validated by Finance, through digital support improvements that reduced avoidable support demand
4.96% → 8.8%
growth in community-assisted resolution as a share of incoming support volume after rebuilding a transactional portal into a customer community
78%
growth in quarterly community logins after improving routing, content visibility, and customer-facing support paths
10%
ticket volume reduction and 25% fewer repeat questions after unifying Zendesk, Discord, and Discourse into an intent-based help architecture
Post-sales systems
designed, built, and shipped.
A focused diagnostic if you need to see where your customer experience infrastructure breaks. A fractional engagement if you need someone to own the architecture behind it.
CX Architecture Audit
A focused diagnostic of your post-sales experience infrastructure. I map how customers currently move through support, knowledge, community, AI, escalation, and internal handoffs — then identify the places where systems, ownership, and data drift apart.
You get a clear view of:
- Where Shadow CX is forming.
- Which customer paths are creating avoidable friction.
- Which tools or workflows are undercutting trust.
- Where AI is blocked by content, data, or governance issues.
- What to fix first for the highest operational leverage.
Fully credited toward a Fractional engagement if we continue.
Book a CX Architecture Audit →Fractional CX Engineer & Systems Architect
For teams that need senior post-sales systems leadership without hiring a full-time function. I help design, build, and operationalize the systems behind scalable customer experience: support workflows, knowledge architecture, community strategy, AI readiness, data hygiene, and cross-functional governance.
Built for companies that need someone who can move from strategy to system design to implementation before they scope a full-time role.
Explore Fractional CX Engineering →3-month minimum. Rolling monthly after. 30-day cancellation. Limited to 2 concurrent partners at a time.
The bits and the Bee.
NahamSec and I at a Bugcrowd live hacking event in Las Vegas
I'm a technical operator, systems architect, and builder focused on the infrastructure behind customer experience.
My work sits in the space between support, success, product, community, knowledge, data, and AI. I help B2B SaaS teams turn fragmented post-sales operations into systems that customers and internal teams can trust.
I believe most customer struggle is not user error. It is system failure.
When customers cannot find the right answer, when support cannot see the right context, when AI gives inconsistent responses, when escalation depends on tribal knowledge, or when feedback never reaches the product team, the issue is rarely one person or one tool.
It is the architecture. That is the work I do: engineer the systems behind better customer experiences.
Frequently asked questions
Is this support operations, customer experience, or business systems? +
Yes. The work sits at the boundary between CX strategy and the systems that deliver it. I work across support operations, knowledge architecture, community, self-service, AI, and business systems because customers experience those as one path, not separate departments.
Do you only advise, or do you also own execution? +
I own execution. The advisory work is useful because it identifies where the system breaks, but the larger value is building the roadmap, governance, workflows, routing, and measurement model needed to fix it.
Is the audit useful if we don't continue? +
Yes. That's why it's a flat $1,500 and only credits forward if you choose to continue. The deliverable stands on its own.
How is this different from a UX audit? +
A UX audit usually focuses on interface and usability. My work looks at the full post-sales system: support flows, knowledge architecture, community, routing, self-service, AI surfaces, and the operational seams between them. The issue is often not one screen. It's that the experience strategy and the systems behind it are owned separately, so the customer journey breaks across the boundary.
Can I just hire you full-time? +
Possibly. The fractional model exists for companies that need this function before they're ready to scope or hire it as a full-time role.
Build the product behind your product
Tell me where
the experience breaks.
If your post-sales experience depends on hidden workarounds, disconnected tools, or heroic internal effort, it is time to engineer the system.