Dispatch is a Phoenix web application for managing and triaging support tickets with automated urgency scoring.
- Provides a web interface for users to submit support tickets, including their name and issue details.
- Automatically assigns an urgency score to each ticket using a background process (currently random, with future plans for keyword/AI-based scoring).
- Supports real-time updates and notifications via Phoenix PubSub.
- Built with Ash Framework for resource and domain logic, and AshPostgres for persistence.
- Includes job processing, pubsub, and extensible resource actions for ticket management.
- Ticket creation, listing, and deletion
- Automated urgency scoring on ticket creation
- Real-time updates via PubSub
- Extensible resource and domain logic with Ash
- Modern Phoenix LiveView UI
-
Install dependencies:
mix setup
-
Start the Phoenix server:
# if db isn't already running docker compose up -d mix phx.server # or for IEx iex -S mix phx.server
-
Visit the app: Open http://localhost:4000 in your browser. The ticket list is here.
- Use
mix precommitbefore pushing changes to run formatting, tests, and unlock unused deps. - See
AGENTS.mdfor project and coding guidelines. - Ticket resource logic is in
lib/dispatch/tickets/. - Urgency scoring logic is in
lib/dispatch/tickets/urgency_scorer.ex.
- Elixir
- Phoenix Framework
- Ash Framework
- AshPostgres
- Oban (for background jobs)
- Tailwind CSS (for styling)
This is actually my first Phoenix 1.8 project, I've been working with 1.7 for awhile. I really like the improvements, but they through me off at first.
I just wanted something working at first, so I got the form and index page working.
I then added eventing to the creation, destruction, and scoring of tickets.
I added the event listening to the index page so that it would update automatically without the need of a refresh.
I then created the urgency scorer as a GenServer and generates a random decimal between 0 and 1 as the score.
Then I focused on documentation.
I decided not to add tests for this, though I'm a big believer in having tests.
If it was decided to use this prototype further, I'd first add tests to make sure I don't add any regressions further down.
I'd then also switch to using test driven development as needed.
- MVP might be a checkbox for the user to say the issue has halted the job, which would give a much higher score.
- Regex would be an easy way to start extracting certain terms for scoring, though that might be a very large regex object.
- Next I would see if there was a library that scored text by urgency already out there and try to implement it, depending on how intensive that process is I might implement oban to process those.
- I then would focus more on UX, especially for the ticket input form. The who would be determined by the logged in user (in an already authenticated system) so that's one input removed.
- I would then work to implement the Web Speech API to add speech to text functionality for the issue details. I think having the input be the first screen for workers in the field would be something to look into.
- Maybe we could have the whole page for field workers be controlled via speech? Maybe something to look into in the future.
- Adding photo support would be a big addition I think.
- Adding a ticket queue locally for offline functionality, that would send the queue up when the device gains access to the internet again. This might need background processing. Service worker?
- This page needs a search functionality.
A way to make urgent issues stand out and not just have them on the top. Different colors for different tiers of urgencies perhaps? - A way to automatically increase the urgency score based on due dates would help too.
- A way to take action on a ticket, whether that's a way to message the ticket issuer for clarification, or just mark as resolved.
For more information on Phoenix, see: