Triage new Podio support requests before anyone opens them

Trigger this from a Podio webhook on my Support Requests app, firing when a new item is created. The webhook payload carries the item id.

First, pull the full request with the Podio Get item operation using the item id from the payload. Read the requester, the subject, the body of the request, the current category field if one is set, and the created time. Everything after this step works from that content, not from the webhook payload alone.

Next, look for precedent. Use Podio Search in app, scoped to the same Support Requests app, running two or three short searches built from the distinctive words in the request: product names, error text, feature names, the specific thing that broke. Ignore generic words like help, issue or problem. Exclude the item that just arrived. For the closest matches, read the item and its comments so you can see how it was actually resolved, not just that it existed.

Now decide severity using this rubric, and apply it the same way every time. Urgent: a complete outage, data loss, a security exposure, payments or billing failing, or a whole team or site blocked with no workaround. High: a core feature broken with no reasonable workaround, or a hard customer deadline inside the next 24 hours. Medium: something degraded or partly broken where a workaround exists, or a question that blocks work but not immediately. Low: how-to questions, cosmetic issues, feature requests, documentation, anything with no time pressure. Judge on the impact actually described, not on how the customer worded it. A customer writing URGENT on a how-to question is still low. When a request sits between two levels, pick the lower one unless the customer explicitly describes a production outage.

Pick the category from the options that already exist on the category field in the app. If it is a fixed option field, choose only from the existing options and never invent a new one. If nothing fits well, choose the closest option and say in your comment that the fit was poor.

Write both values back with the Podio Update item field values operation, one call per field: the category field, then the severity field.

Then post one internal comment on the item with the Podio Add comment to object operation, using ref type item and the item id. The comment should contain: a one line summary of what the customer actually needs; the category and severity you assigned with a one sentence reason tied to the rubric; a draft first response written to the customer in a warm, plain, professional voice, clearly labelled as a draft for a human to send; and up to three of the closest past requests, each with its title, a one line note on how it was resolved, and a link to that item. If none of the past requests are genuinely similar, say that plainly instead of padding the list with weak matches. The draft reply must never promise a timeline, a refund or a fix date.

This is deliberately human in the loop. Do not email or otherwise reply to the customer, and do not send anything outside Podio and the Slack alert described below. The draft response exists so a person can read it, edit it and send it themselves.

Then create the follow up work. Use the Podio Create task operation with a title in the form Triage: <subject> (<severity>), a description containing the one line summary and a link back to the item, and a due date set by severity: urgent is due two hours from now, everything else is due end of the next business day, skipping weekends. Then use the Podio Assign task operation to hand it to the queue owner for the category you chose, using the routing map I configure. If a category has no owner listed, assign it to the default support owner and note that in the comment.

Finally, announce urgent requests only. When and only when the severity is urgent, use the Slack Bot Send a Message action to post to my support channel: the customer, the one line summary, why it was rated urgent, the link to the Podio item, and who the task was assigned to. Low, medium and high severity requests must never post to Slack, so the channel stays worth reading.

Two safety rules. If the item already has a severity set or already carries a triage comment from a previous run, stop rather than duplicating the work. And if any step fails, still post what you have as a comment on the item so a human is never left with an untouched ticket.