01 Choose just one process—and one that repeats

LOOP-R doesn’t improve “the company.” It improves one process at a time. Here, a process is a task that happens often, in the same way, and ends with an observable outcome. Three criteria help you choose: it happens at least dozens of times a month; it has a clear beginning and end; and the person doing it can observe the result.

Marcos, a real estate agent, receives about 80 contacts a month from listing sites. Replying to the first contact is a process: it starts when a lead arrives and ends when the lead replies (or doesn’t) within 24 hours. Listing properties, negotiating fees, and coordinating viewings are processes too—but they belong to other loops. If he tries to improve everything at once, he won’t know what caused what.

Think of a renovation done room by room: you don’t paint the whole house on a Saturday. You choose the living room, finish it, and only then move to the kitchen. The loop works the same way—and the first room should be the one that repeats most, because that’s where evidence accumulates fastest.

02 “From X to Y”—and without worsening what?

The loop’s goal has a fixed form: move [a number] from X to Y without worsening Z. Each part has a job. “A number” says what you measure. “From X” is where you are today. “To Y” is a target you’d be glad to reach. And “without worsening Z” is the part almost everyone forgets—and the part that protects the business.

Dr. Renata owns an aesthetics clinic and sends proposals over WhatsApp after consultations. Out of every 100 proposals, 3 become paid packages. Her goal became: “move conversion from 3% to 5% without worsening average margin or increasing complaints”. Why does the second half matter? Because a number by itself becomes a target—and a system that chases a target learns to cheat. If the request were only “close more proposals,” the version offering a 20% discount would win every time.

In support, the same trap looks different. Cláudio manages customer service at a small software company and asked to “reduce service time.” Without a “without worsening” condition, the winning version would close a ticket in two minutes without solving anything. His condition was: without increasing tickets reopened within 7 days.

03 The number must exist today—and be quick to measure

“From X” is a number you have, not the number you wish you had. If nobody tracks it today, the loop’s first task is to count it (that’s what lesson 3 does). There’s a second requirement: the number must respond quickly. There are three speeds. Metrics for money (conversion, ticket size, margin) take weeks to show up. Metrics for signal (customer replied, viewing booked) appear in hours. Metrics for artifact (does the proposal meet the checklist?) appear in minutes.

The difference changes everything because of the sample size that proves it. To prove a version converts 5% versus the current 3%, you need about 1,500 proposals per version. Dr. Renata sends 50 a week—it would take more than a year to complete a single test. But to prove the reply rate moved from 20% to 30%, about 300 per version is enough: 12 weeks at her pace. That’s why the clinic’s loop tests reply rate within 48 hours and only monitors conversion.

Marcos made the same switch. He wanted “more properties sold” (2 a month—impossible to test). The number his loop pursues is leads who reply within 24 hours of the first contact: 22 out of every 100 today. Sales are still what he wants; they’re just not what he measures every week.

04 Question 1 on the loop worksheet

A loop worksheet is the only thing you fill in. There are five questions—like the intake form a clinic asks for at a first appointment: you answer once, and every professional who sees you later reads it. The loop’s assistants read the worksheet the same way at every cycle. Answer 1 is exactly the sentence you built in the previous steps.

You’ll see an excerpt from the worksheet below. It looks like a registration form—and that’s exactly what it is: each row is a question you answer once, and the rest of the loop relies on it. You only edit the answers; the labels on the left stay as they are.

QUESTION 1 — goal (example: Dr. Renata’s clinic)
  process:       WhatsApp sales proposal
  number:         conversion — became a paid package within 15 days
  today:           3%
  target:          5%
  fast metric:  reply rate within 48h — now 20%, target 30%
  without worsening: average margin · complaints · requests to stop

Notice what the worksheet doesn’t promise: that conversion will reach 5%. What it guarantees is something else—no version that hurts margin or increases complaints becomes official, everything is recorded, and the cycle runs the same way every week. If the number rises, great; if it doesn’t, you haven’t lost what you had.

01 The loop only learns from what was done

The second letter in LOOP-R is Operate: do the actual work. It sounds obvious, but this is where many people try to skip ahead. You can’t improve a proposal that was never sent or a support exchange that exists only on paper. Every real execution is a chance to learn—and every execution that never happens is a missed chance.

Marcos, the real estate agent, replied to portal leads from memory. On Monday, with time to spare, he wrote three paragraphs and sent a property photo. On Thursday, in traffic, he sent “hi, interested?”. He executed 80 times that month—but they were 80 executions of 80 different things. When he asked AI “how can I improve my reply?”, AI had no way to answer: which one?

It’s like the difference between a recipe and “cooking like Grandma.” Grandma gets it right, but nobody can repeat or improve it, because her hand weighs things differently every day. A written recipe may be wrong—and that’s exactly why it can be corrected.

02 The current version needs to be written down

Before the first cycle, the process gets a current version: a short written script that describes how the work is done today. It doesn’t need to be good. It needs to be the same in every execution, so 200 proposals become 200 comparable cases—not 200 opinions.

Dr. Renata’s clinic version 1 had five blocks: greeting by name and thanking the client for the visit; a summary of what was observed during the assessment, in two or three sentences; an explanation of the recommended package; price and payment options; a friendly close, “available for any questions.” It fits in six lines. That script generated the first 200 logged proposals—and revealed the first finding: 166 out of 200 got no reply within 48 hours.

03 Doing it the same way is what makes things comparable

Following the current version to the letter may seem rigid. It’s the opposite: it’s what lets you make changes safely later. If two executions differ in five things at once and one does better, you don’t know which of the five made the difference. If they differ in one thing, you know. The fixed script is what lets the next lesson change one thing at a time.

At Cláudio’s support team, two agents replied to the same type of ticket in opposite ways: one sent step-by-step instructions with images, the other asked for remote access right away. The month’s numbers said 61% of tickets were resolved on first contact. But 61% of what? A mixture. When both agents started following the same version 1 (steps first, remote access only if that failed), the number fell to 58%—and for the first time it meant something.

This doesn’t mean nobody can improvise. It means improvisation doesn’t count. Anyone who goes off script writes “off script” on that execution’s row—and that row stays out of the comparison.

04 The Executor: the person who executes doesn’t judge

In LOOP-R, the one who executes is a single-purpose assistant called Executor. It gets the current version and the case data, produces the artifact (proposal, reply to a lead, ticket response), and logs one row. That’s all. It doesn’t judge whether the result is good, suggest changes, or “improve” anything on its own.

For Marcos, the Executor is the assistant that receives version 1 of the script plus the lead’s details (name, property clicked, neighborhood) and returns the first reply ready to paste into WhatsApp. If the script says “one question at the end,” it includes one question at the end—even if two might seem better in that case. The urge to “improve it on the fly” is exactly what it doesn’t do, because an on-the-fly improvement is invisible: nobody recorded it, nobody compared it.

It’s the same separation as on an assembly line: the person who assembles isn’t the inspector. Not because of distrust, but because of method. The person who did the work never sees it the way the person checking it does.

01 Evidence is not an opinion: one row per run

The third letter is Observe. This is where the loop’s intelligence begins—and it’s an unglamorous step: every run becomes a row, with its outcome recorded. No “I think shorter proposals work better.” The question is: how many were short, and how many of those got a reply?

At Dr. Renata’s clinic, the first 200 proposals using version 1 became 200 rows. The “replied within 48 hours” column added up to 34: a 17% response rate. Her worksheet said 20%—the number she “thought” was right. A 3-point difference isn’t huge, but it’s the first time the number left her head and made it onto paper. From then on, everything the loop proposes starts from 17%, not 20%.

Think of how a clinic handles blood pressure: it doesn’t ask “do you feel pressure?”; it measures, records, and compares with the last reading. Evidence is the recorded measurement. Opinion is “I feel.”

02 The columns in the process log

A process log is an ordinary spreadsheet—the one you already use will do. What changes is the discipline: one row per run, always with the same columns. It is answer 2 on the loop worksheet: “where the evidence begins.”

Below you’ll see the spreadsheet header. It looks like an accountant’s table, but works like the reception desk’s logbook: each column is a question answered once per row. The first three say what and when; the middle ones say which version; the last ones say what happened. You only fill it in; the column names never change.

id date version variant replied outcome complained notes L0041 2026-09-02 v1 A yes no no portal lead, 2-bedroom apartment L0042 2026-09-02 v1 A no no no L0043 2026-09-03 v1 A yes yes no visit scheduled for Saturday

Marcos uses exactly these columns. “id” is any code he makes up (L0041, L0042…); “version” is the script he followed (v1 for now); “variant” stays “A” until there’s a test; “replied” is his quick metric; “outcome” is his money metric (did the visit close or not); “complained” is the “no harm” metric. “Notes” is free-form—and where he writes “off script” when he improvises.

03 The source is the bottleneck—and so is the column definition

The loop assistants are the easy part. The hard part is that the evidence lives in different places: the clinic’s WhatsApp, the portal inbox, the ticketing system, a partner’s spreadsheet, the salesperson’s memory. Where the evidence begins is question 2 on the worksheet precisely because no one can answer it alone. No assistant will fetch data from your WhatsApp; someone—you, the receptionist, or the Executor when they write the artifact—has to bring each outcome to the row.

And every column needs a definition that fits yes or no. In Cláudio’s support team, “resolved” seemed obvious—until agents closed tickets without the customer agreeing. The definition became: “resolved = the customer did not reopen it within 7 days.” At the clinic, “replied” became “replied within 48 hours with something other than a refusal”: does “no, thank you” count as a reply? By this definition, no. Without that sentence, the version that gets more “no, thank you” replies would look like the winner.

04 How many rows until the spreadsheet tells you something

Ten rows teach you how to fill it in. They don’t support conclusions. The loop only accepts a pattern with at least 30 rows of the same type —and treats it as strong starting at 90. Below that, what looks like a pattern is almost always chance, so the spreadsheet saves the observation in a separate “observed, not tested” list to revisit when there are more rows.

With 12 leads recorded, Marcos noticed that “Tuesday leads reply more.” Three of the four Tuesday leads replied; only two of the other eight did. It looks like a pattern. With 12 rows, it’s nothing: one lead changing days would make the “discovery” disappear. The note stayed on the observations list. Eight weeks later, with 160 rows, Tuesday was no different from any other day.

01 Critique comes before the idea

The fourth letter is Propose. But proposing doesn’t start with creativity; it starts with a cool-headed reading of what the spreadsheet showed. In the loop, that reading has an owner: the Critic, a single-purpose assistant that examines the evidence and says what worked, what failed, and how strongly the evidence supports each claim. It doesn’t suggest a solution. It only diagnoses.

Looking at the clinic’s 200 proposals, the Critic noted: 166 of 200 got no reply within 48 hours (83%); the cost and time per proposal were steady (about five and a half minutes each); and version 1 ended with “let me know if you have any questions”—without asking the client to do anything. Three statements, three numbers. No suggestions. Only then does someone propose an idea.

It’s the mechanic’s order of operations: diagnosis first (“the noise is coming from the front suspension”), then the estimate. Anyone who proposes a fix before diagnosing may replace a good part.

02 IF, THEN, BECAUSE—the format that can be disproved

A LOOP-R hypothesis has three required parts. IF: what changes in the script, concretely. THEN: which number changes, and from what to what. BECAUSE: what evidence in the spreadsheet supports the bet. And a fourth practical part: the CHANGE —the exact edit to the current version’s text, so the Executor can follow it.

Here is the loop’s second real hypothesis from the clinic, as written by the Optimizer: IF we add a rule requiring no more than 80 words in total, THEN the response rate should rise from 17% (200 proposals) to at least 22%, BECAUSE 83% of proposals get no reply and the 5-part structure makes for a long WhatsApp message; shortening it reduces the reading cost before the price. CHANGE: under “Rules,” add the line “maximum 80 words in the full message.”

03 Every hypothesis carries the strength of its evidence

Not every hypothesis starts out equal. The Critic labels each claim: strong when backed by 90 or more rows of the same type; moderate starting at 30; weak below that. Strength determines the queue: strong hypotheses go to testing first; weak ones stay on the “observed, not tested” list until the spreadsheet grows. You can only test one thing at a time—the evidence strength tells you which one.

Marcos had two ideas. The first—“leads who ask for the price in their first message book fewer visits”—came from 25 leads, so its evidence was weak; it went on the waiting list. The second—“the current reply doesn’t end with a question”—came from the 130 rows recorded so far, 101 with no reply within 24 hours; its evidence was strong. The second went to testing: IF the first reply ends with one clear question (“Would you rather visit this week or next?”), THEN the 24-hour response rate should rise from 22% to at least 28%, BECAUSE 101 of 130 leads don’t reply and the current text doesn’t ask for a response.

04 A hypothesis is not a rule yet

Writing the hypothesis ends this letter, not the loop. It still has to pass through two gates. The first is the Guardian: an assistant that checks whether a change touches something that must never change on its own or puts a “no harm” metric at risk. If it does, the Guardian vetoes it—and that veto is final. The second gate is next lesson’s test. Only what passes both becomes the official version.

In Cláudio’s support team, 37% of the month’s tickets involved the same issue: the payment screen wouldn’t load. The hypothesis was clear: IF the first reply to this kind of ticket includes the three steps that solve 80% of cases, THEN first-contact resolution should rise from 58% to at least 65%, BECAUSE 112 of 300 tickets are about this issue and the standard reply only asks for more information. The Guardian approved it. At the clinic, though, the cycle’s first hypothesis—ending the proposal with one closing question such as “Would you rather start this week or next?”—was vetoed before any test. The same idea Marcos was allowed to test stopped there: Dr. Renata’s worksheet had zero tolerance for complaints, and a forced choice puts pressure on exactly that metric. The Guardian reads each loop’s worksheet, not a general rule.

A hypothesis that seems great but gets vetoed isn’t a failure. It’s the loop showing that the worksheet was taken seriously.

01 “Seems better” proves nothing

The fifth letter is Reinforce: test the hypothesis, evaluate the result, and only then incorporate—or discard it. The important words are only then. Between the hypothesis and the official version there is a test, and the test has an outcome that doesn’t depend on anyone’s taste.

Marcos read the first twenty replies written with the new version (the one that ends with a question) and liked them: more direct, friendlier. He wanted to change the script that day. What he had was an impression about twenty messages—not a single outcome row. Those twenty replies could be lovely and still get fewer responses than the old ones. He wouldn’t know.

It’s the difference between a medicine that “seems to have helped” and one tested against another. The first is a story; the second is a result. The loop only accepts the second.

02 A and B side by side, at the same time

A LOOP-R test is simple to describe: half of the runs follow the current version (A), the other half follows the candidate (B), during the same weeks, chosen at random. The spreadsheet’s “variant” column, which was set to A, now alternates. The Experimenteris a single-purpose assistant: it calculates the sample size needed for proof, estimates how many weeks the test will take at your current pace, and writes the stopping rule before the test begins.

Why at the same time, instead of “this month with B, last month with A”? Because months change: at Dr. Renata’s clinic, December has holidays and January has vacations, and the response rate shifts by 8 points without anyone changing anything. If B runs in January and A ran in December, the difference may come from the calendar, not the script. With A and B mixed into the same weeks, the calendar affects both equally.

03 The test has three possible answers

When the test ends—or each week while it runs—the Evaluator reads the spreadsheet and gives one of three answers. B won: the difference is bigger than chance can explain, the required sample size has been reached, and no “no harm” metric fell beyond its allowed margin. A stays: B didn’t win, or it won on the main metric but lost on a guardrail. Not enough data: there aren’t enough rows to say anything yet—keep testing. There is no fourth answer. There is no “it’s winning.”

The third answer is the most common, and it has to be acceptable. To prove that the response rate rose from 20% to 30%, you need about 300 runs in each version; at Dr. Renata’s pace of 50 a week, that takes 12 weeks. In Cláudio’s support team, after three weeks of testing, B had resolved 41 tickets on first contact versus 38 for A—66% versus 61%. He wanted to stop: “B is winning.” The Evaluator said there wasn’t enough data because the worksheet required 220 tickets per version, and there were only 62 each. Stopping early because it’s winning is the most common way to make an imaginary difference official.

04 Winning on the main metric isn’t enough: the guardrails

B only wins if it raises the number and none of the “no harm” metrics exceeds the tolerance written on the worksheet. Both conditions must hold. If the number rises 40% and the margin drops by one point with zero tolerance, the answer is A stays—no exceptions, no “but look how much it went up.” The Evaluator applies the rule as written; if the rule is poorly written, you fix it for future tests.

In support, Cláudio’s version B finished testing with 220 runs per variant: first-contact resolution rose from 58% to 66%. But tickets reopened within 7 days rose from 4% to 9%, with a 2-point tolerance. A stays. B resolved tickets “faster” by closing ones that came back—the exact trick the “no harm” metric was designed to catch.

There’s one thing to watch with the tolerance. For frequent metrics (margin, reopenings), zero tolerance works. For rare events —one complaint in every 100, one “stop messaging me” in every 200—zero tolerance can’t separate an effect from chance: in 300 runs, 1 or 4 complaints may be the same noise. The loop’s rule is that the tolerance for a rare event should be at least as large as the expected noise at the planned sample size—about 1 point for 1% events in 300 rows. Writing zero there isn’t rigor; it can reject good hypotheses by chance.

05 Make it official—with a rollback button

When the verdict is B won, the decision still goes through you: at most once a week, you get a five-line card—what changed, how much it improved, what was monitored, what it cost, and three buttons: approve, reject, or wait for more data. If you don’t respond by the deadline, the default is not to make it official. Once approved, the candidate becomes the current version, and the old one is saved in the version history with rollback.

The rollback button isn’t decoration. During the first cycle after a change, the loop checks whether the test metric or a “no harm” metric fell below the old version’s result. If it did, the old version becomes official again, and the reason is recorded. This is the LOOP-R’s one unambiguous guarantee: the system won’t choose a worse version—and if one slips through, there’s a way back.