In this guide
- Start with an observable result
- Trace changes in information, not a guessed organization chart
- Put evidence beside each arrow
- Distinguish dependencies from delays
- Keep personal administration on a separate line
- Test the map with one interruption
- Leave with a bounded service brief
- Read next
- Sources and limits
A city service becomes understandable when you can follow what changes between the first question and the usable result. Department names help locate responsibility, but they do not explain every transition. A resident may speak to one counter, submit information through another channel and wait for a different function to make a decision. For an employee, the critical work may be checking whether the next function has enough information to act.
Phoenix’s public department directory and myPHX311 offer different views of the same city: organizational responsibilities and service categories. Planning and Development separately lists project tools, appointments, reviews and inspections. Those public distinctions are enough to show why a single “contact the city” box is too coarse. They do not reveal an internal workflow or authorize anyone to skip a required step.
Start with an observable result
Write the result in a sentence that another person could recognize. “The requester can identify the next official step” is narrower than “the issue is handled.” “The responsible office has accepted a complete request” is different from “the requested work has been completed.” A clear end condition prevents a sent email, an appointment or a reference number from being mistaken for the final outcome.
For a municipal employee learning an unfamiliar service, this is a useful orientation exercise. Ask what a successful handoff makes possible for the next role. The answer might be scheduling, technical review, a records search or a decision. It need not be a final approval. This makes support work visible without overstating the employee’s authority.
Trace changes in information, not a guessed organization chart
Use five columns: question received, information checked, responsibility accepted, work or decision recorded, result explained. A real service may repeat a column or use a different order. These are analytical lenses, not Phoenix procedure. Draw an arrow only when you know what allows the next stage to begin; label an unknown arrow as a question.
A fictional example helps. An employee at a public information counter receives a project question. The counter can clarify which published project resource is relevant, but it cannot promise that a review will approve the project. A useful trace records that the reader received the correct official destination and knows what information to prepare. It leaves the technical decision with the authorized function. This example is invented and does not describe a Phoenix case or employee.
Put evidence beside each arrow
An arrow labeled “sent” needs a destination and a date in the authorized record. An arrow labeled “accepted” needs evidence that the receiving function recognized the work. An arrow labeled “finished” needs the appropriate completion condition. The evidence could be a system state, an official communication or an approved record; this publication cannot decide which evidence controls a real case.
Missing evidence should remain visible. If the sender can show that information was transmitted but cannot tell whether the receiver accepted it, draw the chain only as far as transmission. Guessing the rest creates an attractive but misleading map. Conversely, do not demand a new document for every transition when the authorized system already records it.
Distinguish dependencies from delays
Some work cannot proceed until something else exists: a complete submission, a scheduled visit, an approved resource or an authorized decision. Other work is ready but waiting for capacity. These situations can look identical from outside. They call for different questions. “What must exist before this can start?” investigates a dependency. “When is ready work reviewed?” investigates a queue.
Neither question gives a reader permission to change priority or a worker permission to bypass review. The value of the map is explanatory. It helps a person direct a specific question to the responsible office instead of repeatedly requesting a vague status update from everyone along the chain.
Keep personal administration on a separate line
A City employee may use eCHRIS for an employee-administration task while also using a department’s service systems for public work. A staff member’s employment record and a resident’s service request are different objects. Do not attach payroll, benefits or other personal employment information to a service map just because both involve the same worker.
For the same reason, a public service portal is not evidence that someone can access employee functions. Use the City’s official employee and service resources for their stated audiences. This independent publication neither connects to those accounts nor acts as an intermediary.
Test the map with one interruption
Suppose one expected response does not arrive. Can the map identify the last evidenced state, the responsible function and the next authorized question? If all three are missing, add clarity before adding more boxes. If they are present, the map is useful even when the final date is unknown.
A second test is substitution: could an authorized colleague understand the current state without relying on your memory? Avoid building a second unofficial database. Use a minimal conceptual map and point to the approved source of record. Keep case details in the systems where they belong.
Leave with a bounded service brief
The output is a short explanation: “This service begins with this kind of request, requires these known inputs, moves through these evidenced states and ends when this result is recorded.” Follow it with the unresolved questions. That is a much stronger starting point for learning city work than a list of phone numbers or a diagram that pretends to expose private operations.
Read the intake guide if the first step is unclear. Read the handoff guide if the sender and receiver appear to disagree. Read the closure guide when a system label and the reader’s understanding of completion diverge.
Read next
- A Complete Service Request Is More Than a Filled Form
- Read the PHX ACT Announcement as an Employee Reporting Map
- Close the Service Loop with Evidence and a Clear Next Step
Sources and limits
Public sources checked October 5, 2026. Editorial examples are hypothetical; official instructions and case-specific decisions remain with the responsible City service.
- City of Phoenix: City Departments
Public department responsibilities and official destinations; no private operational workflow inspected.
- City of Phoenix: myPHX311
Public service categories and issue-reporting entry points. Not an emergency dispatch or employee HR interface.
- City of Phoenix: Planning and Development tools
Separate public functions for appointments, plan review, inspections and project information. Not a case-specific approval.