Issues get reported informally.<\/p>\n
Somebody sends a WhatsApp message \u2014 sometimes with a photo, sometimes a screenshot, sometimes a voice note. “The printer on floor 2 is showing an error again”, or a picture of a broken part with no text at all.<\/p>\n
None of that is a ticket.<\/strong> It has no title, no priority, no category, no reporter field.<\/p>\n So somebody reads it and types it into Jira.<\/strong> That is the work being removed here.<\/p>\n The input is free text and media<\/strong>, written by whoever noticed the problem.<\/p>\n No rule handles it.<\/strong> Keyword matching breaks on how people actually write \u2014 “this is unacceptable” and “I’m really not happy” mean the same and share no words.<\/p>\n A model can read the message and produce structure:<\/strong> a title, a description, a category, a suggested priority.<\/p>\n That is the justified use.<\/strong> Everything else in this workflow is ordinary logic.<\/p>\n FIGURE 1: THE CHAIN<\/p>\n Message arrives<\/p>\n Media handled<\/p>\n AI extracts<\/p>\n Ticket created<\/p>\n Messages arrive with attachments, and this part is easy to get wrong.<\/p>\n Three things to handle:<\/strong><\/p>\n Download it.<\/strong> The message references the media; you have to fetch it.<\/p>\n Attach it to the ticket.<\/strong> A photo of a broken part is often the most useful thing in the report.<\/p>\n Handle the case where it is the only content.<\/strong> Somebody sends a photo with no text at all. What then?<\/strong><\/p>\n Two options:<\/strong> ask them to describe the problem, or create the ticket with the image and a note that no description was given.<\/p>\n Decide in advance.<\/strong> This case is common and it should not be handled by whatever the workflow happens to do.<\/p>\n Ask for specific fields, not a summary.<\/p>\n A title.<\/strong> Short and descriptive. This is what appears in a ticket list.<\/p>\n A description.<\/strong> The problem, in structured prose. Keep the original message too.<\/p>\n A category.<\/strong> From your existing list, not one it invented.<\/p>\n A suggested priority.<\/strong> As a suggestion.<\/p>\n Two rules that make this reliable:<\/strong><\/p>\n Give it your actual categories.<\/strong> A model choosing from a list you supplied produces usable values. A model inventing categories produces a mess in your Jira configuration.<\/p>\n Keep the original message on the ticket.<\/strong> Always. The extraction can be wrong, and whoever picks up the ticket needs to see what was actually said.<\/p>\n Worth being firm about.<\/p>\n A model can suggest a priority. It should not set one that skips a queue.<\/strong><\/p>\n Why:<\/strong> priority determines what gets attention. A model reading urgency from tone will overrate a politely worded serious problem and underrate an angry trivial one.<\/p>\n A workable approach:<\/strong> the model suggests, the ticket is created at a default priority with the suggestion in a field, and a person adjusts during triage.<\/p>\n FIGURE 2: WHAT THE MODEL DECIDES AND WHAT IT DOES NOT<\/p>\n The model produces<\/p>\n A person decides<\/p>\n Who sent this, and are they in your system?<\/strong><\/p>\n Match on phone number<\/strong> \u2014 you have it.<\/p>\n Which means consistent formatting<\/strong>, as in every WhatsApp integration. Country code, no spaces.<\/p>\n Decide what happens for an unknown sender:<\/strong><\/p>\n Create a contact? Route to a general queue? Reject with a message explaining who can report issues?<\/p>\n Decide before go-live<\/strong>, not when the first one arrives.<\/p>\n The same problem gets reported by three people.<\/strong><\/p>\n Two approaches:<\/strong><\/p>\n Check for a recent similar ticket<\/strong> before creating. Harder than it sounds \u2014 “printer broken” and “can’t print” are the same issue and share no words.<\/p>\n Create them all and let triage merge them.<\/strong> Simpler, and it means somebody sees every report.<\/p>\n The second is usually more honest.<\/strong> Automatic duplicate detection on free text is unreliable, and a missed report is worse than a merged one.<\/p>\n Send one.<\/strong> It costs nothing and it prevents two problems.<\/p>\n What it should say:<\/strong><\/p>\n The ticket reference.<\/p>\n What you understood the problem to be.<\/strong> This is the important part \u2014 it gives the reporter a chance to correct a misreading immediately.<\/p>\n What happens next.<\/p>\n Because they messaged you, a service window is open<\/strong> \u2014 you can reply freely without an approved template.<\/p>\n FIGURE 3: FOUR THINGS THAT MAKE THIS WORK<\/p>\n Keep the original message<\/p>\n Categories from your list<\/p>\n Priority as a suggestion<\/p>\n Confirm what you understood<\/p>\n Good fit:<\/strong><\/p>\n Internal issue reporting.<\/strong> Staff reporting problems from where they are.<\/p>\n Field reports.<\/strong> Technicians on site with a phone.<\/p>\n Customer-reported faults<\/strong>, where the customer already messages you.<\/p>\n Poor fit:<\/strong><\/p>\n Low volume.<\/strong> Under a handful a day, a person reading them is fine.<\/p>\n Complex intake.<\/strong> If a report needs ten structured fields, a form is better than a message.<\/p>\n Anything safety-critical.<\/strong> Do not put a model between a person and an emergency.<\/p>\n Four things:<\/strong><\/p>\n If the model fails<\/strong>, still create a ticket. With the raw message and a flag. Never lose a report<\/strong> because an extraction step failed.<\/p>\n If media fails to download<\/strong>, note it on the ticket rather than silently dropping it.<\/p>\n If Jira is unreachable<\/strong>, retry and then alert. The message must not vanish.<\/p>\n Log the original, the extraction and the created ticket.<\/strong> When a ticket comes out wrong, you need all three to see what happened.<\/p>\n The principle throughout: a failed step should degrade the ticket, never lose the report.<\/strong><\/p>\n A model reads an informal message and produces a structured ticket \u2014 title, description, category, suggested priority.<\/p>\n Justified because the input is free text<\/strong>, which no rule handles.<\/p>\n Keep the original message on the ticket.<\/strong> Give the model your real categories. Treat priority as a suggestion a person confirms.<\/p>\n And make sure a failure degrades the ticket rather than losing the report.<\/p>\n Issues reported by message and typed into a tracker by hand?<\/p>\n Get in touch. We build message-to-ticket workflows that keep the original report and leave triage decisions with your team.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" The problem Issues get reported informally. Somebody sends a WhatsApp message \u2014 sometimes with a photo, sometimes a screenshot, sometimes a voice note. “The printer on floor 2 is showing an error again”, or a picture of a broken part with no text at all. None of that is a ticket. It has no title, […]<\/p>\n","protected":false},"author":3,"featured_media":9287,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[28],"tags":[],"class_list":["post-9283","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-n8n"],"yoast_head":"\nWhy this needs a model<\/h2>\n
\n
\n
\n
\n
Handling media<\/h2>\n
What the model should produce<\/h2>\n
Priority is a suggestion<\/h2>\n
\n
\n
Matching the reporter<\/h2>\n
Duplicates<\/h2>\n
The confirmation reply<\/h2>\n
\n
\n
\n
\n
Where this fits<\/h2>\n
Failure handling<\/h2>\n
The short version<\/h2>\n