Desktop Procedures Examples: How to Write Them Right

A desktop procedure is step-by-step documentation for completing a specific task at a workstation. It tells the person doing the work exactly what to click, what to type, and what result to expect before moving on. That's the difference between a desktop procedure and a broader standard operating procedure, which covers an end-to-end process across multiple people and systems. A desktop procedure lives at the task level — it belongs on a single screen or in a single application window.

Write instructions that let anyone on your team complete the task correctly without asking questions. If they have to ask, you haven't written the procedure yet.

What Is a Desktop Procedure?

A desktop procedure is a written set of instructions for a single task performed at a computer workstation. It is narrower than a standard operating procedure. An SOP describes a full process — for example, how a sales team moves a lead from first contact through close. A desktop procedure describes one step inside that process — for example, how to enter a new customer record into your CRM, including which fields to fill, where to find the save button, and what confirmation message to look for.

The difference comes down to scope and audience. An SOP is read by anyone involved in a workflow. A desktop procedure is read by the person sitting at the keyboard doing the task right now. That means it must be specific enough to follow without guessing, but not so wide that it buries the actual click-path in unrelated steps.

Here is when each type makes sense:

• Use an SOP when you need to document how multiple people coordinate across systems, hand off work, or make decisions in sequence.
• Use a desktop procedure when you need someone to complete one task correctly on their own — data entry, report generation, file upload, system configuration — and you want them to finish it without calling a colleague.

Clear, specific instructions catch mistakes before they reach production or a client. They also support training; a new hire can follow the steps without needing a live person watching over their shoulder. And they support audit readiness. When a regulator or auditor asks how a control is performed, you need documented evidence that the work is done consistently, not just that a person remembers doing it.

• Scope: Standard Operating Procedure: End-to-end process across people and systems · Desktop Procedure: Single task at one workstation
• Audience: Standard Operating Procedure: Anyone involved in the workflow · Desktop Procedure: The person performing the task
• Detail level: Standard Operating Procedure: Decision points, handoffs, ownership · Desktop Procedure: Click-paths, field names, exact values
• Example: Standard Operating Procedure: "How we onboard a new vendor" · Desktop Procedure: "How to add a vendor in the procurement system"
• Maintenance trigger: Standard Operating Procedure: Process change or role change · Desktop Procedure: System update or task change
• Best use: Standard Operating Procedure: Cross-functional coordination · Desktop Procedure: Task-level consistency and error reduction

A desktop procedure is the right choice when the task is repeatable, specific, and performed by multiple people who all need the same result. If the answer depends on a judgment call made by a manager, an SOP is more appropriate. When the answer is the same each time — entering fields, clicking a button, verifying a message — a desktop procedure saves time for everyone.

What to Include in a Desktop Procedure Template

Every desktop procedure needs the same core fields. Without them, the document becomes a note rather than an instruction set, and the next person reading it will have to guess what you meant. Here are the eight fields every desktop procedure must have, and what each one does.

Title. A clear name that identifies the task and the system. "Enter a new purchase order in the ERP" works better than "PO entry." The title should stand alone on a search results page so anyone can find it without context.

Purpose. One sentence explaining why this task exists and what business outcome it supports. This field prevents the procedure from drifting into unnecessary detail. If the purpose is "to create a valid vendor payment record," the writer knows to include only the steps that produce that record.

Scope. What this procedure covers and what it does not cover. Scope prevents the reader from wondering whether they should also update the general ledger or notify the procurement team. It sets boundaries around the task.

Steps. The numbered, sequential instructions. Each step is one action: open the screen, select a value from a dropdown, type a number into a field, click a button. Steps are written in imperative form — "Click," "Select," "Type" — not descriptive prose about why something happens.

Fields. A table of the data fields that must be entered, with the exact format required for each. Field names come from the system itself — the label as it appears on screen — not a summary description. Format details include whether a date must be MM/DD/YYYY, whether a currency code is required, and which values are mandatory versus optional.

Exceptions. Decision rules for situations that deviate from the normal path. What happens if the vendor is already in the system? What happens if the purchase order exceeds a threshold? A desktop procedure without exceptions becomes a checklist that breaks on the second try.

Owner. The role responsible for maintaining the procedure, not the person performing the task. This field makes review schedules actionable. When someone leaves the company, the owner field tells the next person what to update.

Review date. The last date the procedure was verified against the current system state. This field is what turns a static document into a maintained process. Without it, procedures drift until they no longer match the software.

A well-written step looks like this: "In the 'Create Vendor' screen, type 'ACME Corp' into the Name field, select 'United States' from the Country dropdown, then click 'Save.'" A vague one looks like this: "Enter the vendor information." The difference between them is the same difference between a recipe that says "add the flour" and one that says "sift two cups of all-purpose flour into a bowl."

When writing steps, aim for specificity that removes ambiguity. If a field has a dropdown, name the exact option. If a button has a label that could be confused with another button, include the full label in quotes. If a confirmation message appears on screen, quote it. The measure of a good step is simple: can someone who has never done this task complete it by reading only these instructions?

How to Create and Maintain Desktop Procedures

Writing a desktop procedure starts with observation and ends with validation. Here is how to build one from scratch and keep it useful over time.

1. Identify the task. Pick a repeatable workstation task that causes errors or requires repeated explanation. Common candidates are data entry in a CRM, report generation in an analytics platform, file uploads in a document management system, or configuration changes in a tool. Choose the task that costs the most time when done incorrectly.

1. Observe the work. Watch someone perform the task multiple times. Take notes on every click, every field filled, every decision point, every error that occurs. Do not write the procedure from memory. Write it from what you see. The person doing the work may skip steps they consider obvious; those skipped steps are exactly the ones new hires will miss.

1. Write the steps. Draft the procedure using the eight-field template above. Write each step in imperative form, one action per line. Use the exact system labels — field names, button labels, dropdown options — as they appear on screen. Do not paraphrase. If the system says "Submit for Approval," do not write "send it through."

1. Test with a new person. Hand the draft to someone who has never performed the task. Ask them to follow it without asking questions. Note where they pause, where they guess, where they deviate. Revise based on their experience, not your intention. A procedure is complete only when it works for someone reading it cold.

1. Publish and link. Place the final procedure in the team's documentation system — a shared drive, a wiki, or a process library. Link it from the relevant SOP so readers can find it when they reach the relevant section. Make it searchable by title and keywords.

Maintenance follows a regular schedule. Review procedures after any system update, any interface change, or any process change that affects the task.

Link each procedure to the specific control or risk it addresses. If a procedure documents how purchase orders are entered, note which audit control it satisfies. If it documents how customer data is uploaded, note which data-governance requirement it supports. This linkage turns a collection of instructions into an auditable compliance record. The maintenance schedule that works for a small team is simple: assign one person per procedure as owner, set a calendar reminder for quarterly review, and add any system-change notification to their inbox so they know when to verify.

If you're a business owner and the team keeps producing inconsistent work because no one wrote down what they do at their workstation, that's the kind of leadership gap Confluunt Advisors can fill.

A Worked Example: ERP Transaction Entry

This complete desktop procedure for entering a vendor payment transaction in an ERP system shows the exact navigation path, field names, values, and decision rules that a good procedure contains. Use it as a template for writing your own.

Title: Enter a vendor payment in the ERP Purpose: Create a valid vendor payment record that posts to the general ledger on the correct date. Scope: Covers entering a single vendor payment from the payments module. Does not cover approval routing, bank file creation, or payment release. Owner: Accounts Payable Supervisor Review date: [To be updated after next ERP release]

Navigation path: Login → Payments Module → New Payment → Vendor Selection → Enter Details → Save

Field-by-field entry:

• Payment Date: Required value / format: System default · Notes: Must match invoice date or within the agreed period
• Vendor Code: Required value / format: Exact code from vendor master file · Notes: Do not use vendor name; look up by code
• Invoice Number: Required value / format: Alphanumeric as shown on invoice · Notes: Verify against physical invoice copy
• Amount: Required value / format: Currency with two decimal places · Notes: No commas; no currency symbol
• GL Account: Required value / format: Select from dropdown; default varies by system · Notes: Only change if instructed by supervisor
• Department: Required value / format: Select from dropdown · Notes: Matches purchase order department
• Cost Center: Required value / format: Select from dropdown · Notes: Matches PO cost center
• Memo: Required value / format: Free text, length varies by system · Notes: Include invoice reference number
• Attach Reference: Required value / format: Upload PDF of signed invoice · Notes: Required for larger amounts

Steps:

1. Open the application login screen. Enter your credentials and click Sign In.
2. Click the Payments Module icon in the navigation bar.
3. Click the button to create a new payment in the Payments Module toolbar.
4. In the vendor search field, type the first three letters of the vendor name and select the matching entry from the dropdown.
5. Click OK to return to the payment entry screen.
6. In the Payment Date field, enter the date in the format required by your system or accept the system default.
7. In the Invoice Number field, type the exact alphanumeric code from the physical invoice.
8. In the Amount field, type the dollar amount with two decimal places. Do not include a dollar sign or commas.
9. Click the GL Account dropdown. Select the account listed on the purchase order. If none is listed, select the appropriate account for the purchase.
10. Click the Department dropdown and select the department matching the purchase order.
11. Click the Cost Center dropdown and select the cost center matching the purchase order.
12. Type a memo in the Memo field referencing the invoice number and vendor (for example, "PO-4421 ACME Corp").
13. If the payment amount is significant, click the Attach Reference button, locate the signed PDF invoice, and confirm the upload completes before proceeding.
14. Click Save. Verify the confirmation message. Record the generated payment reference number in the AP tracker.

Exception handling:

• If the vendor code is not found in the system, stop and contact the appropriate administrator. Do not create a new vendor record without authorization.
• If the invoice amount differs from the purchase order by a noticeable margin, flag the transaction for supervisor review before saving.
• If the GL account dropdown is empty, check whether the cost center has been mapped in the system. If not, contact the finance administrator before proceeding.

Before publishing, validate that field names and screen paths match your current interface. After a major release, the owner must verify that the navigation path and field labels have not changed, then update the review date accordingly.

Common Mistakes to Avoid When Writing Procedures

Most desktop procedures fail because they are written as notes rather than instructions. The result is a document that looks complete but cannot be followed by someone who has never done the task. Here are five mistakes that make procedures fail, and how to avoid each one.

1. Vague steps. A step like "enter the vendor details" tells the reader nothing about what to enter or where to enter it. The fix is to name every action: click which button, type which value into which field, select which option from which dropdown. Write the step so that the person reading it does not need to guess.

2. Missing exceptions. A procedure that only describes the happy path breaks the moment a real situation deviates. Every desktop procedure needs at least two exception rules: what to do if a required value is missing, and what to do if a system error occurs. Without them, the procedure is incomplete by design.

3. No owner. An undocumented maintenance responsibility means the procedure becomes stale the first time the software updates. Assign an owner role, set a review date, and link the procedure to the control it supports. This turns a static document into a maintained process artifact.

4. No review date. A procedure without a last-verified date gives no signal to the reader about whether it matches the current system state. Every published procedure should carry a review date and a rule for when the next verification is due — typically after any interface change or quarterly on a fixed schedule.

5. Writing procedures nobody follows. Procedures are often written in isolation from the people who perform the task. A procedure that skips steps the writer considers obvious will fail for anyone new. The fix is the same as the creation process described earlier: test with someone who has never done the task, revise based on their experience, and publish only when the instructions work without questions.

The difference between a procedure that gets used and one that gets filed away is specificity. A specific instruction is a click-path with exact labels. A vague instruction is a reminder of what needs to happen. Write for the person who will follow it, not the person writing it. That discipline alone eliminates most of the errors that make procedures useless.

If you need help building the systems your team actually uses, start with a free strategic review at contact.

Frequently asked questions