Turning problems into solutions, ideas into strategy, and strategy into results.

I built and managed a 20-person SME organisation, dividing the team into six specialised areas across the product and customer experience: Fraud & Compliance, Cards, Payments/P2P, Marketing, UX, and Content.

Each area had an SME lead responsible for managing their own team and developing expertise within their domain, creating clearer ownership and specialised growth paths across the organisation.

This structure gave people a clearer area of responsibility, created dedicated development paths, and made it easier for Operations and Product teams to connect with the right subject-matter expertise.

I created a Voice of the Customer programme that connected these specialised SME teams with Product Owners and Product Managers.

SMEs brought recurring customer issues and patterns from their areas of expertise into a structured matrix, helping us categorise problems, identify themes and prioritise areas for product improvement.

This created a feedback loop between customers, Operations, SMEs and Product, helping turn customer experience into actionable product insight and roadmap priorities.

Every Mur Mur lamp is made to order on our own 3D printers. Orders arrive from the online shop and from Faire wholesale, ship through Packlink, and some are sourced by a sales representative on commission.

The data lived in five places: the shop, Faire, Packlink, Notion and the print files. Simple questions had no quick answer. What does this order really earn after shipping, materials and commission? What should we print next? How many lamps can we sell with the components in stock? Entering orders by hand was slow, costly and error-prone.

I traced where each fact is created and decided who should own it:

• orders, customers and payments: the shop, which also receives Faire orders
• shipments and the real cost of shipping: Packlink
• print time, filament and material per lamp: the sliced print files
• every calculation: visible sheet formulas
• prices, print priorities, reorders and payouts: a person

Each fact is entered once, at its source, and everything else is derived from it.

One workbook of linked tables with stable internal IDs for orders, order lines, shipments, components and printers. A consistent colour code separates manual input, formulas and IDs, and every calculated column keeps its inputs on the same sheet, so anyone can trace a number back to where it came from.

The model is platform-independent: a new sales channel plugs in at the intake without changing the maths.

One Apps Script pulls orders from WooCommerce and shipments from Packlink every morning, or on demand. API keys are read-only and stored outside the sheet, and a dry run shows what would change before anything is written.

Records are matched by their source ID, so a re-run updates rather than duplicates. The script writes only input columns, never a formula or a manual override. It also corrects data at the source: wholesale orders that arrived with VAT charged in error are marked as EU reverse charge, so revenue and VAT are right.

The sliced print files are 20 to 60 MB, too large for Apps Script to open. A small Python helper on the studio Mac reads only the 1 KB of metadata inside each one (print time, grams, filament, printer) and writes a small index to Drive.

The sheet turns that index into a recipe library, one row per lamp and printer, and calculates the true unit cost: material by weight, energy by print hours, the wireless bulb, packaging, labour and a scrap allowance. Re-slicing a lamp updates its cost.

Every order gets a full waterfall: net revenue ex VAT, less production, shipping paid, fees and commission, to contribution profit. Overheads are then allocated by revenue share to reach net profit and net margin.

Commission is calculated from the sales source on net revenue, excluding shipping, and shown as a share of profit as well as a percentage of sales. Orders that lose money on shipping, or where commission takes more than 40% of profit, are flagged red.

Components are consumed when a lamp ships, one wireless bulb per lamp. Gifts, press samples, showroom pieces and breakage go into a separate movements ledger, so nothing is counted twice.

Weeks of cover come from the trailing 56-day sales rate, with critical and reorder levels per item and a direct reorder link. The dashboard shows how many lamps can be sold right now with what is on the shelf.

There is no AI in the data path. A source of truth has to be predictable, cheap to run and easy to audit, and rules and formulas do that better than a model.

AI helped me design, build and audit the system. It does not run it. Every number on the dashboard can be traced to a cell and a source.

Every table has a Data Check column, every run writes to a Sync Log, and a Field Guide explains each column in plain language. Regular audits of the live sheet turned up real issues: material costs showing €0 because one filament had two IDs, and commission columns shifting because of a hidden difference in header text. Each was traced to its root cause, fixed in the script and verified against the live data.

Next is the printer link: live status from the three printers, prints scheduled from the queue, and each order moving forward on the machine’s own status, from printing to packed to customer informed.

Wholesale is the main growth channel for Mur Mur: concept stores, interior studios, galleries, online design shops and design markets across Europe, plus press and creators. Each contact needs research, a verified address, a personal email in their language, a well-timed send, a follow-up and a careful answer when they reply.

For a two-person team the bottleneck was not the writing. It was everything around it: finding the right shops, confirming the right address, remembering who to chase, and keeping a handmade brand's tone at a volume no one could write by hand.

I broke outreach into its steps and decided, for each one, who should own it:

• deduplication, timing, sending, tracking and bounces: code
• finding prospects that fit a written profile: AI with web search
• verifying contact details: code, on the company's own site
• writing and translating in the brand voice: AI, then checked
• first contact and every answer to a reply: a person

This became the boundary the whole system is built on.

One sheet is the single source of truth: one row per contact and a fixed status lifecycle from Research to Draft Ready, Approved, Sent, Follow-up and Reply, with Bounced, Duplicate and Do Not Contact as exits. Every step reads and writes that status, so the state of every conversation is visible at a glance.

The robot refuses to process a tab whose columns have moved, contact tabs are locked to the owner and the robot, credentials live in encrypted secrets, and runs never overlap.

Before any email was written by AI, I wrote the brand voice down: tone, banned words, approved links, a pitch per contact type, wholesale facts and sign-offs. It lives in a Voice & Links table that the robot reads on every run.

It can be edited in the app, with checks before saving, a history of every change and one-click restore. The voice is governed like content instead of being buried in prompts.

Research runs on request (type, market, how many) or daily per category, from a written profile: what I am looking for, good examples, what to avoid, and a fixed number of wildcards that bring in adjacent opportunities. Regions rotate and there is a daily cap.

Results come back through a strict schema. Code then removes duplicates across every list and accepts an email only if it is printed on the company's own website. An address is never guessed.

Each first email is written in the contact's language (Spanish, Catalan, French, Italian, Polish, Portuguese or English) and includes one concrete detail about that contact. A separate call checks the translation, writes an English version for review and flags anything invented.

Code then checks for banned words, dashes, link echoes, unfilled placeholders and a valid own-domain address. Anything that fails goes to Needs Review with the reason next to the draft.

The system could send on its own. Approval stays on by design, because a first email speaks for the brand. Approving is one click in Outreach OS, and editing in English sends the text back to be re-translated.

Approved emails go out in the recipient's local morning, within a daily limit per mailbox, from two real mailboxes on the brand's own domain. A copy is saved in each Sent folder, so the conversation continues naturally in an ordinary mail app.

Each run reads the inbox and separates bounces, auto-replies and anti-spam challenges from real replies, matched by thread, subject or sender domain. Opt-outs move to Do Not Contact automatically and for good.

Real replies are scored, translated into English and answered with a drafted reply that uses only approved wholesale facts. Any missing fact is left as a visible gap that blocks sending until a person fills it.

Outreach OS, the control room I designed on top of the sheet, shows live KPIs, the funnel, research and send queues with their next run, the activity log and a health banner when a run is missed or something fails. A backup timer starts the robot when the scheduler skips a run.

Results feed back as small, reviewed changes. When "about 20% wildcards" produced none, the profile switched to fixed counts. When design markets returned nothing, the search learned that a market's website is often a page on its organiser's site. Prompt caching cut the cost of re-reading the voice rules to a tenth.

Support demand fluctuated significantly with the academic calendar, marketing campaigns and product activity. At peak periods, ticket volumes increased sharply; at quieter periods, the workload was substantially lower.

The queue contained a mix of repetitive operational requests and higher-risk cases involving billing, refunds, account access and compliance. The challenge was not simply to automate support, but to determine what could be automated safely, what required human judgment, and how the system should respond when it was uncertain.

I analysed the existing support operation end to end: ticket types, recurring questions, escalation paths, response patterns, service-level requirements, systems involved and the actions required to resolve each request. I mapped which requests were:

• repetitive and rules-based
• suitable for AI classification or response
• dependent on customer or account data
• sensitive or compliance-related
• ambiguous and therefore unsuitable for autonomous handling
• dependent on human action or approval

This created the decision framework for what the system should automate and what it should deliberately leave to people.

Security and operational controls were designed before automation was introduced. API credentials were isolated and protected, access was restricted, rate limits and spending controls were defined, and sensitive workflows were separated from autonomous handling.

The system was designed so that internal tooling, credentials and decision logic remained invisible to customers, while higher-risk requests were routed outside the automated path.

Before the model was allowed to respond, I documented the recurring support scenarios, required information, approved resolutions, exceptions and escalation conditions.

These were converted into a structured knowledge base and approved response library. The system could select from validated information rather than freely inventing answers, with sensitive or uncertain cases excluded from autonomous handling.

Tickets are classified and matched against defined workflows, knowledge and approved responses. Rule-based checks handle deterministic conditions; AI is used where language understanding or classification adds value.

Each response passes through validation before being sent. Requests outside the defined confidence or safety boundaries are removed from the automated path.

Sensitive requests, including refunds, billing disputes, account issues and unclear cases, are routed to a person rather than forced through automation.

The objective is not maximum automation. It is the right level of automation for each type of work.

When the system cannot establish a sufficiently reliable answer, it does not improvise. It flags the case, records the reason for escalation and routes it to a person.

Uncertainty becomes an observable operational signal rather than an invisible failure mode.

Automated responses are reviewed against defined quality criteria, with a second model used as an additional review layer where appropriate.

Human review remains essential for identifying failure patterns, knowledge gaps and cases where the system’s behaviour diverges from the intended workflow.

When an issue is identified, the response, knowledge base, rule or escalation logic is updated and tested against the relevant scenario before being reintroduced.

Every run produces an operational record of what happened, what required attention and where the system encountered uncertainty.

Recurring findings feed back into the knowledge base, rules and approved responses. New automation is introduced only after it has been reviewed and validated.

The system becomes more capable through evidence, not simply through more autonomy.

The Mur Mur shop runs on WordPress, Elementor and WooCommerce, with more than thirty plugins, a wholesale channel on the side and one person to look after all of it. Nobody was watching the site day to day, and the journal had no posts and no page.

The bottleneck was not the tools. It was remembering to look, noticing what changed, and finding the time to write. The risk was the opposite of too little automation: an AI with the keys to a live shop.

I split the work into its steps and decided who should own each one:

• reading visits, orders, reviews, plugin versions and uptime: connectors, read-only
• spotting what is broken: fixed rules
• turning the numbers into a short plain-language report: AI
• proposing topics and drafting posts in the brand voice: AI, from my own stories
• publishing, plugin updates, settings and anything live: me

This became the boundary the whole system is built on.

A handover file in the repository is the first thing every run reads: what the assistant may do, what it may not, the site's facts and the voice rules. The core rules are short. Nothing changes on the live site without my explicit yes for that change. Posts are saved as drafts. If a fact is unknown, it stays a visible placeholder.

Because the rules live in a file and not in a chat, every scheduled run starts from the same place, and anyone can pick the work up.

A report is only as good as its numbers. The first analytics plugin was broken and returned errors, so I replaced it with the official GA4 integration for WooCommerce and confirmed the tag in the live page source. Product views, add-to-cart, checkout and purchase now reach GA4.

Two blind spots were made visible instead of hidden. The cookie banner blocks counting until a visitor accepts statistics, so visitors who decline are not counted, and consent modelling is the planned fix. Instagram clicks showed up as "Direct", so the bio links now carry tracking parameters through short redirects.

Every weekday at 07:47 a scheduled routine reads yesterday's visits and sources against the same weekday last week, new orders with their source, comments and reviews waiting, and whether the site responds. It also compares installed plugin versions with the official registry.

It has no permission to update, activate, edit or publish anything. It reports. Major updates to the shop, page builder and payments plugins come with the same advice every time: update after a backup. Premium plugins cannot be checked this way, and the report says so once, briefly.

A fixed list of alerts goes at the top of the report: a tool or account missing, zero visits in a full day, failed or on-hold orders, the site not reachable. Each one says what is broken and the one thing to do about it.

The shop has low traffic, so the routine is told not to dramatise small changes. The rest is a few lines in plain words, then at most five actions for the day, or "Nothing today". It arrives as a push and an email.

Every Monday a session proposes three topics from search data, existing posts and a standing topic list, with the goal of bringing search visitors to the shop. I choose one and the assistant interviews me, a couple of short questions at a time, to get my real stories and details.

It then writes in the brand voice: 400 to 700 words in short blocks between photo groups, one soft link to the lamps at the end, and only my own photos, never generated images of the product. The Search Console link that feeds the topics is the next connection to make.

The look was designed once and approved by me: minimal, with a lot of air, in the style of the site's own pages. A small builder turns each post, written as a structured file with layout, title, photos with alt text and captions, and the closing link, into the finished page.

Three layouts rotate week by week, so the journal does not repeat itself. The post is saved as a WordPress draft with its SEO title, description, keyphrase, slug, excerpt and category. I read it, change what I want and publish it myself.

The first real runs found real gaps. The cloud environment could not reach the live site or the plugin registry directly, so the check now says so in one line instead of failing silently. The analytics account was not yet linked, so a missing account is now reported as a problem to fix.

Next on the list: alt text for the 100 or more images and videos that have none, a Search Console connection for topics, consent modelling for the visitors who decline cookies, and a journal overview page once the first post is approved.

I run a product brand, a contract customer-success role, a job search and a second brand at the same time. Ideas, requests and worries arrive faster than they can be organised, and urgent work crowds out important work.

The bottleneck was not capturing tasks. It was deciding, every morning, what deserves today, and having the discipline to say what does not.

I broke personal operations into its steps and decided, for each one, who should own it:

• capturing thoughts as they come, without forms: me, in my own words
• working out what something is and where it belongs: AI
• structure, status and history: Notion, as the single source of truth
• time, fixed blocks and theme days: the calendar
• finding what is overdue, stale or overlapping: queries, from fixed rules
• what goes into today, and what gets dropped: me

This became the boundary the whole system is built on.

The first version modelled the whole strategy: North Star, Area, 90-day goal, System, Project and Task, across ten linked databases with sixteen fields on every task. It was coherent on paper.

In practice it was too heavy to keep up, and within a few weeks I had stopped using it. A system nobody uses does not manage anything, however well it is designed. That was the most useful finding of the project.

The second version keeps three levels (Area, Project, Task) and five fields per task: title, project, area, status and date. Statuses describe a decision, not a mood: Inbox, Today, Next, Waiting, Done or Dropped. Today holds three tasks at most.

Nothing was deleted. The old databases moved to an archive and the old fields were hidden, so history and earlier thinking are still there if they are needed. Strategy now lives in each project's goal, not in extra layers.

I talk freely, by voice or text. Before anything is organised, the assistant works out what it actually is: an idea, a decision, a project, a task, reference material or simply context about how I am doing. If it is unclear, it asks one question, not a form.

It then proposes where the item belongs, with the project, status, date, why it matters and the first concrete action. When one conversation creates several things, they come back as one bundle. Nothing is written to Notion without my OK.

One rule keeps the two tools honest: the calendar says when, Notion says what. Fixed commitments and theme days or weeks (a design week, a shop-launch day) live in the calendar; tasks and their dates live in Notion.

Neither copies the other, so there is one place to change a date and one place to change a plan.

Every weekday at 08:15 a routine reads the calendar and the task data and writes a short brief: today's fixed blocks and theme, at most three suggested tasks that fit the free time, each with a reason, and a heads-up list.

The routines can read, calculate and suggest. They cannot create, edit or move anything. They use only two connectors, with no web search, file work or sub-agents, which keeps them cheap, fast and predictable. If a connector fails, the brief says which one and still delivers what it can.

The assistant is designed to push back: is this leverage or distraction, what does it compete with this week, what is the exit condition for this creative loop? When the week is overloaded, its job is to help me cut, not to add.

The heads-up list surfaces what goes stale silently: overdue tasks, dates left over from an earlier plan, overlapping calendar blocks, an unsorted Inbox and anything waiting for more than a week.

Every Friday at 17:00 a review reports what was done by area, what is stuck, which projects have no next step, and proposes a focus for each day of the coming week from the calendar's theme days.

Real briefs drive small, reviewed changes. One of the first briefs after the redesign caught a trial that had to be cancelled the day after its deadline, two overlapping calendar blocks and around ten tasks still carrying summer dates, which became a one-off triage rather than a permanent source of noise.

My experience spans operations, customer success, programme management, AI automation and running my own product brand. That range is an asset in the work and a liability in a job search: it is easy to apply too widely, undersell the strongest evidence, or tell a slightly different story every time.

The bottleneck was not finding listings. It was deciding, consistently and quickly, which roles were genuinely worth pursuing, and then preparing applications that stayed accurate.

I broke the search into its steps and decided, for each one, who should own it:

• reading alerts, extracting links, deduplication and tracking: code
• scoring, thresholds and hard gates: code, from fixed rules
• mapping job requirements to my evidence: AI, then checked
• company research and drafting: AI, inside evidence boundaries
• which roles to pursue, and every submission: me

This became the boundary the whole system is built on.

A private database holds one record per vacancy, with a search lane and an application status from Not started through Research, Ready for review, Approved to apply, Submitted and Interviewing to Offer or Closed.

The automated recommendation and my own decision are stored as separate fields and never inferred from each other. Old scores are kept as immutable records rather than rewritten, and the AI provider sits behind a provider-neutral contract, so it can be replaced without redesigning the workflow.

Before any AI wrote a word about me, I wrote down what is true and how it may be used. Every claim in my career evidence bank records where it comes from, whether it is documented, supported or still needs documentation, and whether it can be shown publicly.

Claims with open conflicts or missing documentation never reach an application. Confidential work, such as the support automation, is described only in approved anonymised terms. Generated text never becomes evidence just because it was saved.

Three times a day the system reads LinkedIn alert emails in full, not just their subject lines, and extracts the exact vacancy link and job ID from the message body.

If an alert has no exact link, it is rejected. A link is never reconstructed from a web search, because a near match points to the wrong job. Roles already on the tracker are skipped, and nothing is scored automatically on import.

Each role is scored against seven dimensions: qualification evidence, economics, stability, time fit, career capital, AI signal and interest. The weights and thresholds change by lane, because a stable employee role, a flexible contract, AI side work and a relocation opportunity are different economic decisions.

The arithmetic is deterministic and stays outside the model. Missing information is never filled with a default: it produces a range and a Needs Review status. Nine hard gates, from location to contract risk, stop a role with a stored reason.

Company, role and vacancy link are locked before research begins, and the spending ceiling is checked before any paid call. Source collection runs without my profile, so it gathers facts about the company instead of looking for reasons to like it.

Results about other employers, stock prices or other vacancies are rejected before storage. A dossier is saved only when relevance checks pass, and a long research run keeps its ID, so checking it later resumes the same run instead of paying for a new one.

Each role is routed to one of five CV baselines by role family, with ambiguous cases sent to review rather than silently matched. Tailoring may only reorder approved content and adjust a few defined slots; titles, dates, scope and metrics stay locked.

The application pack adds a cover letter in my documented voice and interview preparation built from the research. Everything stays a draft. Apply means I have approved it to submit by hand. The system never submits an application.

Automated tests cover the scoring formula, lane thresholds, approval gates and budget checks, and a validation run reproduced every stored record on a local copy before migration, with zero production writes and zero model calls.

Decisions and outcomes feed back as small, reviewed changes: a new lane when relocation roles did not fit the existing weights, stricter source rules when research drifted to unrelated pages, and new evidence entries as projects are documented.