Correct something Connect got wrong
Fix the message in front of you, then decide where the lesson belongs. A correction can live on one message, on one thread as guidance, on the person or channel as memory, or in Knowledge as a fact the whole business answers from. Editing a draft fixes the message and teaches nothing; a rejection on its own is a decision about one reply rather than a lesson.
The four places, from narrowest to widest#
| Place | Reaches | Use it when |
|---|---|---|
| The draft itself | One message | The wording is wrong here and nowhere else |
| Guidance on the thread | One conversation | This customer's situation needs handling a particular way until it closes |
| A memory row | One contact, one endpoint, one channel or the workspace | It is a standing preference about how to deal with someone or something |
| Knowledge | Every answer, everywhere | Connect stated something factually untrue about the business |
The choice is not about how annoyed you are; it is about how far the correction should reach. Putting a one-off phrasing preference into Knowledge makes every future answer worse, and leaving a factual error at thread level guarantees it recurs on the next enquiry from somebody else.
Working through one#
Fix the immediate message. Edit the held draft and approve it, or reject it if it should not exist at all.
Result Your edit is what goes out — Connect does not rewrite over it. The customer gets the right answer today, which is the urgent half.
Ask what kind of wrong it was. A wrong fact, a wrong tone, a wrong decision to act at all, or a wrong assumption about a person are four different faults with four different homes.
Result You know which of the four places to write in before you write anything.
Write the correction as a positive statement of what is true or what to do, not as a complaint about the reply.
Result "Our standard lead time is quoted from despatch, not from order" is usable. "Stop getting lead times wrong" is not.
For a factual correction, put it in Knowledge and let the fact be derived from it rather than typing the sentence into an instruction.
Result Answers are grounded in Knowledge, so the correction applies wherever the question comes up rather than only where you remembered to mention it.
Make the same question happen again — a test call, a message to the mailbox from an outside account, or a regenerated draft on the thread.
Result This is the proof. A correction is verified by the next answer being right, never by the settings screen having accepted it.
Corrections that do not stick, and why#
- You edited the draft and expected it to learn
- An edit is applied to that message and is not read back as a lesson. If it represents a rule, write the rule down as well.
- You rejected it and expected it to understand
- A rejection is recorded against the thread and stops the same reply being drafted again immediately. It is a decision about one message; the reason has to be given separately as guidance or memory.
- The correction is at the wrong tier
- Memory resolves workspace, channel, endpoint, then contact, narrowest winning. A workspace-level correction loses to an older contact-level note that contradicts it — which is correct, and usually surprising.
- The old fact is still in Knowledge
- Adding a truth beside an untruth leaves two. Remove or amend the source that carried the wrong statement rather than out-writing it.
- The draft you are looking at predates the correction
- Regenerate rather than re-reading. A held draft is not rewritten by a later change, which is also why a stale draft can answer a message the customer has already followed up.
When the mistake was acting at all#
Sometimes nothing about the wording was wrong and the fault was that a reply went out unattended. That is not a correction, it is an autonomy decision: narrow the mode at the scope that matches — this contact, this mailbox, this channel — so the next one is held for a person. Writing "be more careful" into memory does not achieve this, because care is not a gate and the model cannot enforce one on itself.
Whatever you change, the decision log will answer the question you are going to ask in a month: what was decided, by what, under which rule, and what happened. Refusals are recorded there too, because a refusal is a decision. If you cannot work out which instruction produced a reply, that trail is the shortest route to it.
Questions#
Does Connect learn from being corrected automatically?
Not from an edit or a rejection on its own. What changes future behaviour is a durable record — guidance on the thread, a memory row at the right tier, or a Knowledge source. The design is deliberate: silent learning from edits would make behaviour untraceable.
How do I correct something Connect said on a phone call?
Same principle, different surface. The factual part belongs in Knowledge; how it should have been said belongs in the behaviour text or the voice profile, and is proved by a test call and its review rather than by ear.
Can I see what corrections are already in force?
Yes. The memory viewer shows every tier for a person or a channel, including the tiers that are empty, and anything there can be forgotten. Knowledge shows its sources and the facts derived from them.
Which wins if two corrections disagree?
The narrower one. That is the same resolution rule autonomy uses, and it is what lets one customer be handled differently from everybody else without special-casing the whole workspace.