Concepts

RENEW: get your processes ready for AI.

Who in your company knows exactly how a quotation is processed, from receipt to dispatch? Not just roughly. Exactly: every step, every exception, every decision along the way.

Who in your scale-up knows exactly how an enterprise customer's escalation travels from the first support ticket to the fix in production? Not roughly. Exactly: every hand, every exception.

Who in your company knows exactly what happens when a consignee in Duisburg refuses a delivery? Not roughly. Exactly: who calls, who replans, who invoices the extra trip.

Who in your agency knows exactly when a change request gets its own price and when it quietly vanishes into the sprint? Not roughly. Exactly: who decides, at what moment, for what amount.

Who in your company knows exactly how a customer's specification becomes a signed quotation? Not roughly. Exactly: who estimates the engineering hours, who sets the mark-up, who signs.

Ask that question out loud tomorrow morning. There’s a good chance you’ll get three different answers from three different people, and that none of them will be written down. Where those answers diverge, a model breaks down.

Ask it at Monday's stand-up. Your support lead, your CTO and your customer success manager give three answers, and none of them sits in Confluence. Where those answers split, a model stalls.

Ask it at tomorrow's morning planning. The planner, customer service and the driver will give you three routes, and none of them sits in the TMS. Right where those routes split, a model stalls.

Ask that question at Monday's stand-up. Your project manager says one thing, your lead developer another, and your account manager has a third version. None of it is in Jira. Where those versions clash, a model stalls.

Ask your sales engineer, your estimator and your head of engineering tomorrow morning. Expect three different contingency mark-ups, none of them written down. That is where a model stalls.

I would like to see my completed process page and payback period

One hour · enquiry regarding the process · no quotation

Why things go wrong, and keep going wrong

Figures from Statistics Netherlands (CBS) for 2025.

27%

10 to 49 employees

Of the companies with between 10 and 49 employees, 27 per cent use AI.

66,2%

From 250 employees

For organisations with 250 or more employees, the figure is 66.2 per cent. Same country, same year, same method.

14.0 to 22.7 to 33 per cent

All companies with 10 or more employees

Across all companies with 10 or more employees, the figure rose from 14.0 per cent in 2023 to 22.7 per cent in 2024 and to 33 per cent in 2025.

CBS, 2025

That gap is currently widening. Those figures relate to implementation; there are no official statistics on the results.

Vague input, plausible nonsense

A model reflects the accuracy of its input. Feed it a vague process description, and it will produce results that are plausible but incorrect. That is why the pilot is successful, whilst the roll-out gets bogged down.

The couplings are the problem

The problem lies with the links, not the steps. There is no handover between sales and work planning.

The handovers are the problem. What the AE promised at signature sits in Slack, not in the CRM customer success opens.

The links are the problem. A pallet exchange the driver agrees at the dock never reaches the pallet account.

The problem sits in the handover. What sales promised the client never reaches the statement of work your project manager receives.

The links are the problem, not the steps. What sales promised the customer often reaches engineering at the order kick-off as a spoken summary.

That’s where your lead time increases, and that’s where you’ll see, when carrying out a post-project analysis, where your margin went.

Pay for that loss

Cost of that loss. If the colleague responsible for the process leaves: a replacement’s monthly salary multiplied by the number of months until full staffing levels are restored, plus your own training hours.

Price that loss. If the CSM carrying renewals for your twenty largest accounts leaves: a replacement's monthly salary times the months to full speed, plus your own renewal-call hours.

Price that loss. If the senior planner who knows every lane and every quirk of your biggest shipper leaves: a replacement's monthly salary times months to full speed, plus your own hours.

Price that loss. If the senior developer who knows your biggest client's stack leaves: a replacement's monthly salary times the months to full speed, plus the hours you cannot bill.

Price that loss. If your senior estimator leaves after twenty years: a successor's monthly salary times the months until they quote alone, plus your hours checking every quotation meanwhile.

You can’t know exactly which months these are, so our rule of thumb is: three to nine. The lower end of the scale applies to a standard role that’s clearly defined; the upper end applies to specialist work that isn’t specified anywhere.

Our estimate; not a measured standard.

That amount does not appear in any accounts or in any work in progress.

Documenting things is never a priority, and the hustle and bustle of the day gets in the way. That’s how the gap above comes about.

[ Four questions ]

Four questions, using your own figures

This is the first step in every conversation I have, and you’ll be doing it yourself this afternoon.

Please have your timesheet or your ticket export for the last four weeks to hand.

Pull your Zendesk export or your HubSpot activity log for the last four weeks.

Pull the trip export from your TMS and your exceptions log for the last four weeks.

Export your timesheets and your Jira tickets from the last four weeks.

Pull the hours booked per order number from your ERP for the last four weeks.

Which recurring task takes your business five hours a week or more?

Which task costs your team five hours a week, like logging churn reasons by hand?

Which recurring task, such as matching PODs to invoices, costs you five hours a week?

Which recurring task, like client status reports, costs you five hours a week?

Which recurring task, like spare-parts quotes, costs you five hours a week or more?
How many of those hours do you actually save if someone keeps checking the results?
How often does that task deviate from the standard procedure, on a monthly basis?
Who is the only one who really knows how this task is going?

If the answer to question three is in the tens, work out the problem first. Only then will your answer be correct.

How to work out the answer

terugverdientijd (weken) = bouwuren / bespaarde uren per week

Never divide by what the task currently costs. Someone will always double-check, so the actual saving is lower. Twenty-five hours’ work compared with three hours’ profit works out at well over eight weeks. If it’s over twelve weeks, go for something else. That’s our rule; if you’re around the twelve-week mark, measure more precisely.

Never divide by what the task costs today. Your RevOps analyst keeps checking the output, so the honest saving is lower. Thirty build hours to automate pipeline-review prep, against four hours saved a week, is seven to eight weeks. Above twelve weeks, pick something else. That line is ours; if you land near twelve, measure more closely.

Never divide by what the task costs now. Take the pallet account your planner reconciles per customer each Monday: four hours. Someone keeps checking, so the honest gain is three. Thirty build hours over three is ten weeks. Above twelve weeks, pick another task. That limit is ours; near twelve, measure more precisely.

Never divide by what the task costs now. Someone still checks the output, so the honest saving is lower. Matching hours to retainers takes four hours a week; one hour of checking stays. Thirty build hours against three hours saved is ten weeks. Above twelve weeks, pick something else. That limit is ours; near twelve, measure more precisely.

Never divide by what the task costs today. Your service coordinator still reads every service report, so the honest saving is lower. Thirty build hours against three net hours saved a week is ten weeks. Beyond twelve weeks, pick another process. That limit is ours; if you land near twelve, measure more precisely.

You can’t predict development hours, so here’s our rule of thumb. A first working version of a task that’s been documented and is already running digitally takes us between fifteen and forty hours. How many of these three apply to you: lots of exceptions, three or more systems, nobody checking the result? None: fifteen hours. One: twenty-five. Two or three: forty.

This is our estimate, not a measured standard. Check after one week.

RENEW: taking one step back to take two steps forward

RENEW is our own method; the letters represent the steps.

R, Recognise, to recognise

Look for processes that take five hours a week or more – our threshold – and calculate the payback period. Five characteristics predict whether a task is suitable for a model: frequency, clear rules, few exceptions, little need for judgement, and digital input and output.

E, Explore, explore

List two alternatives alongside the task: scrap it, or simplify it first. Only if those options prove fruitless is a model the cheapest option. Let the person carrying out the work choose.

N, Nurture, refine

Answer the four D’s below, one line per D. Those four lines make up your assignment.

E, Enhance, to strengthen

Measure four weeks after the solution has been implemented. The person carrying out the task counts the hours per week themselves and compares them with their baseline measurement in Recognise. If you achieve less than half of the expected time savings, simplify or split the task. That’s our threshold.

W, Walkthrough, step-by-step guide

You carry out the test, make a note of what you see, and check back after three days, six days and nine weeks.

The four Ds.

Delegation

What do you delegate, and what do you keep in-house because you remain responsible?

Diligence

Where does a mistake cost a lot, and what checks do you put in place there?

Description

Describe the task in such detail that there can be no misunderstanding.

Discernment

When is it permissible for the model to deviate, and when is it never permissible?

Judgement becomes Delegation, exceptions become Diligence, rules become Discernment, and recording becomes Description.

Indexing and linking

Indexing and linking. Every documented process is assigned a number, an owner, a start and an end. Record which process feeds into which other process; duplication of effort will come to the fore.

Your assignment will then refer to your own text, not to an opinion. If you change the model, that text remains the same.

Week one

Week one. The employee records their own screen and explains what they are doing. They control the recording; they decide what stays in it; and the aim is to reduce their workload, not to measure their work. Make sure to say that out loud, otherwise it comes across as surveillance. You can also shadow them, at their invitation and under the same terms.

If someone leaves, hold a handover meeting to discuss their key responsibilities. Set this out in writing: reason, steps, decision-making rules, exceptions, escalation. Our estimate is between a few hours and a day per workflow.

[ By sector ]

The same five steps, three tempos

The method does not vary from sector to sector. What does vary is which process you tackle first.

SaaS scale-up

R Filter your ticketing system by topic. Count the number of tickets per week relating to the same five topics, plus the hours spent, plus your support team’s utilisation rate.
E It really is possible to remove them: sort out the error message that’s causing the tickets. If the flow remains the same, simplify the triage to two bins.
N Delegate the drafting, not the sending. Carry out a double-check whenever money or data is involved. Describe the correct answer for each topic. Never invoicing, never security, never your SLA.
E After four weeks, remove the filter from step 01 again. If the total number of hours does not decrease, narrow the focus down to the topic that actually keeps coming up.
W Follow a release: the sixth day of a sprint, the ninth week from a release date.

See SaaS scale-ups.

Logistics

R Don’t look at the journey, but at the exceptions log in your TMS and the dispatcher’s phone. Keep a tally of those calls for a week.
E. In addition to ‘build’, provide two options: do not call the customer if the delay is less than a quarter of an hour, or plan the journey so that the handover is not required during cross-docking.
N A model may draft a standard message regarding a delay. Never commit to a delivery time; any deviation from the route must be handled by a human.
E. After four weeks, count the same calls for each lane. If the number remains the same, then you’ve automated the message rather than the cause.
W Footfall on busy days – not on a quiet Tuesday – and mark week nine as a peak.

More about logistics.

Mechanical Engineering

R Your order book is project-driven; the same order never comes back. Frequency is found in the steps between your ERP and work planning: quotation, bill of materials, service report, warranty enquiry. Count them across ten orders, plus the hours.
E Ask the most senior mechanic and the estimator what can be omitted: which warranty claims will no longer arise if the service report becomes a standard form.
N For each component, describe when a deviation is considered normal. A model that does not recognise this distinction accepts customisation as the norm.
E Calculate per order, not per week: the estimated hours for the new order alongside the previous two, and the final calculation next to them. If there’s no difference, just use the bill of materials.
W Lead time for an entire order: when lead times run into months, a week means nothing.

The assignment that replaces my first lesson

Below is the prompt I use to query a process myself. You are welcome to copy it and use it under your own name. Paste it into the AI model you’re already using, select a task from your initial diagnostic response, and answer the model’s questions.

Allow twenty minutes – this is based on our experience, not a set standard. You’ll receive a page which you can show to the colleague doing the work that very afternoon. Ask them to tick off the bits that aren’t right.

Before you use this

First, check where that model allows you to enter data. A business subscription with a data processing agreement is what makes this secure for company data; a free consumer account is not. Leave out customer names, personal data, rates and anything covered by an NDA, and if necessary, run the exercise using placeholders: calculator, planner, system A, system B. The method works just as well with these.

First check where that model keeps your input. A business plan with a data processing agreement makes this safe for company data; a free consumer account does not. Leave out account names, ARR per customer, contract values, your cap table, personal data from support tickets and anything under NDA with investors. Run the exercise on roles if needed: AE, CSM, tier-2 support, billing, CRM. The method works just as well.

First check where that model keeps your input. A business subscription with a data processing agreement makes this safe for company data; a free consumer account does not. Leave out shipper names, number plates, drivers' names with their driving and rest times, and your contract rates per lane. Use roles if you need to: planner, driver, shipper A, TMS, on-board computer. The method works just as well on those.

First check where that model keeps your input. A business plan with a data processing agreement makes this safe for company data; a free consumer account does not. Leave out client names, source code, API keys, hourly rates and anything under NDA, and if needed run the exercise on roles: project manager, lead developer, the client's product owner, ticketing system. The method works just as well on those.

First check where that model keeps your input. A business plan with a data processing agreement makes this safe for company data; a free consumer account does not. Leave out customer names, drawings and specifications under NDA, cost prices, hourly rates and your margin mark-up. If needed, run the exercise on roles: sales engineer, estimator, project manager, customer buyer, ERP, PDM. The method works just as well.

Rol: je bent procesanalist. Ik beschrijf zo een terugkerende taak uit mijn
bedrijf. Werk in vier delen en begin bij deel 1.

Deel 1, uitvragen. Stel mij maximaal tien vragen, maar stel er nu precies
een: alleen de eerste. Zet geen genummerde lijst neer, toon de volgende
vraag niet, en wacht op mijn antwoord voordat je verder gaat. Vat mijn
antwoord in een zin samen voordat je doorvraagt. Vraag naar: de aanleiding,
de stappen op volgorde, de beslisregel bij elke stap, de uitzonderingen en hoe vaak die per maand voorkomen, de
systemen waarin het werk gebeurt, welk proces aanlevert en welk proces
ontvangt, en welke rol de enige is die het echt weet. Is een antwoord vaag,
vraag dan door met een concreet voorbeeld van vorige week.

Vraag nooit naar klantnamen, persoonsgegevens of tarieven, en vraag naar
rollen in plaats van naar namen van personen. Noem ik ze toch, gebruik ze
dan niet in je uitvoer.

Deel 2, de pagina. Lever een pagina van hooguit een A4 met deze kopjes:
Procesnummer, Eigenaar, Aanleiding, Stappen genummerd, Beslisregels in de
vorm als-dan, Uitzonderingen met frequentie per maand, Systemen, Levert aan
welk proces, Ontvangt van welk proces, Wie bel je als het misgaat.

Deel 3, de toets. Geef de taak een score van 1 tot 5 op deze vijf kenmerken.
Bij alle vijf betekent 5 gunstig voor automatiseren en 1 ongunstig:
frequentie (5 = heel vaak, 1 = zelden), regelduidelijkheid (5 = vaste
als-dan-regels, 1 = geen regels), uitzonderingen (5 = bijna nooit een
uitzondering, 1 = voortdurend), eigen oordeel (5 = bijna geen eigen oordeel
nodig, 1 = veel eigen oordeel), en digitale invoer en uitvoer (5 = staat al
volledig in systemen, 1 = papier en gesprekken). Zet achter elke score het
woord gunstig of ongunstig, zodat ik in een oogopslag zie welke kant goed
is. Onderbouw elke score met een zin uit mijn eigen antwoorden, niet met
algemene kennis.

Stel daarna de knock-outvraag: hangt er persoonlijke verantwoordelijkheid
richting een klant of een toezichthouder aan deze taak? Is dat antwoord ja,
of scoort de taak een 1 of een 2 op uitzonderingen, of een 1 of een 2 op
eigen oordeel, adviseer dan: eerst vastleggen, daarna hooguit een deel
automatiseren. Is het antwoord op de knock-outvraag ja, zeg er dan bij dat
een mens elk resultaat aftekent, hoeveel het model ook doet. Zeg in een zin
waarom, en ga daarna toch door naar deel 4, zodat ik de som zie.

Deel 4, de som. Stel deze drie vragen, een voor een.
Vraag A: hoeveel uur per week kost deze taak nu in totaal?
Vraag B: hoeveel van die uren verwacht ik straks echt te besparen als een
model een deel van het werk doet? Zeg erbij dat het eerlijke antwoord
meestal flink lager ligt dan het volle aantal, omdat iemand het resultaat
blijft nakijken. Dit antwoord B is mijn tijdwinst per week.
Vraag C: hoeveel uur bouwen schat ik? Weet ik dat niet, geef dan deze
bandbreedte: een eerste werkende versie van een opgeschreven, al digitaal
lopende taak kost vijftien tot veertig uur, een schatting uit de praktijk
en geen norm.

Noemde ik bij vraag C zelf een aantal uren, reken dan met mijn getal. Weet
ik het niet, bepaal dan waar in de bandbreedte ik zit. Vraag, voor zover dat
niet al uit deel 1 blijkt, hoeveel uitzonderingen per maand er zijn, hoeveel
systemen de taak raakt, en of een mens elk resultaat nakijkt. Kijk naar drie
dingen: veel uitzonderingen, drie of meer systemen, geen menselijke
controle. Geen van de drie: vijftien uur. Een van de drie: vijfentwintig.
Twee of drie: veertig. Noem welk getal je gebruikt en waarom.

Reken dan de terugverdientijd: bouwuren gedeeld door antwoord B is het
aantal weken. Deel door de bespaarde uren uit vraag B, nooit door de uren
uit vraag A. Noem het aantal weken.

Sluit af met een oordeel. Twaalf weken is de grens die wij aanhouden, onze
werkregel en geen natuurwet. Twaalf weken of minder: doen. Meer dan twaalf
weken: kies iets anders, of versimpel of splits de taak en reken opnieuw.
Adviseerde je in deel 3 eerst vastleggen, herhaal dat hier en zeg erbij dat
deze som pas geldt nadat de taak is vastgelegd. Zeg er altijd bij dat de
bouwuren een schatting zijn en dat ik ze na week een toets aan wat het echt
kostte.

Regels: markeer elk punt waarover ik geen antwoord gaf met OPEN VRAAG. Verzin
geen stappen, geen regels en geen aantallen die ik niet heb genoemd.

Three things make it useful. It asks one question at a time, so you can complete it between appointments. It records which process delivers and which receives: the links on which your index is based. Parts 3 and 4 allow the model to validate its own outcome, using your sentences as evidence. If you mainly get ‘OPEN QUESTION’ back, then you’ll know which questions to ask whom on Monday.

This is not a one-off interaction but a pattern: fixed task, fixed output. In agent-based terms, that is a ‘skill’, and the stack of pages is the memory on which it runs. See the introduction to agent-based working.

What RENEW is not for

Four situations where RENEW is of little use to you, and which you can recognise in advance.

If your market is set to undergo a fundamental transformation next year, then setting the process in stone today is the wrong first move. If you work almost exclusively on bespoke projects, there is little that can be repeated and therefore little to be gained. If you’re looking for a quick fix that’ll be ready tomorrow, it’ll demand more attention in the first few weeks than it’s worth. And for tasks where someone is personally accountable to a client or a regulator, you need a person at the helm. A model may assist, but it’s the person who gives the final approval. Full stop.

If you move from seat-based to usage-based pricing next year, capturing today's process is the wrong first move. If every enterprise deal is a custom implementation, there is little to repeat and so little to gain. If you want something running before next week's board meeting, this costs more attention than it returns in the first weeks. And where someone carries personal responsibility, such as the revenue recognition your CFO signs off or a breach notification under GDPR, keep a human at the wheel. A model may help; the human signs. Full stop.

If your biggest shipper puts its volume out to tender again next year, documenting today's process is the wrong first move. If you mostly run project transport where every trip differs, there is little to repeat and little to gain. If you want a trick that is ready before the rate round, this costs more attention than it returns in the first weeks. And for an ADR transport document or a customs declaration that someone personally signs, keep a human at the wheel. A model may help; the human signs off. Full stop.

If your agency moves next year from hourly billing to fixed prices or its own product, capturing today's process is the wrong first move. If you build almost only one-off custom work, there is little to repeat and so little to gain. If it has to be ready by the next sprint review, this will cost more attention than it returns in the first weeks. And where someone signs personally towards a client or an auditor, as with a go-live approval or a SOC 2 statement, keep a human in charge. A model may assist; the human signs off. Full stop.

If your main market shifts next year because your largest German customer is rebuilding its production line, capturing today's process is the wrong first move. If you build almost only one-off special machines with nothing repeated, there is little to gain. If you want a trick ready for the next tender round, this costs more attention than it returns in the first weeks. And for the risk assessment and the EC declaration of conformity, keep a person at the wheel. A model may help; a person signs. Full stop.

RENEW determines which processes you tackle, not which direction you want to go in. Without a clear direction, you’ll end up documenting the wrong process: see strategy.
The rhythm of three, six and nine must survive the hustle and bustle. When urgency and importance clash, urgency wins. The discipline to counter this lies with 4DX.
If your market is changing faster than your processes, start by analysing trends and uncertainty.

Think of a process that annoys you

Take a step back to take two steps forward.

One step back on customer onboarding, two forward.

Bring the one exception that returns every single week.

One sprint back, two releases forward.

Bring the process every order waits on.

We’ll sort it all out together in an hour.

a completed process page
a score on the five selection criteria
your payback period based on your own hours

No quote during that hour.