Procedures

A procedure tells the AI how to handle a kind of request, in your own words: what to look up, what to tell the customer, what to ask, and when to hand over to a person. For example, “Order status”: look up the order, give the carrier and tracking number if it has shipped, say when it usually ships if it has not.

You find them under AI Configuration → Procedures in the admin console at app.flexivity.ai , one list per brand. A brand also uses its parent’s procedures, unless it has its own with the same name.

Only an Admin can create, change or publish a procedure. A Knowledge Manager or a Read Only user can see every procedure with the controls switched off. See Users.

Starting a procedure

Choose New procedure, then one of:

• A sample. Flexivity ships five: Order status, Cancel before shipping, Damaged item refund (a Stripe charge), Damaged item refund (store order) (Shopify items) and Address change. Each shows where a lookup is used, where a condition guards a step and where the AI hands over. You can publish a sample unchanged or adapt it. The samples that change something come with two test conversations, one that should prepare the change and one that must not (an order that has already shipped, say). They are added to the procedure when you confirm what Flexivity understood, with each lookup’s result filled in for the lookups you chose. Edit or delete them like any other test.
• Paste your procedure. Paste the procedure your team follows and Flexivity drafts it for the AI, using only what your connected systems can do and saying where a person must act.
• Start blank.

Writing it

Write the steps in plain language, one per line. Give the procedure a When this applies sentence (“The customer asks where their order is”) and, if you like, kinds of request it is not for.

To name a lookup or an attribute, type @ and choose it from the list. The list shows your enabled data connector tools, grouped by system and marked looks up or changes, and your attributes. You do not have to use @: when you write “look up the order”, Flexivity proposes the right tool for you to confirm.

What Flexivity understood

A procedure has three tabs: Procedure (your text, who carries out changes, when it applies, and its versions), Reading and Testing. When you save, Flexivity reads your procedure and shows what it understood on the Reading tab: the steps in order, the tool each step uses, the questions it may ask, the conditions and the hand-overs. This usually takes under a minute.

• Check each step’s tool. You can swap a tool for another of the same kind.
• Check which questions ask for a file. A question such as “Could you send a photo of the damage?” is marked Asks for a file. It is answered only when the customer attaches a file, never by what they write about one (“I can send you a photo”), and a photo they sent with their first message is never asked for again. Tick or untick it where Flexivity got it wrong. On osTicket this needs Flexivity plugin 2.10.1 or later, which tells Flexivity the type of each file on a ticket (an attached file, or an image pasted into the message); with an older plugin the question is asked again however many files the customer sends.
• Check which questions ask which record. A question such as “Which order do you mean?” is marked Asks which record. It is not asked when a lookup has already found the one record the change is about (a customer with one recent charge), when the customer’s message names one of the records the lookup listed (“my alarm clock”, with only one charge described “Alarm clock”), nor when the customer’s own words answer it. Tick or untick it where Flexivity got it wrong.
• Choose which hand-overs say why. When a step hands the conversation to a person on a condition (“if the charge is more than 30 days old”), Flexivity shows the reason it would give the customer. It is sent only when you tick Tell the customer why, and only when the condition was checked against what a lookup returned. Leave it unticked for your own internal rules (“orders over $500 go to a person”): the customer is then told only that a colleague will handle their request. The customer is never told the request is refused; the person decides.
• Read the notes. Flexivity says where your text sets a rule that nothing enforces (“never refund shipping”), where no connected system can do a step (a person will), and where a step names a value your system has not been seen returning. It also says where a question’s condition depends on what a lookup returns (“if they have more than one charge”): such a question is asked before any change unless the customer’s own words answer it, so word it by what the customer has said (“if they have not said which item”) for it to be skipped when they have.
• Confirm the reading. A procedure is used only once you have confirmed what Flexivity understood. Confirming is what allows the AI to use the tools it names.

If something cannot work, for example a step names a tool that is turned off, Flexivity says so at that step and you cannot confirm until it is fixed.

Conditions and hand-overs

A condition such as “if the order total is over $500, hand over” or “if the customer is frustrated, hand over” is checked by Flexivity itself, not left to the AI: when it is met, the conversation goes to a person even if the AI had written an answer. If the lookup a condition depends on fails, Flexivity hands over rather than guess.

A condition that guards a step that changes something (“only if the order has not shipped, cancel the order”) is checked the same way.

Steps that change something

When a conversation reaches a step that changes something, such as cancelling an order or making a refund, the AI hands the conversation to a person. The customer gets your brand’s hand-over message. What the agent sees depends on who carries out that kind of change for the brand, set on the tool’s page in Data Connectors:

• Manual, a person does it: the agent sees what the procedure would do next (“cancel order #1004”), so they can do it.
• Assist, the AI prepares it and an agent approves it (the default): the agent sees the change ready on the ticket, with every check Flexivity ran, and approves, edits or rejects it. See Prepared Changes.
• Hold and Execute: where the AI may resolve conversations, the conversation is paused while an agent approves and then resumed by the AI (Hold), or the AI makes the change itself within its limits (Execute). Elsewhere they work as Assist. See Who carries out a change, which has a table of each mode at each level.

Under Who carries out changes, a procedure can restrict the changes it makes, overriding each tool’s own setting. A restriction only ever lowers a tool’s write mode, never raises it:

• No Restrictions (the default): each change tool’s own settings apply.
• Never Execute: each change under Execute follows Hold behavior, so a person approves every change.
• Never Hold: each change under Execute or Hold follows Assist behavior, so the conversation is always handed over.
• Manual: each change under any setting follows Manual behavior: the AI hands over with what to do.

Like the text, the choice is part of the draft and takes effect when you publish. A handling rule can restrict the changes on the tickets it matches in the same way; where both do, the stricter applies.

Test conversations

A test is a whole conversation, run before customers see the procedure. On the procedure’s Testing tab, under Test conversations, choose New test and write:

• Who the customer is and what they want, in your words: “Their vase arrived broken three weeks ago. They have a photo.” Flexivity plays this customer, answering what the replies ask.
• Their first message, and whether it comes with a file attached (a photo sent up front). Flexivity plays the customer attaching a file when a reply asks for one and the description says they have it.
• What each lookup returns. By default a lookup returns its shape, as your connected system showed it when you enabled it. Choose A mock I edit to set the values, such as a charge from 40 days ago, or A live lookup for a test ticket to read your system for the requester of a ticket marked as a test ticket (tagged flexivity-test on Zendesk; Flexivity set to Test ticket on osTicket). A change is never called in a test, so only lookups have a source.
• What must be true at the end, one line each: “A photo is asked for before anything is prepared”, “A refund is prepared for the vase’s amount”.
• Whether it should prepare a change or must not. A test where it should is an acting test; one where it must not, a refusing test.

Every test is also checked for one thing you do not write: the customer is never told a change happened before it did.

A test runs the conversation through the version shown, as a live ticket would, with each reply treated as sent to the customer. Nothing is sent, no ticket is changed, nothing in your systems is changed, and a test is not billed. The result shows the conversation, each lookup, what the step that changes something would have prepared (with every check the agent’s card would show), and whether each line held. An acting test fails if nothing was prepared; a refusing test fails if something was.

Your saved tests run on a version when you confirm its reading, and you can run one or all of them at any time. A test runs at most 20 times on one version.

The first test opens as the tab does; choose another test’s name to open it, and Run opens the test it runs. Runs lists its runs on the version shown, newest first and five to a page, each with when it finished (or, still going, since when), and how many times in a row it has passed there. Show opens a run. Edit test changes the test.

Publish sits at the top of the procedure, above its tabs. When the recommended tests are not met, Tests recommended appears beside it with what is still recommended; Publish stays available.

Versions

Editing a published procedure creates a draft; the published version keeps running until you publish the draft. A conversation that started on one version keeps using it, so publishing never changes a conversation already under way. Every version stays listed with who published it and when, and you can restore an earlier one as a new draft. A restored version, and a sample procedure, are drafts like any other: one that changes something needs its tests to pass on it before it is published. A procedure published before tests existed prepares no change until its tests pass on its version; until then, the agent sees what it would do, as with Manual.

Turning a procedure off

The switch beside the procedure’s name turns it Off or On. Off, the AI stops following it from the next customer message, in new conversations and in ones that were already following it. A change it already prepared stays on its ticket’s card for a person to approve or reject. Its versions and tests are kept, and tests still run, so you can check it before turning it back on. The procedures list marks it Off.

A brand’s procedure that is off also keeps out a procedure of the same name from a brand above it.

Deleting a procedure

Delete procedure, at the bottom of the Procedure tab, removes the procedure with every version, its test conversations and their runs, after you confirm. A live procedure stops being used at once. A change it prepared that is still waiting for approval can no longer be approved: reject it on its ticket. Only an administrator can delete.

When the AI uses a procedure

On a Zendesk or osTicket ticket at the Assist, Reply, Clarify or Resolve level, and in a Zendesk chat with a signed-in customer, the AI considers the brand’s published procedures whose tools are all available. You can narrow a procedure to tickets with certain attribute values under Applies only when.

For each message, the AI chooses the procedure whose When this applies fits, or none. With none, it answers exactly as it would without procedures. A conversation can move from one procedure to another, for example from Order status to Cancel before shipping.

A procedure whose tool has been turned off, or has a change waiting for your review, is not used until you confirm it again. The Procedures list says why a procedure is not in use.

What an agent sees

In the Zendesk sidebar and the osTicket panel, a Procedure section shows which procedure the AI followed, why it chose it and the step it reached. When the AI hands over, it also shows what was already done. The AI activity report shows the procedure and version for each conversation.

Limits

• Up to 25 procedures per brand.
• Instructions up to 5,000 characters; a pasted procedure up to 20,000.
• Reading a procedure and drafting from a pasted one are limited to 10 a minute for your account.