How to Triage and Summarize Support Tickets Across Channels with a Multi-Model AI Pipeline

Build a Spojit workflow that runs on a schedule, pulls your open Front conversations, classifies each one with a fast AI model and summarizes it with a stronger one, then writes a prioritized item to a Monday.com board with sentiment and category.

What This Integration Does

Support teams that live in Front often lose the bigger picture: which open conversations are angry, which are simple questions, and which need a senior reply today. This workflow reads your open Front conversations on a recurring schedule and turns each one into a triaged work item. A lightweight model does the cheap, high-volume work of classifying category and sentiment, and a more capable model writes a short resolution summary only where it adds value. The result is a Monday.com board where every open ticket is already labeled, summarized, and ranked by priority, so a person can work the queue instead of reading it.

The workflow is driven by a Schedule trigger, so it runs unattended on a Unix cron expression in your timezone. Each run lists current open Front conversations, loops over them, sends each one through two AI steps, and creates one Monday.com item per conversation. It writes new items each run and does not delete or reconcile existing ones, so to avoid duplicates you key off the Front conversation ID (described in the Tips) or run it against a board you treat as an append-only triage feed. Re-runs are idempotent only as far as your dedupe step makes them: with no dedupe, a conversation that is still open next run produces another item.

Prerequisites

A Front connection added under Connections with access to the inboxes whose conversations you want to triage.
A Monday.com connection added under Connections, plus the target board's ID and the column IDs you will populate (priority, category, sentiment, link).
An AI model available in your workspace for the classification and summary steps. A fast model for classify, a stronger model for summary.
Familiarity with the Workflow Designer: adding a Trigger, Connector, Loop, and Transform node and connecting them on the canvas.

Step 1: Start the workflow on a Schedule trigger

Add a Trigger node and set its type to Schedule. Enter a 5-field Unix cron expression and an IANA timezone. To triage every two hours during business hours on weekdays, use a cron such as 0 9-17/2 * * 1-5 with timezone Australia/Sydney. A single Schedule trigger can hold multiple schedules if you want different cadences. The trigger output is { scheduledAt }, which you can reference downstream as {{ input.scheduledAt }} for stamping when the run occurred.

Step 2: List open Front conversations

Add a Connector node in Direct mode, choose the Front connector, and select the list-conversations tool. Use the q field to scope the search to open work, for example a query that filters to your support inbox and open status. Front returns a page of conversations plus a pagination token, so set the node's output variable (for example front_open) and reference the list and the next-page token in later steps.

q: inbox:support is:open
page_token: (leave blank on first call)

To page through more than one screen of results, add a Loop in While mode that re-calls list-conversations with page_token set to the previous response's pagination token until no token remains. For a first build, processing the first page is fine.

Step 3: Loop over each conversation

Add a Loop node in ForEach mode and point it at the conversation list from Step 2 (for example {{ front_open.conversations }}). Inside the loop body, each iteration exposes the current conversation as a loop variable. If your list items are summaries, add a Connector node inside the loop using the Front get-conversation tool with id set to the current conversation's ID to pull full details (subject, latest message text, contact).

id: {{ conversation.id }}

Step 4: Classify with a fast model (structured output)

Inside the loop, add a Connector node in Agent mode and select a fast, low-cost AI model. Agent mode lets you attach a Response Schema so the model must return structured JSON instead of prose. Use a tight prompt that asks only for category, sentiment, and a priority score, and force the shape with a schema like the one below. This is the cheap, high-volume step: keep the prompt short.

Prompt:
Classify this support conversation. Subject: {{ conversation.subject }}
Latest message: {{ conversation.last_message.text }}
Return category, sentiment, and a priority from 1 (low) to 5 (urgent).

Response Schema:
{
  "type": "object",
  "properties": {
    "category": { "type": "string", "enum": ["billing", "bug", "how-to", "feature-request", "complaint", "other"] },
    "sentiment": { "type": "string", "enum": ["positive", "neutral", "negative"] },
    "priority": { "type": "integer", "minimum": 1, "maximum": 5 }
  },
  "required": ["category", "sentiment", "priority"]
}

Set the output variable (for example triage) so you can read {{ triage.category }}, {{ triage.sentiment }}, and {{ triage.priority }} downstream. Because the Response Schema forces JSON, these fields are reliable to map into Monday.com columns.

Step 5: Summarize with a stronger model

Still inside the loop, add a second Connector node in Agent mode, this time selecting a stronger model. Ask it to write a one-paragraph resolution summary plus a suggested next action. Attach a Response Schema again so the result is structured. To save AI credits, you can wrap this step in a Condition node that only runs the stronger model when {{ triage.priority }} is 3 or higher, leaving cheap tickets with the fast classification only.

Prompt:
Write a 2-sentence resolution summary and one suggested next action for this
support conversation, given it was classified as {{ triage.category }} with
{{ triage.sentiment }} sentiment.
Subject: {{ conversation.subject }}
Latest message: {{ conversation.last_message.text }}

Response Schema:
{
  "type": "object",
  "properties": {
    "summary": { "type": "string" },
    "next_action": { "type": "string" }
  },
  "required": ["summary", "next_action"]
}

Set the output variable to resolution so you can use {{ resolution.summary }} and {{ resolution.next_action }} when building the Monday.com item.

Step 6: Create a prioritized Monday.com item

Still inside the loop, add a Connector node in Direct mode, choose the Monday.com connector, and select the create-item tool. Set boardId to your triage board and name to the conversation subject. Map your structured AI fields into columnValues, which is an object keyed by column ID. Use the exact column IDs from your board (look them up with the Monday.com get-board tool if you do not know them).

boardId: 1234567890
name: {{ conversation.subject }}
columnValues:
{
  "status": { "label": "{{ triage.category }}" },
  "sentiment": { "label": "{{ triage.sentiment }}" },
  "priority": "{{ triage.priority }}",
  "text_summary": "{{ resolution.summary }}",
  "next_action": "{{ resolution.next_action }}",
  "link": { "url": "https://app.frontapp.com/open/{{ conversation.id }}", "text": "Open in Front" }
}

If you want to use a Transform node to assemble columnValues cleanly before the create step, add one between Step 5 and Step 6 and build the object there, then pass it into create-item. Optionally add a Front add-tag Connector node in the loop to tag the conversation as triaged so a future run can skip it.

Tips

Two models, two jobs: keep the fast classify prompt short (it runs on every ticket) and reserve the stronger summary model for higher-priority items via a Condition to control AI credit spend.
Always attach a Response Schema in Agent mode for both AI steps. Free-text output is hard to map into Monday.com columns and breaks when the model rephrases.
De-duplicate by Front conversation ID. Store the ID in a Monday.com column and, on each run, use the Monday.com list-items tool plus a Condition to skip conversations you already created an item for. Alternatively tag handled conversations in Front with add-tag.
Keep the Front q query narrow (one inbox, open only) so each run stays small and well under any per-run limits.

Common Pitfalls

Pagination: list-conversations returns one page plus a pagination token. If your queue is large, a single call misses older open conversations. Add a While loop on page_token or accept that you process the newest page each run.
Column IDs are not column titles. Monday.com's columnValues must be keyed by the internal column ID. Run get-board once to read the real IDs, and remember that status and dropdown columns expect a { "label": "..." } shape, not a plain string.
Timezone drift: the Schedule trigger cron runs in the IANA timezone you set, not the viewer's local time. A 0 9 * * 1-5 with the wrong timezone fires at the wrong hour for your team.
No built-in dedupe: re-runs create fresh items for any conversation still open. Without the dedupe step in Tips, the board fills with duplicates over a day.

Testing

Before scheduling it, switch the Trigger to Manual (or just press Run) and tighten the Front q query to a single test inbox with one or two open conversations. Confirm the classify step returns valid JSON, the summary step fires only when your Condition allows, and exactly one Monday.com item appears per conversation with the right column values. Inspect the run in execution history to see each loop iteration's output. If anything is off, ask Miraxa, the intelligent layer across your automation, "Why did my last run fail?" on the workflow page. Once a small batch looks right, restore the Schedule trigger and widen the query.