diff --git a/modules/sysadmin_guide/nav.adoc b/modules/sysadmin_guide/nav.adoc
index 8cd2ae9..1d10b49 100644
--- a/modules/sysadmin_guide/nav.adoc
+++ b/modules/sysadmin_guide/nav.adoc
@@ -108,6 +108,7 @@
 ** xref:status-fedora.adoc[Fedora Status Service - SOP]
 ** xref:syslog.adoc[Log Infrastructure - SOP]
 ** xref:tag2distrepo.adoc[Tag2DistRepo Infrastructure - SOP]
+** xref:tickets.adoc[How to handle new tickets in fedora-infrastructure - SOP]
 ** xref:torrentrelease.adoc[Torrent Releases Infrastructure - SOP]
 ** xref:unbound.adoc[Fedora Infra Unbound Notes - SOP]
 ** xref:virt-image.adoc[Fedora Infrastructure Kpartx Notes - SOP]
diff --git a/modules/sysadmin_guide/pages/tickets.adoc b/modules/sysadmin_guide/pages/tickets.adoc
new file mode 100644
index 0000000..ae69c99
--- /dev/null
+++ b/modules/sysadmin_guide/pages/tickets.adoc
@@ -0,0 +1,153 @@
+= How to handle new tickets in fedora-infrastructure
+
+This SOP describes the process of handling incoming tickets on
+https://pagure.io/fedora-infrastructure.
+
+== Contact Information
+
+Owner::
+  Fedora Infrastructure Team
+Contact::
+  #fedora-admin, #fedora-noc
+Location::
+  https://pagure.io/fedora-infrastructure
+Purpose::
+  Fedora infra ticket tracker
+
+
+== Ticket workflow for standard tickets
+
+This ticket workflow is applied to any ticket Infra Team finds in tracker and it's related to
+issue that really falls under Fedora Infra Team umbrella. This will be evaluated by the Infra
+Team itself, but everything related to apps Fedora Infra Team maintains automatically falls
+in this category.
+
+. Identifying new tickets
++
+The tracker is being checked by the Fedora Infrastructure Team twice per day from Monday to
+Thursday. The new tickets can be recognized by not having any label and are in priority
+*Needs Review*.
+
+. Adding labels to tickets
++
+____
+The team will look at each ticket and evaluate the trouble and gain this ticket
+represents.
+
+Gain could be:
+
+* *low*
++
+Affects only few users
+
+* *medium*
++
+Affects some of the Fedora users
+
+* *high*
++
+Affects most of the community
+
+Trouble could be:
+
+* *low*
++
+Will take less than a day
+
+* *medium*
++
+Will take less than a week
+
+* *high*
++
+Infra team is not sure how much time this will take or it takes more than one week
+
+There are also two additional types of tickets *ops* (needs sysadmin attention) and *dev*
+(needs developer attention).
+
+If there are some things we need to clear with the reporter, we switch the ticket to
+*Waiting for reporter* priority and wait for the reply before adding the trouble, gain, ops/dev
+label.
+____
+
+. Assigning tickets
++
+If the ticket has labels we can switch it to *Waiting on Assignee* or assign it, if there
+is someone who wants to take it.
+
+== Ticket workflow for apps we don't maintain
+
+This ticket workflow is applied to any ticket Infra Team finds in tracker and it's related to
+app that Fedora Infra doesn't maintain.
+
+. Identifying new tickets
++
+The tracker is being checked by the Fedora Infrastructure Team twice per day from Monday to
+Thursday. The new tickets can be recognized by not having any label and are in priority
+*Needs Review*.
+
+. Find the maintainer
++
+Look for the maintainer of this app.
+
+* Maintainer is known
++
+Ping it in the ticket.
+
+* Maintainer is not identified or not active
++
+In this case new ticket should be created "<App> is without maintainer" and the following
+should be done:
+
+** Add your investigation outcome to ticket
++
+Anything found out or known about the application should be added to this ticket.
+
+** Short time outage (optional)
++
+If there isn't clear if the application is used in infrastructure schedule a short outage
+and see who will respond.
+
+** Decide what to do with it
++
+The app is without maintainer and the investigation revealed what is the purpose of this application.
+There are now multiple options to choose from:
+
+*** It's no longer useful
++
+Shut it down and remove the ownership.
+
+*** It's useful, but doesn't fit Fedora Infra mission
++
+Put a 3 quarter timer for a shutdown
+
+**** File a ticket with the appropriate board/council that the application has no owner and is a threat
+to the stability of the project for reasons documented in the ticket. Let them know that you will need
+to either remove/replace/get an owner for it. Give a 1 quarter deadline for guidance so they can come to a conclusion.
+
+**** Put it in a quarterly planning cycle to do what is needed to shutdown it.
+
+**** Use the last quarter to deal with any roadblocks (we could not replace it, we could not remove it,
+we could not get an owner for it.)
+
+*** It's something we need
++
+Find POC in CPE team for it.
+
+*** It's something that could be offloaded/migrated away from
++
+In this case Fedora Infra should investigate the situation.
+
+****  Add an investigation to https://pagure.io/fedora-infra/arc[ARC team board], prioritized by Product Owner
+
+**** Figure out if it's an iniative, or a mini-initiative or just standard ticket
+
+**** Schedule it, do it, drop our application
+
+. Resolve the ticket
+
+* Close it if the application is shut down
+
+* Work on it if it's now Fedora Infra owner application
+
+* Let the maintainer work on it and leave the resolution on them