# Your first week

Week one has one theme: make the drafts good enough that loosening autonomy is a small decision rather than a leap. That means adding knowledge where drafts were vague, writing standing instructions where you kept editing the same sentence, turning on one more channel, and letting the first follow-ups come round so you can see the chase actually happen.

- **Status:** Available
- **Audience:** both
- **In the app:** #/knowledge, #/maya-rules, #/follow-ups, #/autonomy
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/getting-started/first-week/

## Let the edits tell you what is missing

The most reliable guide to what your Knowledge lacks is your own editing. Every time you rewrite the same part of a draft, that correction belongs somewhere durable. Which somewhere depends on how widely it should apply:

| The correction | Put it in | Scope it reaches |
|---|---|---|
| A fact about your business is wrong or missing | Knowledge | Every answer, every channel |
| The tone is not yours | A standing instruction on Connect Rules | Future behaviour, stated once |
| Something specific to one customer | Memory at the contact tier | That person only |
| Something true of one mailbox or number | Memory at the endpoint tier | That mailbox or line only |
| This person should not be contacted at all | A block directive on the contact | Every channel, permanently, until removed |

> **Note** A rejection is not a lesson. Rejecting a draft records a decision about one message and stops that draft; it does not teach anything. If the reason will recur, write it down as guidance or memory in the same sitting, while you still remember what annoyed you.

## Add one channel, not three

A second channel doubles what you have to judge. Add the one your customers actually use — for many businesses that is WhatsApp, for others the phone — and give it the same treatment email got: hold everything, read what is written, then decide.

1. Configure the channel's provider on `#/integrations`, or on that channel's own screen where it has one.
   - Result: Inbound arrives and appears alongside email in the same conversation list, resolved to the same people.
2. Set that channel's autonomy explicitly on `#/autonomy` rather than relying on the workspace rule.
   - Result: The channel-scoped rule now beats the workspace one, so a change to email later cannot quietly change WhatsApp.
3. Watch one full day of it before touching the mode again.
   - Result: You have seen how the channel's shorter, faster messages differ from mail — which is the whole reason to scope autonomy per channel.

## Let a follow-up come round

Follow-ups are the part that is hard to evaluate in an afternoon, because the interesting moment is when one falls due. Create a couple deliberately in the first days — a chase on a quote, a check-in after a delivery — and watch what happens at the due time.

- Follow-ups exist on `email`, `whatsapp`, `sms`, `phone`, `any` and `task`.
- The `task` channel is work for a person. Nothing ever sends it; it appears as work to do, which is exactly right for 'ring the supplier yourself'.
- Phone follow-ups drain a couple at a time and go through the same gates as any outbound call — a line that is not ready is retried later rather than forced.
- A phone follow-up more than a day late is closed as missed rather than rung, because a very late call-back is worse than none.

## Deciding whether to loosen autonomy

By the end of the week you have a body of evidence: the drafts you approved unchanged, the ones you edited, and the ones you rejected. Loosen narrowly rather than globally. Autonomy resolves contact → endpoint → channel → workspace with the narrowest winning, so a sensible first move is `autonomous` on one quiet endpoint — a mailbox handling order confirmations, say — while the rest of the workspace keeps asking.

If the answer is 'not yet', that is a legitimate long-term setting. Some workspaces run on `ask_before_send` permanently and get most of the value: the writing, the research, the memory and the chasing all still happen — only the final send waits for a person.

## Questions

### How much knowledge is enough?

Enough that a draft stops being generic, which is usually less than people expect. Grounding material is budgeted before it reaches the model, so adding a fifty-page policy document does not put fifty pages into every answer. Short, specific, correct entries beat volume.

### Should I write rules or just correct drafts as they come?

Both, in that order of preference. Correcting a draft fixes one message; a standing instruction changes the behaviour. The signal that you need a rule is repetition — the third time you make the same edit, stop editing and write it down instead.

### Is a week the right amount of time?

A week is a convenient unit, not a threshold. What actually decides readiness is volume: a workspace that saw two hundred messages knows more about its own drafts than one that saw six, whatever the calendar says.

## Related

- [Your first hour](https://connectbyjbrh.com/docs/getting-started/first-hour/)
- [Teach Connect about your business](https://connectbyjbrh.com/docs/getting-started/teach-connect-your-business/)
- [Create your first follow-up](https://connectbyjbrh.com/docs/getting-started/your-first-follow-up/)
- [A weekly review](https://connectbyjbrh.com/docs/getting-started/weekly-review/)
- [Write a standing instruction that works](https://connectbyjbrh.com/docs/how-to/write-a-standing-instruction/)
- [Follow-ups in Connect](https://connectbyjbrh.com/docs/follow-ups/)

## What this page is based on

- docs-source/sources/GENERAL.md §5, §6, §7 — autonomy scopes, memory tiers, follow-ups
- Connect capability registry (docs-source/facts.py)
- docs-source/sources/GENERAL.md §4 — screens and routes