Find the broken path. Make the next action and its owner clear. Test the change against the constraint.
Risk management
Named owner on a shared queue.
Underwriting arrived in one mailbox shared by around six people. Without a ticket product, assignment and pending work could live in people's heads.
The tooling was simple. The systems problem wasn't: make the case's state visible, name its owner, and escalate beyond that person's authority.
Operating practice / proposed conventions · no quantified outcome claimed
The queue and the decision
I used mailbox tools and proposed clearer conventions for visible state, assignment and escalation. Colour coding, categories, filters and rules, and reusable replies were the available primitives. Senior authority remained part of the work.
A case has a visible state and a named owner, or it is not in progress.
Building and documents
Initial review
Missing information? Request it.
Assess risk: accept, set conditions or decline; escalate when authority requires it.
A conceptual model of the work, not a historical software specification. The link to The Desk is accountable ownership; there was no AI in this mailbox workflow.
Enterprise SaaS / CleverTap
Knowledge and tools had no owner.
People doing similar jobs used different tools and found different answers. Conversations across teams exposed uneven access and knowledge scattered across Confluence, Docs, Notion and Slack.
I investigated the fragmentation and proposed a dedicated Operations CSM role: own the path the customer book depended on, not only the book. The role was not implemented.
Diagnosed / investigated · role proposed, VP accepted direction
The customer felt it first
Tools and knowledge stores without clear owners
A stale or conflicting answer reaches a customer
Escalation interrupts planned account work
Less capacity for the next response
This was the failure path I wanted to address. My VP accepted the proposal; restructuring occurred before final head-office approval.
Proposed operating contract
For each important tool or knowledge object: purpose, named owner, one authoritative source, a review date and an intentional audience. Drafts should not become competing truth. Keep admin access with a small named group; archive obsolete channels.
The proposed role would serve CS, Sales, Support, Finance, Security and Product through better knowledge ownership, onboarding, handoffs and quoting / Salesforce workflows.
What I would measure: time to a current answer, repeated questions, guidance-related escalations, overdue knowledge reviews and important objects without owners. These are proposed measures, not achieved improvements.
I kept a written improvement backlog in Confluence and raised it in manager and team-lead conversations: better request context, routing, signals and reusable knowledge.
Most ideas remained proposals. Intercom was a real tool evaluation: I joined vendor conversations and early testing, including feedback on restricting broad admin privileges.
Written proposals · Intercom pilot participation
Four families of improvement
Intake quality / proposed
Ask for useful context in the submission form, enrich incomplete requests, then triage and route to a named owner. Do the cheapest useful computation at intake.
Routing and tool control / proposal + pilot
Slack handling and escalation ideas; Intercom testing and detailed feedback. Admin access belongs with the appropriate smaller group. The feedback is evidence of evaluation, not global security ownership.
Signal / proposed
Ticket sentiment, attribution, first reply, resolution and journey touchpoints: what should draw attention before chronology alone decides? No deployment or measured improvement is claimed.
Knowledge reuse / shared learning
Learning World used development time and Confluence to make individual interests teachable. I shared cybersecurity learning and projects with security colleagues.
Admin is a control plane, not a perk.
What I would measure: missing intake context, unowned requests and escalation quality before attributing any change in response time to a tool.
Independent Studio
Scope under constraint.
A whole world was too much work for one person. A smaller stage exposed the next constraint: the picture still had to read.
I own the scope decision. Build the smallest proof, test it, capture the result, then keep, change or kill from evidence.
A compact ledger. LinkedIn remains the exhaustive chronology.
Operating foundations
Hospitality, logistics, risk
Execution under load from 2006 — kitchens, warehouses and service timing, including Chef de Partie and Senior Storeman & Forklift Operator. Then judgement with consequences at AAMI and Strata Community Insurance — Account Manager & Underwriter work, including high-value residential strata portfolios.
Enterprise SaaS
Catawiki + Atlassian + CleverTap
Customers, adoption and commercial systems from 2018. Marketplace operations at volume in Catawiki support; Atlassian as Customer Advocate, Account Manager and Senior Account Manager across a broad EMEA portfolio of 750+ customers, with $6.8M net-new ARR; then Senior Customer Success Manager at CleverTap — EU portfolio work with the VP of Customer Success EU, including a €1.5M+ / 40+ account book, alongside an internal operations-role proposal around quoting, Salesforce and knowledge flow.
Current
Systems design & operational ownership
Independent product and operations practice from 2025: workflow design, data contracts, model evaluation and process/tooling improvement. The aim is useful change for the people operating the tools.
Catawiki: improvement needs reserved capacity
I proposed a rotating cross-functional group to bring team problems, investigate causes and document learning. My immediate team and managers responded positively, but the proposal was not implemented: there was no working-hours backfill, and voluntary extra-hours participation was not a viable model.
Full employment chronology:
LinkedIn.
Systems design, workflow design and internal-user change — grounded in operational ownership.
Illustrative service setting.
01 / Service
Every movement had to earn its place.
I didn't call it systems then.
I was not designing systems. I was trying to get through service — prepare correctly, place tools and ingredients, communicate, work quickly, stay calm, and avoid the head chef's wrath. In a small brigade serving hundreds of covers, that physical flow was the system. The insight came later.
Risk doesn't disappear. You decide what to reduce, what to transfer, and what to own.
At Strata I worked close to underwriting judgements: building defects, property risk, brokers, exposure and price. Incomplete information still had commercial consequences — accept, decline, or investigate. The lasting lesson was ownership of risk. Sometimes the best system is not another internal team; it is a specialist carrying a known risk for a known cost.
Customer-facing SaaS put me inside systems operating at real scale. The leverage was rarely simply doing more of the work; it was improving the handoff, information, workflow or tool around it.
At Atlassian, I was already gravitating toward Sales Operations problems — workflow, attribution and internal signals around the commercial motion.
At CleverTap, that shift became more explicit. I proposed an operations-focused CS role around the silos, knowledge flow, Salesforce complexity and quoting friction I was seeing across the organisation.
I spent years being the person who had to live with the consequences of the systems — customer workflows, handoffs, risk, adoption, commercial pressure and internal tooling. Over time I moved from operating inside those systems to changing them. At CleverTap that was becoming a formal move toward an Operations CSM role. Since then I've gone much further into building the systems myself.
04 / Lab
If I recommend a system, I want to know what it is like to live in it.
I test the systems I recommend before I depend on them. Three questions guide the work.
Workflow assist with an owner. AI can extract, classify, draft and route. A human or deterministic policy owns the consequential action.
Evaluate before dependence. Test structured output, failure cases and reliability before a model enters a workflow.
Buy the rail, build the policy. Buy commodity infrastructure; keep ownership, routing, auditability and decision boundaries explicit.
Further proof / Studio
Tooling under constraint.
Independent production is another test of scope, verification and ownership.
