diff --git a/docs/.vuepress/config.js b/docs/.vuepress/config.js
index a424f3cd..65c603f3 100644
--- a/docs/.vuepress/config.js
+++ b/docs/.vuepress/config.js
@@ -69,6 +69,7 @@ module.exports = {
             'quarterly-review',
             'security-basics',
             'security-incident-response',
+            'handling-emergency-requests'
           ],
         },
         {
diff --git a/docs/guides/handling-emergency-requests.md b/docs/guides/handling-emergency-requests.md
new file mode 100644
index 00000000..b04ccab5
--- /dev/null
+++ b/docs/guides/handling-emergency-requests.md
@@ -0,0 +1,36 @@
+# Handling Emergency Requests From Clients
+
+First and foremost, we try to honor the clients who have put their trust in Tandem to handle their web needs. Dealing with emergencies efficiently bolsters our clients' trust and should spark a sense of pride in our team. Handling these situations should hopefully end up feeling similar to helping any friend with a personal emergency. The friend should be understanding and respectful of your boundaries, and you should be understanding of the stress this emergency is placing on your friend. With all of this in mind, here are some guidelines to how we should handle emergency requests from clients:
+
+1. If the client has a project in active development (this could be ongoing development on a project or a support retainer), handling of emergencies should be fairly straight forward if the request comes in during normal business hours. We simply re-prioritize the current sprint to move the emergency before other work, which means other work may get bumped to the next sprint.
+
+2. If the client does not have an active project or retainer, and is therefore not scheduled for work in the current sprint, they can elect to escalate the issue to a 'P2' level emergency.
+
+3. If the emergency needs to be handled outside of Tandem's standard business hours, requiring a team member to work during nights and/or weekends, the client can elect to escalate the issue to a 'P1' level emergency.
+
+Note that, without an SLA, response to the initial issue is always best-effort. We should always respond to emergency requests as quickly as possible, but we don't have a pager system for non-SLA carrying clients that will alert our team.
+
+## Priority Levels
+
+### P2 "Standard Emergency Rate": Normal Business Hours Non-Scheduled Work
+
+P2 emergencies are charged at an elevated fee compared to our standard rate (as detailed in the applicable SOW). This is done to cover the costs of additional compensation for our staff to handle these emergencies and also as a means to encourage healthy scheduling expectations. When a client's request pushes into a P2 scenario, Tandem should give written notice of the elevated charges and get confirmation from the client in writing that they accept the charges. The notification could be something like:
+
+> Hey Steve! I just wanted to send you a note confirming that we got your request to jump on resolving that issue with the site going down during the sale. We've scrambled the team and they're checking the New Relic data to track down what is slowing things down. As we didn't have any work scheduled this week for your project, we're slotting this in as an emergency which will be at an elevated rate of $XXX. Can you just shoot me back a quick confirmation that you approve? Thanks!
+
+### P1 "Off-Hours Emergency Rate": Non-Business Hours High Priority Emergencies
+
+P1 emergencies are any emergency that falls outside of our normal business hours, requiring a team member to work extra time on nights/weekends and taking time away from their loved ones to go above and beyond the call of duty in assisting our customers. Tandem values healthy boundaries between our work and personal lives because we believe it leads to healthier and happier employees (which also translates into better quality work!).
+
+In recognition of the extra work we ask out of our team in these cases of high-level emergencies, Tandem charges its highest rates for this kind of work to ensure we can compensate our team members for the extraordinary effort. The same principles apply as with P2 requests. Ensure we let the client know the costs are going to be elevated, and ask for confirmation that they understand the costs.
+
+## Coordinating our Response
+
+Emergencies always alter the course of our planned work. As a developer, you should immediately ping your project manager and let them know you have to jump on an emergency. If that lucky person happens to also be you, then you also get to handle the next level, which is to make sure Alec knows about the issue.
+
+We do this for a few reasons:
+
+1. We may need to let other clients know about a shift in plans.
+2. You might need help! Working on an emergency can be stressful, and it's often best done with a team. Communicating with the client about an issue makes it difficult to stay in the code and troubleshoot and/or fix the issue. When possible, splitting these functions up can greatly reduce stress and possibly improve our performance in solving the issue.
+
+Ultimately, the goal of our emergency policy is to ensure we're able to handle the inevitable surprises that come up while maintaining our commitments to our clients and keeping Tandem the calmest place to work we possibly can.