Skip to content
Pitaj.io

Steps & Decision Trees

Procedures in Pitaj.io are structured as sequential step pipelines enhanced with conditional branching (If/Else logic).

Procedure Step Types

When composing a new procedure, you have access to the following building blocks:

Step TypeDescriptionExample
Agent MessageDeliver fixed explanatory guidance“Please locate your 8-digit order number from your receipt.”
Option Chips (Buttons)Prompt visitor with clickable choices[Transit Damage] [Incorrect Item] [Defective Device]
Collect InputWait for structured user input stored to a variableText, email, phone number, or photo attachment
Conditional BranchEvaluate conditions against prior inputsIf issue == “Incorrect Item”, jump to Step 4; Else Step 6
Execute ActionTrigger an API endpoint or open a formVerify hardware serial number against warranty database
Handover to HumanEscalate conversation to Help Desk live inboxNotify available agents with high-priority audio alert

Production Walkthrough: Warranty Claim Flow

Here is how a standard 3-step claim workflow behaves:

  1. Step 1: Issue Classification

    • Message: “We are sorry to hear that you are encountering an issue. What describes the problem best?”
    • Buttons: [1. Physical Damage] [2. Hardware Defect] [3. Return Request]

  2. Step 2: Collect Order Reference & Photo Evidence

    • Agent prompts: “Please enter your order reference and attach a clear photo of the damage.”
    • Customer uploads photo directly inside the chat window.

  3. Step 3: Automated Ticket Creation & Confirmation

    • System registers a support ticket with tag Priority: High and appends the uploaded photo.
    • Assistant: “Thank you. Your warranty claim has been logged under #CLM-402. Our support team will follow up within business hours.”

Handling Unexpected User Inputs (Fallbacks)

What happens if a user submits “I do not want to share my email” when email verification is required?

Pitaj.io features an adaptive input validator:

  • If the submission fails syntax checks, the assistant politely clarifies why the attribute is required.
  • Following 2 failed attempts, the procedure gracefully falls back to human escalation or logs an offline inquiry.