KIBI HELP · OWNERSHIP

Give the next enquiry a clear owner.

Set up a readable rule, check what it actually matches and test the exceptions. Learn when an enquiry goes to one person, takes turns or waits Unassigned for the team.

Follow the setup steps ↓
CONNECT AND CHECK

Follow the task, step by step.

  1. Open Routing rules in the correct workspace. Check that your plan includes rules and your account can Set up sources, forms and routing.
  2. Type who should get which enquiries, then inspect the When and Then choices Kibi proposes. Correct the condition, person or action instead of relying only on your sentence.
  3. For more than one condition, choose all of these or any of these deliberately. In Then…, choose One person, Take turns, The team or Their last owner. Choose Use this to keep the edited action.
  4. Add a first step only if it fits the receiving person’s work. Give the rule a recognisable name and choose Save rule.
  5. Under Your rules, check which rules are On and their order. Use Move up or Move down where necessary: the first enabled matching rule normally decides.
  6. Check Otherwise, each source decides. Open the relevant source and review Who receives these enquiries; save any changed fallback setting.
  7. Use Try it — where would this enquiry go? with the source, service, fields, arrival time and other conditions you intend to test. Read the selected rule and owner after the result settles.
  8. Send a recognisable, authorised test submission through the actual source. Inspect the resulting owner, history and next action. Check Unassigned separately, then restore any temporary availability or rule changes.
BEFORE YOU START

Agree what responsibility should mean for this source.

Start with one supported source and the people who handle its enquiries. Decide who answers a normal request, who covers an absence and who checks work left Unassigned. A rule can choose an owner; it cannot make the team’s coverage decision for you. Check that the source delivers the service, choice or other field you want to use before writing a condition around it.

Routing & team access · Available. Routing rules are included on Team and Growth. Your account also needs Set up sources, forms and routing permission. If you can inspect the rules but cannot save a change, ask the workspace owner to review your access and plan. Use fictional details for an initial test and keep the change small enough that its result can be checked before more sources depend on it.

WRITE & REVIEW

The editable rule is the instruction Kibi follows.

Open Routing rules and type a plain sentence describing the enquiries and their recipient. Kibi turns it into editable When and Then choices. Read those choices carefully. A name shared by two teammates or a phrase that could mean several services can produce a draft different from your intention. Select the actual person and field values before saving; the original sentence alone is not enough evidence.

Choose a condition to edit it, add another with condition, or deliberately choose every enquiry for a catch-all. When several conditions exist, all of these requires the combined match, while any of these allows one matching condition. Keep that choice explicit. A rule for one source and one service will behave differently if it only needs either the source or the service to match.

Open the Then choice to inspect its recipient mode. Add Plan a first step only when the action and timing make sense for the incoming work. A planned call or text is a task for a person, not proof that a customer has been contacted. Choose Use this, give the rule a useful name and Save rule. Confirm the saved rule appears in Your rules.

RULE ORDER

Put specific decisions before a broad catch-all.

Kibi checks enabled rules from top to bottom. The first matching rule normally decides the owner, so a broad rule near the top can prevent a more specific rule below from being used. Review the numbered order under Your rules and use Move up or Move down to change it. Read the resulting order after the save settles; a matching count does not by itself show that the intended rule won.

A deliberate The team action is a valid result: it leaves matching enquiries Unassigned rather than continuing until a later rule finds a person. Off rules are skipped. Their last owner has a particular exception when no available previous owner can be used; that rule falls through to the next rule or source. Keep this different from a rule that successfully matches but has nobody available in its selected rotation.

  • Check the first rule that could match, not just the rule you intended.
  • Put a catch-all last unless it is meant to override the other rules.
  • Turning a rule off changes new routing; it does not undo ownership already assigned.
PEOPLE & AWAY

Different recipient modes have different exceptions.

One person sends matching new enquiries to that selected person when they are Available. If they are Away, the matching rule leaves the enquiry Unassigned for the team; it does not fall through to a later backup rule. If you need shared absence coverage, use an appropriate Take turns pool or another deliberately reviewed arrangement. Do not assume a single-person rule automatically finds a substitute.

Take turns rotates through the selected people and skips Away members. If nobody in that pool is available, the matching rule leaves the enquiry Unassigned. Their last owner tries the person who previously owned work for that contact; without an available previous owner, the next rule or source decides. The team deliberately leaves the work for someone to pick up. These are different results, even when more than one ends as Unassigned.

In Team, use Available or Away for your own availability; an owner can change other people’s availability. Agree how active work will be covered before someone leaves. Marking a person Away controls new assignment choices; it does not transfer all their existing enquiries or fulfil their due promises. Review and reassign current work separately, with the context and next action intact.

  • One person + Away: Unassigned; later rules are not a backup.
  • Take turns + everyone Away: Unassigned.
  • Their last owner + no available previous owner: continue to later rules or source.
  • The team: intentionally Unassigned.
SOURCE FALLBACK

A source decides when no routing rule applies.

The bottom of Routing rules shows Otherwise, each source decides. Open the relevant source and find Who receives these enquiries. Its setting is the fallback when no enabled rule matches. Review the person, team choice or rotation shown there, then Save any change. A website source and an email source can have different fallbacks; changing one does not configure every arrival route.

Fallback is not an extra rule that always runs after an unsuccessful owner choice. A matched One person rule whose person is Away has already decided to leave the enquiry Unassigned. So has a matched rotation with nobody available. Test a genuinely non-matching enquiry to see the source fallback. If the source itself uses an Away default owner or an unavailable pool, it can also leave work Unassigned.

TRY THE EXCEPTIONS

Use the simulator before sending an actual submission.

Use Try it — where would this enquiry go? to choose Comes from, Service and the relevant custom fields. Arrives offers example times, and the panel also lets you try Returning customer, an unfinished form and a message. The result identifies a matched rule or explains that the source decides. Wait for the result to settle before comparing it with your expected outcome.

The simulator is a dry run: it saves no enquiry and does not advance the rotation. It helps check conditions and order without adding customer work. It does not prove that the public form sends the same mapped fields, that a real returning contact has the assumed prior owner, or that a teammate receives a notification. Test the actual source separately after the rules look right.

The draft preview can say how many enquiries from the last 30 days would match. That is a condition preview, not a promise to reassign the historical records. A new rule can correctly have no historical matches. Concentrate on the inputs you intend to receive and the exceptions your team needs to handle, rather than trying to increase the caught count.

  • Try one matching enquiry and one that should reach the source fallback.
  • Try an overlapping case to prove the intended rule order.
  • Check absence and returning-contact behaviour with a deliberate coverage plan.
  • Avoid changing another person’s availability merely to experiment on live work.
CHECK THE REAL HANDOFF

Verify a fresh enquiry and the person receiving it.

After saving, submit a recognisable authorised test through the actual form, email or other source. Use its normal visitor path rather than only the rule simulator. Open the resulting enquiry and compare the source, mapped fields, owner and history with your expected result. If the rule plans a first step, confirm that the task and timing are appropriate. Ask the receiving teammate to read the request and identify what to do next.

Changing rules affects new routing; it does not reroute every enquiry already saved. Pausing a source is also different from switching off one rule: new submissions to a paused source can be saved Unassigned without normal routing. Resuming the source applies to new arrivals, while its earlier paused records still need review. Do not use a successful fresh test as evidence that the existing backlog has been reassigned.

IF IT IS UNASSIGNED

Start with the reason, then check the earliest decision.

First check whether the source is paused and whether the enquiry has the fields your rule expects. Then inspect the first enabled matching rule, its recipient mode and the relevant person’s availability. A rule can match exactly as written while leaving work Unassigned for a valid reason. Missing source or service values, an earlier catch-all and an Away single-person assignee require different corrections.

If no rule matches, inspect Who receives these enquiries on the source. If a previous-owner rule falls through, check whether the contact actually has an available previous owner. If a rotation is empty of available people, decide who covers the work rather than repeatedly sending test enquiries. For an existing record, use the permitted ownership controls and leave a useful next action; a rule edit alone does not repair it.

If saving or simulation reports an error, preserve the rule name, source name, time and exact visible message. Recheck after the request settles. Share a minimal redacted example with the workspace owner or support, not a full customer export or source secret. Treat an enquiry’s visible assignment and the teammate’s ability to find it as separate checks from email delivery.

KEEP IT UNDERSTANDABLE

Leave an explanation the next owner can use.

Keep names and conditions narrow enough for another authorised person to understand. When a source adds a field, a teammate leaves or the team changes coverage, review the affected rules and fallbacks together. Read the editable condition and action, not only an old sentence. A custom field used by a rule is a dependency; remove the reference deliberately before expecting to remove that field.

Finish a change by checking one fresh normal case and its relevant exception, then restore temporary test settings. Name who watches Unassigned work and how existing promises will be covered during absences. Record the expected result in your team’s setup notes. The useful outcome is a customer request with a responsible person and sensible next step, with an explicit process for anything waiting for the team.

THE PRACTICAL QUESTIONS

Decide with the details.

Does an Away single-person assignee cause the next rule to run?

No. A matching One person rule leaves the new enquiry Unassigned when that person is Away. Their last owner has different fall-through behaviour when there is no available previous owner.

Does the simulator create an enquiry or advance a rotation?

No. It is a dry run. Use a separate authorised submission through the real source to verify field mapping and the resulting handoff.

Will changing a rule reassign the old enquiries?

No. Rule changes affect new routing. Review existing ownership and due work separately; turning a rule off or changing source fallback does not automatically move the backlog.