Skip to main content

Design Change Request — AI Agent Idle Action: Step-List Builder

FieldValue
ToWulan (Design)
FromDimas Fauzi Hidayat (PM, BOT squad)
Date2026-07-05
FeatureAI Agent — Sequential Idle Follow-up (ai-agent-idle-action initiative)
PRDSequential Idle Follow-up — see CHG-002 + story IDLE-ADJ-S01
BE contractFrozen — BE RFC §2.4 (reviewed 8.5/10). The fields and rules below will not move under you.
What we needFigma frames for the step-list builder (list below). This is the blocking dependency for the FE RFC and build kickoff.

Why (1 paragraph)​

Today the AI Agent's idle action fires one action after one timer — nudge or close, never "nudge, then close". Customers have asked for a polite multi-step wind-down ("Are you still there?" → "Last reminder" → auto-close). The backend now supports an ordered sequence of up to 3 steps, each with its own action, timer, and message. The configuration UI is the only missing piece.

Where it lives today (prototype reference — read-only)​

qontak-designer → app/pages/bot-automation/ai-agents/[id].vue, Advanced settings → "Idle action" section (≈ lines 717–900). Current anatomy, all Pixel components:

  1. Idle action select (MpPopover + list) — options incl. resolve / assign / follow-up.
  2. Customer idle time — hours + minutes inputs (MpInputGroup with unit addons).
  3. Assign conversation (only when action = assign) — MpRadio trio: Any available agent / Specific division / Specific agent, each with its select.
  4. Closing message textarea.

The same section appears on the create flow (app/pages/bot-automation/ai-agents/create/).

The change (single picker → step list)​

Replace the single action block with a step list of 1–3 rows. Each row is essentially today's full block, repeated:

Per-step elementRules (frozen by BE contract)
Actionone of Follow up / Assign / Resolve — no new action types
Customer idle timehrs + min (stored as seconds; min 1 s, max 24 h). Step 1 measures from the customer's last activity; steps 2–3 measure from the previous step firing — worth conveying in helper text
Messagerequired for Follow up and Resolve; optional for Assign
Assign targetrequired when action = Assign (same trio as today: any / division / agent)

List-level interactions:

  • Add step — disabled (with reason) once 3 steps exist. Hard cap, not a soft warning.
  • Remove step — per row; minimum 1 row remains.
  • No reordering for this phase (steps run strictly top-to-bottom; drag-reorder is out of scope — PRD Non-Goal 4 has no branching/jumping).
  • Last-step hint — when the final step is Follow up (non-terminal), show an inline informational hint: "conversation stays open after the last nudge". Informational, not blocking — saving is allowed.
  • Legacy mode — when the feature flag is OFF for the org, the form renders today's single-action UI unchanged. (Flag-ON orgs with an old single-action config should see it as a 1-step list.)

Frames we need (suggested set)​

  1. Default state — 1 empty step row (empty state of the section).
  2. Filled 3-step sequence (Follow up → Follow up → Resolve) — the hero case.
  3. A step with Assign expanded (radio trio + division select open).
  4. Cap reached — 3 rows, Add step disabled with its affordance/tooltip.
  5. Last-step-is-Follow-up hint visible.
  6. Validation errors — empty required message; idle time out of range (field-level errors; the API rejects the whole save, nothing partial).
  7. Legacy single-action fallback (flag OFF) — likely just a reference to the existing design, called out for completeness.
  8. Loading / saved-success states if they differ from the section's existing patterns.

Non-goals (don't design for these)​

  • More than 3 steps; step templates; conditional branching between steps; new action types (e.g. send template / webhook / tag); reordering; per-channel step variants.

Acceptance checklist for the frames​

  • Every per-step element above appears with its required/optional state
  • Add/remove affordances follow the cap (≤3) and floor (≥1)
  • Last-step Follow-up hint present and non-blocking
  • Error presentation matches the section's existing field-level pattern
  • Uses existing Pixel (Mp*) components — flag any net-new component you believe is needed so we can raise it early

Open design questions (yours to decide or bounce back)​

  1. Row presentation: repeat the full block per row, or a collapsed summary-row that expands to edit? (3 full blocks may get tall.)
  2. Step numbering/visual sequencing: numbered badges, timeline connector, or plain stacked cards?
  3. Where the last-step hint sits: inline under the row vs a banner under the list.

Ping Dimas when frames are ready — the FE RFC will be authored directly against them.