(Ticketing) Give user easy way to report issue

[mattdjenkinson]

It would be cool when a user is shown an error toast or error page that we surface an easy way for the use to file a bug report/speak to a team member/ask an agent.

[JoseSzycho]

I can imagine creating a dedicated CRD for this, something like:

apiVersion: support.miloapis.com/v1alpha1
  kind: BugReport                                                                                  
  metadata:                         
    name: bug-abc123
  spec:
    userRef:                                                                                    
      name: user-42
    correlationId: "req-550e8400-e29b-41d4-a716-446655440000"                                          
    errorCode: "ORG_NAME_CONFLICT"
    errorMessage: "Organization name must be unique"
    timestamp: "2026-04-28T14:30:00Z"                                                                  
    userDescription: "I tried to create an org called 'acme' but got an error"
    requestContext:                                                                                    
      method: POST                                                                                     
      path: /api/v1/organizations                                                                      
      userAgent: "..."                                                                                 
  status:         
    phase: Acknowledged
    notes: "Assigned to support team"                                                                  
    resolvedAt: null          

I’m not sure how deep we want to go with this functionality, since we could end up building full CRM-style APIs to manage the entire lifecycle of a report, or, we could keep it simple and reuse the existing Notes API to attach notes to any BugReport.

For communicating with customers, I found some open-source chat alternatives, like:
https://github.com/rocketchat/rocket.chat

However, this might be overkill for our use case. A simple asynchronous, self-built API, or open source ticket-system could be sufficient.

[drewr]

Some thoughts sketched out in https://github.com/datum-labs/support

[mattdjenkinson]

LOVE this @drewr. My only concern is should we be building a full ticketing system from scratch or leaning on a third party to do the heavy lifting? Would you envision this fully replacing our HelpScout integration for example?

[jacobsmith928]

@mattdjenkinson yeah the idea would be to replace helpscout or other external interfaces that pull us as operators away from Milo.

I have not spent much time digging but some resources to consider beyond "build from scratch" include leveraging an open source project for the undifferentiated but valuable bits:

FreeScout
Chatwoot
RocketChat

[drewr]

The value proposition of Milo is that the heavy lifting (auth, users, groups, product integration, api, schema, basically all the hard decisions) is done for you. I don't know that a ticketing system "module" in itself is that hard of a problem.

[drewr]

Draft of what done looks like for a first round:

• Cloud users (agent or human) can easily discover how to open a thread with the Datum team that requires resolution (a ticket)
• Staff users (agent or human) can respond to tickets and interact with cloud users
• Staff users can assign and reassign tickets
• Cloud users and staff users can paste screenshots into tickets
• Staff users can promote comments to knowledge base entries
• Staff users can search knowledge base
• Tickets can be tagged
• A staff user can be "on-call" which means they get notified of incoming tickets

[mattdjenkinson]

@drewr i've added this to the 1.5 release and will take the lead on this feature. I do think we should slim down the feature list for this first iteration though. Here's what i think would be valuable and reasonable over the next couple of weeks;

• Cloud users (human) can easily discover how to open a thread with the Datum team that requires resolution (a ticket)
• Staff users (human) can respond to tickets and interact with cloud users
• Staff users can assign and reassign tickets
• Cloud users and staff users can paste screenshots into tickets
• Tickets can be tagged

---

Stretch

• Staff users can promote comments to knowledge base entries - Would this tie into our notes service? Where would these then live etc
• Staff users can search knowledge base
• A staff user can be "on-call" which means they get notified of incoming tickets - This seems like a big feature in itself, it would be cool to have a schedular

[drewr]

I've added it as well as a candidate for talking about tomorrow. Hold off on doing much yet. @kaleygel and @kevwilliams are discussing some tradeoffs here.

[JoseSzycho]

@mattdjenkinson @scotwells is it a good approach to use a CRD for storing messages?

As the APIServer won't list the messages in order, as cannot order by creation date.

The FE would need to list all messages of a conversation and order them in the browser, which I don't think it will be an issue, as I don't expect conversations to be long.

Or we would need to implement the search system in the cloud portal.

[drewr]

We should have search in the cloud portal. Seems trivial to do in GraphQL too.