In this guide
- State the next action narrowly
- Separate four kinds of constraint
- Work through a fictional review
- Do not substitute your own approval
- Define the evidence that would change the state
- Keep readiness separate from priority
- Use the Service Thread Builder as a rehearsal
- Produce a dependency note someone can use
- Read next
- Sources and limits
A service can appear stalled for several different reasons. The next role may be waiting for information, a decision, a scheduled event or capacity. Those conditions are not interchangeable. Adding urgency to a vague request will not necessarily supply the missing input, and completing an input will not necessarily create an immediate appointment.
Phoenix’s Planning and Development resources separate functions such as project information, reviews, inspections and appointments. The department directory also separates responsibilities across the city. These public structures support a simple analytical habit: identify what must be true before the next step can occur. They do not expose the City’s internal sequence or authorize a shortcut.
State the next action narrowly
Begin with an action that belongs to a known function. “Review the submitted material” is narrower than “finish the project.” “Confirm which appointment category applies” is narrower than “solve the issue.” The narrower action makes dependencies visible and prevents a conversation about readiness from becoming a demand for a final outcome.
A worker learning a service can ask the same question during orientation: what input allows this role to start? The answer is often more informative than a broad list of duties. It shows where the role depends on another function and where its own output becomes someone else’s input.
Separate four kinds of constraint
Information constraints concern what is known or documented. Authorization constraints concern who may decide or act. Scheduling constraints concern when a required event can occur. Capacity constraints concern ready work waiting for available resources. These are editorial categories for discussion, not official Phoenix queue codes.
More than one constraint can exist at the same time. A request might need a corrected reference and a later appointment. Solving the first does not remove the second. A useful map therefore marks each condition separately rather than collapsing them into a single red “blocked” box.
Work through a fictional review
Consider an invented municipal project conversation. A resident wants to know when a review will finish. The service contact can see that a clarification has been requested, but the reader does not know whether the clarification has been accepted. The next useful question is about that state, not a guessed completion date.
Suppose the clarification is then accepted. The work may become ready for review while still waiting in a queue. The explanation should change accordingly. Continuing to say “waiting on information” after the information has been accepted is as misleading as promising immediate completion when it first arrives.
This example is not a report of a Phoenix case, a service-level standard or an account inspection. It illustrates how a question changes when evidence changes. Real case status and required material must come from the responsible City process.
Do not substitute your own approval
An input can look complete to an outsider while still requiring review by an authorized person. A checklist is useful for preparation, but it cannot grant permission. The same is true of an employee who is familiar with a process but does not hold the relevant delegated authority.
Where approval is the dependency, name the authorized function without publishing personal schedules or private staff information. If the responsible role is unknown, mark it unknown and use the official route to clarify. A guessed approver can send the work in the wrong direction and create a false expectation.
Define the evidence that would change the state
For every unresolved dependency, ask what observation would establish that it has been satisfied. A received message, accepted submission, confirmed event or recorded decision may be relevant, depending on the process. Do not create an extra evidence requirement where the authorized system already supplies one.
This is also how to avoid endless follow-up. A useful update condition might be a recorded state change or an officially agreed review point. “Ask again every hour” is usually a frequency, not a reason. The department’s actual contact instructions and any case-specific direction remain controlling.
Keep readiness separate from priority
Ready work can still be subject to prioritization. An urgent condition may have a different official route. Neither fact permits a reader to relabel an ordinary request or a worker to override priorities. This guide is about describing the state accurately, not moving an item ahead of other work.
If a situation concerns immediate danger, follow the relevant emergency instructions rather than using this publication or a planning worksheet. No tool here reports an incident, dispatches a service or reaches a City employee.
Use the Service Thread Builder as a rehearsal
The local worksheet on the homepage asks about the work object, owner, dependency, acknowledgment and next update condition. Its output identifies missing questions from the choices you make. It does not evaluate a live request or calculate a service deadline, and it accepts no names, case records or credentials.
Try an invented scenario with an unknown owner, then change only that field. Notice that identifying an owner does not automatically resolve the dependency. Try a second scenario with every condition evidenced. The output should still remind you that the official process controls real action.
Produce a dependency note someone can use
A strong note says: “The next action is X. It depends on Y. Evidence for Y is known, unknown or not applicable. The responsible function is Z, or needs confirmation.” The note can be short because it distinguishes the questions rather than narrating every event.
Use the queue-age guide only after deciding what counts as waiting in the queue. Use the handoff guide when the missing condition is acceptance. Use the appointment guide when an event must be prepared. Together they turn a vague delay story into a bounded explanation of what is known and what still needs an official answer.
Read next
- Make a Development Center Appointment Ready to Use
- Read the PHX ACT Announcement as an Employee Reporting Map
- Two Equal Queues Can Contain Very Different Waits
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: Planning and Development tools
Separate public functions for appointments, plan review, inspections and project information. Not a case-specific approval.
- City of Phoenix: City Departments
Public department responsibilities and official destinations; no private operational workflow inspected.