Write Your First Rule in 60 Seconds

Morgan runs the office at Sabir Homes. Last Thursday she was on her third coffee and still stewing about a water-heater inspection that had closed the week before without a pressure reading. Third time that month. She had told the operators. She had put it in the group chat. It kept happening.

She opened Runbook, tapped the plus button, and typed the sentence she had been saying to herself all week:

I never want a water heater inspection to close without a pressure reading.

She did not open a configuration screen. She did not pick fields from a dropdown. She typed the sentence and watched Runbook turn it into a proposed rule.

That is the gesture. One sentence, a readable preview, a dry test, and then activation. That is the whole pitch.

What the engine did with the sentence

The parser recognized the nouns and verbs it already knew about this business. "Water heater inspection" is a procedure in Morgan's library. "Close" is an execution state. "Pressure reading" is a field on one of the procedure's steps. The sentence compiled into a rule that gates the close action on the presence of that field.

Morgan saw a preview under the text box with the trigger, the gate, and the escalation target. She could read it. It said what she meant. The preview is the part that matters, because she can check the system before it starts enforcing anything.

Screenshot placeholder: Policy Author proposed-rule card for: "I never want a water heater inspection to close without a pressure reading." Show the generated policy name, trigger, required pressure-reading gate, and activation controls.

If the parse had been wrong, she would have fixed it in plain English. "Not every inspection. Just the water heater ones." The rule would update. No jargon, no nodes, no arrows.

Before activation, Runbook ran the rule against recent ledger entries. The dry test showed the same pattern Morgan had been seeing by hand: this would have caught three missed readings in the last month. That was enough. She activated it.

Screenshot placeholder: Dry-run results for the proposed water-heater rule. Show the matched-event count, at least one matching ledger entry, and the enabled "Activate policy" state.

What happened after she tapped Activate

Nothing, for about an hour.

Then Alex finished a water-heater inspection at a property on Maple and tried to close it. The close did not go through. A banner on his phone told him the pressure reading was required. He went back to the step, took the reading, and closed the execution cleanly.

He did not call Morgan. Morgan did not call him. The rule did its job and got out of the way.

By the end of that week the rule had fired eleven times. Ten of those, the reading was already in — the rule was quiet. Once, it caught an operator about to close without it. Morgan has not thought about pressure readings since.

Why this is different from every other tool

Every other SMB tool asks you to describe what your business already does. You fill out templates. You map workflows. You sit through onboarding. The tool documents you.

Runbook asks what you want your business to be. Not what it does today — what you wish were true. You say it. The engine enforces it.

Morgan's policy was the forty-third Sabir Homes has authored. Each one started the same way: a frustration, a sentence, a tap. Jamiel wrote the one about routing water-heater reports within 24 hours. Morgan wrote the one about the electrical-panel photo. They did not sit down for a policy-authoring session. They each wrote a sentence the week they needed it.

The business absorbs intent one line at a time. Forty-three lines in, Sabir Homes is a company whose owner is not in the field and whose admin is chasing exceptions instead of reminders. That is what the sentences compound into.

Open Runbook. Type the frustration you had this week. Read the preview. Run the dry test. Turn it on.