As EAs, when we think about how to create SOPs, we often forget how much operational knowledge we already carry in our heads.
We know how our Executive likes their inbox handled, which meetings need prep and which ones do not, who actually needs to be copied on an email, how travel should be booked, and what can wait until tomorrow.
The problem is that most of this knowledge stays in our heads, in the habits and workarounds we have built over time. That works really well until it doesn’t.
Things start to creak when the workload spikes, priorities change quickly, or someone else needs to step in, because suddenly decisions that normally sit with you have to be explained, processes have to be rediscovered, and routine work takes longer than it should as you rethink steps you usually do on autopilot. This is where standard operating procedures can help, by acting as practical notes that explain how work actually gets done in your role.
In this article, we will explore how to create SOPs that actually save you time as an Executive Assistant, focusing on practical ways to document how you work so they support you day-to-day. SOPs that support your work, reduce repeat explanations, and make it easier to step away, without everything grinding to a halt. Nothing here is about creating extra admin. The goal is to make your working day easier, especially on the days when everything feels manic.
Transform the Way You Work with 101 Must-Have Tools and Technologies
Whether you’re looking to master the latest tech trends, simplify complex tasks, or bring fresh ideas to your organization, this comprehensive resource will empower you to work smarter, not harder. Don’t miss out—download your copy now and take your EA game to the next level!
Why SOPs matter in the EA role
As EAs, the volume of repeat work is high, even though no two days ever look the same. When you start thinking about how to create SOPs, this is usually where it becomes obvious just how much repeat work sits inside your role. Inbox management, calendar changes, meeting prep, travel updates, project follow-ups, and requests from different colleagues all stack up really quickly. A lot of this work is pretty routine on a regular day, but it still requires your thought process every time you do any of this work.
On top of that, we switch context constantly. You might be deep in planning a meeting one minute and pulled into an urgent request from your Executive the next. When you are supporting more than one Executive, that switching ramps up fast, because each person has different preferences, priorities, and ways of working that you will often hold in your head.
SOPs matter because they take some of that thinking off your plate. They give you a reference point for how you handle repeat tasks, so you are not deciding the same things over and over again. This is why understanding how to create SOPs in a way that fits your role matters so much, especially when you are covering holidays, handling sickness, onboarding cover support, or handing work over at short notice.
Consistency is really hard when days are unpredictable, but it is still expected from you because, as an EA, you are often the person your colleagues look to when everything is moving at a pace. Your Executive expects things to run smoothly, whether you are stretched, covering for someone else, or stepping away yourself. SOPs help create that consistency by capturing how you work when things are going smoothly, so you are not relying on memory when things are busy.
For us as EAs, SOPs exist to reduce thinking time. They take a little time to put together, but they actually make repeat work easier rather than adding another layer of admin to your day, which is often the reason EAs avoid learning how to create SOPs in the first place.
The EA rule for deciding what’s worth documenting
One of the biggest reasons EAs avoid SOPs is the fear of creating too many and then not really using them. The worry is that you will end up documenting everything, spending hours writing processes, and adding more work to an already full plate.
That is not the goal. As EAs, we need a much lighter filter. When you are deciding whether something is worth turning into an SOP, it helps to pause and ask a few simple questions rather than defaulting to “I should probably document this.”
It is usually worth documenting a process if you do it weekly or monthly, if you have already explained it more than once, if someone else might realistically need to pick it up at some point, or if getting it wrong would create extra work for you later. Those situations tend to be where time is lost through repeat explanations, small mistakes, or having to redo work that should have been straightforward.
On the flip side, you do not need to document everything. If something is genuinely only a one-off, easy to explain in a quick message, or faster to just do than to write down, it is not a good candidate for an SOP. A helpful rule of thumb is this. If it takes longer to write the SOP than the time it will save you over the next few weeks or months, skip it. You can always come back to it later if it becomes repetitive or frustrating.
A realistic SOP structure for EAs
Once you have decided something is worth documenting, the next question is how much structure it actually needs, especially when you are thinking about how to create an SOP that you will actually use.
For EAs, the structure should be light enough that you can follow it mid-task, without scrolling through pages or translating formal language into what you actually need to do, but detailed enough that it covers all of the process.
Start with a clear name
The SOP name should tell you exactly what it covers. This sounds obvious, but vague titles are one of the reasons SOPs get consigned to the dusty files at the back of your filing system.
So be really practical and specific when you name your SOP. “Inbox triage for VP of Sales” is far more useful than “Email process.” Then you should be able to tell at a glance whether this SOP is the one you need when you search for it.
Be clear on when to use it
Every SOP needs a trigger – when do you actually need to use it. That might be when a new meeting request comes in, when travel needs to be booked, or when I am handing work over before annual leave. If there is no clear starting point, the SOP will sit unused because you are never quite sure when to open it.
Name who owns it
Ownership matters, even if that owner is you. If someone else ever needs to pick this up, they should know who the go-to person is for questions or updates. This also makes it easier to keep SOPs up to date, because there is no confusion about who is responsible for maintaining them.
Write the steps as you would explain them to another EA
This is the core of the SOP. When you are working out how to create an SOP, write the steps in the order you actually do them, using the same language you would use if you were talking to another EA through the task.
Keep each step focused on one action. If a step feels long or overly complicated, it usually means it should be split into two steps or fleshed out a bit more.
Add watch-outs or quality checks
This is where you capture the things that tend to trip people up. It might be a reminder to double-check the attendee list, confirm time zones, or make sure the correct version of the document is used. These small checks will help you remember later, when you have to work through the procedure or when work is moving quickly, and you need the SOP to support a quick turnaround.
Define what “done” looks like
An SOP should make it clear when the task is finished. This might be meeting confirmed and calendar updated, travel booked and details shared, or a handover document sent. Knowing what done looks like will help prevent tasks from dragging on or being revisited unnecessarily.
Include a last reviewed date
Processes change, and SOPs need to keep up with what is happening in your role. If they are not kept up to date, they will be forgotten and become useless. A simple last reviewed date is often enough to prompt you to update the document when something changes. Even if you manage to update all of your SOPs once a year, you’ll be on to a winner.
What to leave out
You do not need long headers, formal language, or layers of approval unless your organization requires them. Avoid jargon and anything that makes the SOP harder to read during a busy moment. If the structure gets in the way of using it, it won’t work for you.
The SOPs that save EAs the most time
This is where SOPs start to earn their keep. The right SOPs support each other and reduce the amount of thinking you have to do across the week. As EAs, our work rarely sits in neat boxes, because inbox decisions affect the calendar, meetings create actions that feed into projects, and travel changes have a knock-on effect on expenses and follow-up work. Good SOPs reflect that reality and link together rather than living as isolated documents.
Below are categories that tend to save the most time in the EA role, along with examples that build on each other rather than sitting in isolation.
Executive support SOPs
These are often the first SOPs worth creating because they sit at the center of the role and touch almost everything else.
Inbox triage and prioritisation.
This SOP should spell out how you read the inbox and make decisions. What gets handled immediately? What gets flagged for your Executive? What gets scheduled? What can wait? Include clear rules for urgency, subject lines you always open, senders that bypass triage, and when something moves straight into the calendar or task list. This SOP should point directly to calendar rules and escalation guidance so decisions do not live in your head.
Calendar rules and meeting acceptance criteria.
This SOP should cover what gets accepted automatically, what needs context first, and what you decline or push back on. Document preferred meeting lengths, required agendas, buffer rules, time zone handling, and when prep time is blocked. This should link to meeting prep and follow-up SOPs so booking decisions reduce work later.
Meeting prep and follow-up.
This SOP should outline exactly what happens before and after a meeting. What materials are gathered? When pre-reads are sent. How actions are captured. Where notes live. When follow-ups are sent. This should connect directly to project or action tracking so outcomes do not disappear once the meeting ends.
Executive travel booking and change management.
This SOP should document booking order, preferred airlines or hotels, approval steps, and how changes are handled. Include what you do when plans change late, who gets notified, and how updates are shared. This should reference expense processing and handover notes, so nothing is missed when travel shifts.
Expense processing for your Executive.
This SOP should explain how receipts are submitted, how approvals are handled, what gets chased, and when submissions happen. Include real steps based on how your Executive actually works, not the ideal policy version. This SOP should also note cut-off dates and what happens when information is missing.
Communication and information flow SOPs
These SOPs help reduce interruptions and repeat explanations.
Handling internal requests.
This SOP should lay out a clear decision path. Who you respond to directly and within what timeframe. Which requests you acknowledge but park. Which ones you redirect to another team. Which ones you escalate immediately. Include examples of common requests, where they usually go, and what information you need before taking action. This SOP should also state how requests are tracked, whether that is a task list, project board, or inbox label, so nothing disappears.
Managing stakeholder emails.
This SOP should spell out how you assess tone and intent, when you reply yourself, when you draft for your Executive, and when you flag something for their direct response. Include guidance on subject lines, sign-off preferences, approval steps, and turnaround expectations for different stakeholders. This helps keep communication consistent even when volume is high.
Escalation rules.
This SOP should define what urgent actually means in your context. What qualifies as same-day. What can wait. Who needs to be informed at each level and how, whether that is Slack, email, or calendar time. It should also explain how escalations are logged or followed up so urgent issues move from inbox to action and do not resurface later.
Sharing updates or briefings.
This SOP should document what updates you send regularly, who receives them, and in what format. Note when updates are written versus verbal, how much detail is expected, and where source information lives. This works best when tied to existing meetings or reporting cycles, so updates feel routine rather than reactive.
Meetings and events SOPsMeetings and events create work before, during, and after. SOPs here should reflect that full lifecycle.
Agenda creation and pre-reads.
This SOP should document exactly when an agenda is required, for which types of meetings, and how far in advance it is created. It should state who contributes items, how agenda items are gathered, and what happens if nothing is submitted. Include where agendas live, when pre-reads are sent, and how you handle late additions. This SOP should link directly to meeting prep and action tracking so decisions, risks, and next steps are captured consistently.
Virtual meeting setup.
This SOP should set out which platform is used for which type of meeting, how links are created, and where they are stored. Include dial-in rules, recording decisions, permissions, and naming conventions. Add clear fallback steps for tech issues, who you contact if something fails, and how you communicate delays or changes to attendees, especially across time zones.
In-person event planning.
This SOP should break the work into phases. Initial requirements, budget and approvals, venue and supplier selection, timelines, and on-the-day logistics. It should spell out what you book, what your Executive approves, and what information is shared at each stage. Include checklists for the event day and clear links to supplier contacts, project tracking, and post-event actions.
Post-event actions and notes.
This SOP should explain how notes are taken, whether live or after the event, where they are stored, and how actions are assigned. Document who receives notes, how follow-ups are drafted, and when actions are checked back. This should link to project or task tracking so outcomes move forward rather than sitting in a document that no one revisits.
Projects and workflows SOPs
These SOPs help you maintain oversight without constantly chasing updates.
Project intake.
This SOP should clearly set out how work enters your world. Document where requests come in, such as email, Slack, meetings, or tools, and where they must be logged before you act on them. List the minimum information you need to proceed, for example, deadline, context, stakeholders, and decision owner. Spell out how you assess urgency, how you check capacity against existing commitments, and when you pause or push back. Include the exact language you use to clarify vague requests and how you flag clashes or trade-offs with your Executive.
Tracking actions and deadlines.
This SOP should describe the single source of truth you use for actions, whether that is a task manager, project board, or shared document. Document how actions are captured from meetings or emails, how deadlines are set or confirmed, and how owners are assigned. Include how often you review this list, how updates are recorded, and how overdue items are handled. Spell out how this feeds into status updates so you are not recreating the same information multiple times.
Handover between phases.
This SOP should define what must be completed before a project moves from one phase to the next. List required documents, approvals, decisions, and background context that need to be in place. Document where this information is stored, how it is shared, and who needs visibility before work progresses. Include a short checklist you can run through so nothing important is lost during transitions.
Closing out projects.
This SOP should set out a clear endpoint for a project. Document which files are finalised and where they are saved, how actions are closed, and who needs to be notified of completion. Include how you archive materials, update trackers, and capture any notes that might be useful if similar work comes up again. This prevents unfinished work or loose context from bleeding into future projects.
Cover, handover, and resilience SOPs
These SOPs are often overlooked, but they pay off quickly.
Annual leave handover
SOPs should set out exactly how you prepare to step away. Document when the handover starts, what needs to be reviewed in the inbox and calendar beforehand, and which projects need a written status update. Include a short summary template that covers current priorities, decisions in flight, risks, and what can wait. Link directly to your inbox rules, calendar rules, and project tracking SOPs so the person covering you can follow the same decision logic rather than guessing.
Short-notice cover
Sickness cover notes should be designed for speed. Document where access details live, which systems are essential, and which ones can be ignored for short periods. List shared folders, naming conventions, and live trackers. Include a simple table of key contacts, what they are responsible for, and how urgent issues should be escalated. This SOP should assume the reader has very little context and needs to act quickly.
Key contacts and dependencies
These SOPs should clearly map who is involved in each area of work. Document internal owners, deputies, and external contacts, along with what decisions they can make and when they need to be looped in. Include notes on dependencies between teams or projects, regular touchpoints, and any known sensitivities. This allows work to continue without pauses when you are unavailable.
Personal productivity SOPs
These SOPs support how you manage your own workload.
Daily admin routines
These should read like a simple run-through of how you actually work, start to finish. Document when you first check the inbox, what you look for straight away, and what gets left for later. Spell out how you scan the calendar for changes, what you check before the first meeting, and how you capture quick actions during the day. Include what you do at the end of the day, such as clearing flags, updating task lists, and noting anything that needs picking up tomorrow. This SOP should link directly to your inbox and calendar SOPs so decisions stay consistent.
Weekly planning SOPs
These SOPs should set out exactly when planning happens and what you look at every time. Document how you review the coming week in your Executive’s calendar, how you spot pressure points, and how you check deadlines across projects. Include where you pull status updates from, how you decide what needs attention this week, and how you communicate priorities back to your Executive. This SOP should show how weekly planning connects to project tracking and meeting prep, so nothing lives in isolation.
Monthly resets
Monthly reset SOPs should outline a repeatable check-in rather than a vague tidy-up. Document which folders, trackers, and lists you review, what gets archived, and what gets closed or carried forward. Include which SOPs you glance at to see if they still match how you are working, and how you note small changes when priorities or ways of working shift. This keeps your systems in step with the reality of the role.
File and folder management
SOPs should be very explicit. Document the folder structure you use, how files are named, where drafts versus final versions live, and how shared folders are organised. Include rules for saving emails or attachments, where meeting notes go, and how you retrieve information quickly when someone asks for it. When this SOP is clear, every other SOP becomes easier to use because information is always where you expect it to be.
So, where do you start?
You do not need all of these! Start with the SOPs that slow you down or interrupt your day most often. The ones you find yourself explaining again, fixing after the fact, or wishing you had written down sooner. Once those are in place, it becomes much easier to see how other SOPs link together and where it makes sense to add the next one.
How to write an SOP that actually gets used
As EAs, we need something we can glance at and follow while we are mid-task and already juggling five other things. When people ask how to create an SOP, this is the part that matters most. It has to actually be helpful.
When you sit down to write an SOP, use the active voice. Start each step with a clear action, using the words you would use if you were talking another EA through the task. Book the travel. Check the calendar. Send the follow-up. This approach keeps the steps easy to scan when your energy is low, which is exactly when knowing how to create an SOP properly pays off.
Keep it to one action per step. If a step starts turning into a paragraph, it usually means it needs breaking down. Short steps are easier to follow and easier to fix later if something changes.
Use plain language. Avoid internal jargon, long explanations, or policy-style wording. You are not writing this to impress anyone. You are writing it so you can get the job done without stopping to think too hard.
Screenshots can help, but only when they genuinely reduce thinking. A screenshot that shows exactly where to click can be useful. A screenshot that just looks nice will slow you down. If it does not make the task quicker, leave it out.
Tools like ChatGPT can help here, especially if you want a quick first draft. You can talk through the task as you do it and ask ChatGPT to turn that into clear steps, then edit it in your own words. Used this way, it can help you create an SOP without replacing your judgement or experience.
Above all, keep it short enough to use mid-task. A good test is this. Would this still make sense to you at 4.45pm on a Friday when your energy is low, and you just want to finish the last thing on your list? If the answer is no, it needs tightening.
Where SOPs should live for EAs
There is no perfect tool for SOPs, and we do not need to turn this into a software decision.
What matters is access. Your SOPs should be easy to find, available while you are doing the task, and not buried in a folder you forget exists.
For some EAs, that looks like a pinned document you can open in one click. For others, it might be a shared folder with clearly named files. Some EAs keep SOP notes directly inside their task manager. A simple Word or Google Doc works just fine if it is easy to open and easy to update. If you want to try a platform for creating SOPs, Moxo is a good option.
Start small.
Pick one standard operating procedure from the list. Choose something you already do regularly. Write it as you are doing the task, in real time, using your own words. Use it the next time the task comes up. Then improve it when you notice what is missing.
As EAs, we know that real progress comes from things we actually use. A rough SOP you use beats a perfect one you do not, and that mindset matters more than mastering how to create an SOP on day one.