Inside Judge.me’s AI operations: what founders can learn

Judge.me founder Peter-Jan “PJ” Celis describes an AI operations system built around shared company knowledge and a Slack interface connected to business tools. The useful lesson for ecommerce software teams is how the workflow is organised, rather than treating a headline savings figure as a result another company can expect.

In a 22 October post, Celis says the company hired a product lead to automate operational requests, including payroll questions, leave and profit-and-loss reporting. He reports more than $770,000 in savings over eight months. The post does not provide a cost reconciliation that lets us independently verify that figure or separate gross savings from implementation and ongoing costs.

Shared knowledge comes before the chatbot

In his talk uploaded on 15 October, Celis describes putting company strategies and processes into a shared, version-controlled knowledge base that agents can read. Work feeds back into that shared memory, so colleagues spend less effort repeatedly exchanging context. This is his account of the company’s approach, not an independently audited productivity study.

The video description dates the talk to 21 September at an Owner/President Management programme session at Harvard Business School. It appears on Celis’s own channel; it should not be read as an endorsement by the school.

Source: Peter-Jan Celis. Talk dated 21 September 2026; uploaded 15 October. Watch the original talk.

A single interface still has people behind it

The operations section, around eight minutes into the talk, describes a product manager building automations and a Slack entry point connected to other systems through APIs and MCP. Celis also says some fractional bookkeeping and operations support remains behind that interface.

That distinction matters. Moving requests into a chatbot does not demonstrate that every underlying judgement or exception has been automated. The work includes maintaining integrations, deciding who can access information and routing requests that still need a person.

What an app founder could test

Our suggested starting point is one recurring internal request with a clear owner and a documented answer. A question about where to find an approved process is a simpler first experiment than an action that changes payroll or accounting records.

• Define the source: identify the current policy or record the assistant should use, who maintains it and how corrections reach the shared knowledge base.
• Separate answers from actions: distinguish explaining a process from submitting or approving a change. Keep existing approval responsibilities explicit.
• Test access: check what different staff roles can retrieve, including when a request is phrased indirectly. Shared knowledge need not mean unrestricted access.
• Measure the whole workflow: record answered requests, corrections, escalations, staff review time, integration maintenance and service charges.

Keep a human route for requests the assistant cannot resolve. Compare the result with the existing process before expanding its remit. Our model evaluation guide explains how to assess accepted work and review effort rather than choosing solely on model benchmarks.

The case offers a concrete design to examine: maintain shared context, give routine work a consistent entry point and make the remaining human work visible. The reported savings remain Celis’s claim, not a forecast for Shopify merchants or app developers.