Operational Request
Use this page for BAU and operational work that supports day-to-day delivery but is not primarily a product feature.
Typical examples include access requests, environment or configuration changes, support needs, third-party setup, process adjustments, and operational fixes that need tracked follow-through.
What to include
State the operational need
- Describe what is needed in plain language.
- Explain why it is needed now.
- Be clear about whether this is a one-off task, recurring need, or urgent blocker.
Provide the affected context
- Which system, tool, environment, clinic, team, or workflow is affected?
- Who needs the change or support?
- What date, event, or operational deadline matters?
Include dependencies and permissions
- Call out vendors, third-party tools, and access dependencies.
- Link any approvals, credentials, or existing setup information.
- Say whether another team must act before engineering can proceed.
Define success
- What outcome would mean this request is complete?
- What should be verified before the ticket can be closed?
Suggested operational request format
Summary
Short description of the operational request.
Need
What needs to happen and why.
Context
Affected teams, tools, environments, deadlines, or locations.
Dependencies
Access, approvals, vendors, data, or cross-team inputs.
Success criteria
What done looks like.
Supporting material
Links, screenshots, emails, logs, or previous requests.Good operational requests avoid
- Asking for action without explaining the business or operational context
- Leaving out the deadline or urgency when timing matters
- Omitting access, vendor, or environment details that determine feasibility
Related guidance: Request Readiness