A fast reply is not necessarily a decision, and a timestamp is not useful until every party knows which event, calendar, time zone and authority it represents.
A site team in Toronto sends a glazing change late Friday afternoon. The supplier's drawing team in China sees it Saturday, the engineer in London is on a daylight-saving offset and production is waiting for a release. Sales replies ‘received’ within minutes, so the issue is reported as answered. In reality, no authorised technical decision exists and the manufacturing cut-off passes. A robust response rule separates acknowledgement, technical assessment and authorised disposition; assigns IANA time zones and working calendars to people and events; and makes the programme consequence visible before silence or false speed becomes an unrecorded approval.
No universal target: All response, assessment, decision, update and escalation times in this article are blank project fields. The contract and authorised project team must approve values, coverage calendars, cut-offs and consequences.
1. Publish a location, calendar and authority map for every project role
List each role and named primary/backup: buyer, architect, façade/structural/glass reviewers, contractor/site team, factory project engineer, production planner, procurement, quality, logistics, commercial/legal and document control. Record organisation, current work location, IANA time-zone identifier, approved working calendar, normal coverage window, language, channel and delegation limit. A telephone country code or UTC offset alone does not survive travel or daylight-saving changes.
Use IANA zone names such as an approved region/city identifier in systems and retain UTC timestamps for event ordering. ISO 8601 and RFC 3339 support unambiguous machine-readable date/time representation, but they do not define business hours, holidays or contractual days. Display local time for humans and record the time-zone database/version or service source where reproducibility matters.
Separate presence from authority. A local coordinator may acknowledge and gather evidence without approving a glass change; a factory engineer may assess manufacturability without accepting cost or programme; a salesperson may communicate an authorised decision but not create one. Publish scopes, limits and absence/delegation rules.
| Role/person | IANA zone and calendar | Coverage/channel | Decision scope/limit | Backup/delegation |
|---|---|---|---|---|
| Site coordinator | [zone/calendar] | [hours/channel] | Receive/contain only | [named] |
| Technical designer | [zone/calendar] | [hours/channel] | [defined technical scope] | [delegate] |
| Factory engineering | [zone/calendar] | [hours/channel] | Manufacturability/evidence scope | [delegate] |
| Commercial authority | [zone/calendar] | [hours/channel] | Cost/contract scope | [delegate] |
| Production/logistics | [zone/calendar] | [hours/channel] | Cut-off/status evidence | [delegate] |
| Document control | [zone/calendar] | [hours/channel] | Issue/status control | [delegate] |
2. Define urgency from consequence and decision need
Build urgency classes from observable project consequence: immediate safety/security/weather exposure; workface stopped or imminent irreversible work; production or shipping hold; approval needed before a controlled cut-off; information request with no current impact; and routine coordination. Define evidence, authorised classifier and reclassification triggers. Loud messaging or seniority is not severity.
For each class, approve distinct targets for acknowledgement, triage, substantive response, decision, update cadence and escalation. Acknowledgement proves receipt and case/query ownership. A substantive response may clarify facts or present options. A decision requires the named authority and stated scope. Resolution or incorporation requires updated controlled documents and downstream verification. Report these clocks separately.
Use provisional urgency when facts are incomplete. Record what is at risk, the next irreversible event, actual cut-off source, affected marks/documents and safe hold. Reclassify when conditions or evidence change, retaining author, reason and timestamp. Never downgrade to protect performance statistics.
| Class trigger | Required evidence | Acknowledgement/decision fields | Escalation/reclassify trigger |
|---|---|---|---|
| Immediate safety/exposure | Local competent assessment/state | [project-approved fields] | Containment fails/state changes |
| Workface/production blocked | Held activity and affected scope | [fields] | Next cut-off approaches |
| Decision before cut-off | Authoritative cut-off/programme impact | [fields] | Decision owner unavailable |
| Technical clarification | Question/source and needed-by logic | [fields] | Impact emerges |
| Routine coordination | Action and programme link | [fields] | Dependency changes |
3. Make clocks, cut-offs, holidays and DST machine-auditable
For every response rule record: start event, stop event, elapsed or working time, authoritative IANA zone, calendar/version, coverage days/hours, holiday and make-up-workday treatment, daylight-saving rule, pause/resume states, cut-off owner/source and timestamp precision. Avoid ‘EOD Friday’, ‘tomorrow morning’ or ‘within two working days’ without zone and calendar.
Daylight-saving changes can create repeated or missing local times and alter overlaps between regions. Store the event in UTC plus source local time/zone, and schedule recurring meetings/rules by zone rather than fixed offset where local-clock intent matters. Reconfirm around transitions and participant travel. China currently uses one national civil time without seasonal DST, but other team locations may not; the database, not memory, controls conversion.
A cut-off is a controlled downstream event—drawing freeze, material purchase, machine release, inspection booking, carrier documentation or port gate—not a pressure tactic. Record who owns it, source system/revision, last responsible decision time in all relevant zones and what slips or becomes irreversible after it. If a holiday calendar changes, recalculate linked clocks and programme impact visibly.
| Field | Approved entry | Evidence source | Audit question |
|---|---|---|---|
| Start/stop events | [state transitions] | Workflow/system log | Can both timestamps be reproduced? |
| Zone/calendar | [IANA zone + version/calendar] | Authoritative project calendar | DST/holiday applied correctly? |
| Coverage/working time | [approved window] | Team rule/contract | Excluded time visible? |
| Pause/resume | [allowed states/evidence] | Query/action log | Was pause justified? |
| Cut-off | [event/time/owner] | Production/logistics source | Is it current and consequential? |
| Programme effect | [activity/float/hold] | Approved schedule | Was downstream impact updated? |
4. Use structured handoffs instead of forwarding message chains
A handoff package contains query/issue ID; urgency and deadline basis; physical/document scope; governing drawing/specification revisions; verified facts and evidence; assumptions/unknowns; options and constraints; local containment/hold; decisions already made with authority; open decision and required approver; programme/cost implications; customer commitment; next update; and accepting owner. The outgoing owner remains responsible until acceptance is logged.
Design follow-the-sun work carefully. Regional teams may collect evidence, translate, prepare comparisons or run checks within their authority; they must not continue an engineering or commercial decision across shifts without sufficient competence and explicit scope. Separate source wording, translation and interpretation, and maintain the controlling-language/terminology route.
At shift start, challenge stale facts: site condition, production state, document revision, material availability and cut-offs. At shift end, record what changed and what must not proceed. Duplicate discussions should link to one authoritative query ID; new conditions require a new or child issue rather than overwriting history.
| Handoff element | Outgoing evidence | Incoming check | Failure action |
|---|---|---|---|
| Identity/scope | Query + marks/docs | Physical/document match | Reject ambiguity |
| Urgency/clock | Class, deadline and calendar | Recalculate locally | Escalate mismatch |
| Facts/unknowns | Evidence-linked summary | Source access and freshness | Keep unknown open |
| Authority | Decisions and limits | Approver/delegate valid | No implied approval |
| Programme/cut-off | Current downstream record | Owner confirms status | Refresh impact |
| Ownership | Named next actions/update | Explicit acceptance | Outgoing owner retains |
5. Connect escalation to programme control and document incorporation
Escalate on consequence, clock-at-risk, missing authority, contradictory instructions, unowned query, unsafe/irreversible work, repeated handoff failure or changed cut-off. Name functional and executive paths without bypassing technical competence. Escalation requests an authorised decision or resource; it does not convert silence into consent unless a legally reviewed contract explicitly says so.
For each late/open decision, record affected schedule activity, predecessor/successor, available float only from the authorised programme, hold point, procurement/production/logistics commitment, cost/change route and mitigation owner. Distinguish forecast impact from approved extension or entitlement. A fast answer that is not incorporated into drawings, BOM, inspection or shipping instructions can still produce programme failure.
Close the communication item only when the decision source, authority, scope and effective date are recorded; objections/dependencies resolved; controlled documents and translations updated; recipients acknowledge the issued revision; and downstream production/site/logistics state is reconciled. Audit metrics from raw state transitions, showing acknowledgements, substantive responses and decisions separately.
| Gate | Required evidence | Authority | Close blocker |
|---|---|---|---|
| Escalation trigger | Consequence/clock/authority evidence | Project procedure | Vague urgency |
| Programme impact | Activity, cut-off, hold and forecast | Planner/project manager | Unapproved assumption |
| Technical decision | Source, scope, approver and limits | Named professional | Acknowledgement only |
| Commercial disposition | Cost/time/contract record | Named commercial authority | Technical answer only |
| Document incorporation | Revised controlled outputs | Document control | Chat/email remains sole source |
| Downstream reconciliation | Factory/site/logistics acknowledgement | Functional owners | Different revisions active |
FAQ
What is a reasonable universal response time?
There is none in this article. Approve separate acknowledgement, assessment, decision and update targets from project consequences, coverage, authority and programme cut-offs.
Does ‘received’ mean the query is answered?
No. It is an acknowledgement. A decision requires the authorised person, evidence, scope and controlled incorporation.
Should every timestamp use UTC?
Store UTC for ordering plus original local time and IANA zone for context. Business clocks still require an approved regional calendar and DST/holiday rules.
How should daylight-saving changes be handled?
Use current IANA zone rules, not a remembered fixed offset; retest recurring events and overlap windows around transitions.
Can the next regional office decide while the original team sleeps?
Only within documented competence and delegated authority using a complete accepted handoff. Follow-the-sun availability does not create approval power.
Does missing a response target automatically change the programme?
No. Record the actual dependency, cut-off, hold and authorised schedule analysis. A target breach and contractual time entitlement are different questions.
When is a technical query closed?
After the authorised disposition is incorporated into current documents and acknowledged by affected downstream owners—not when the email thread ends.
Continue the project review
Connect this guide with the proposed window and door systems, then review how Cavorlen approaches manufacturing and quality control. When your schedule is ready, send it through the project review form.
Official sources used
IANA — Time Zone Database ↗ISO — ISO 8601-1 date and time representation ↗IETF — RFC 3339 Date and Time on the Internet ↗ISO — ISO 21502 project management guidance ↗ISO — ISO 10007 configuration management guidance ↗ISO — ISO 10002 complaints-handling guidance ↗Related buyer guides
This article is not an SLA, emergency-response promise, project schedule, contract interpretation, deemed-approval rule, variation procedure or statement of Cavorlen staffing/availability. It supplies no response time, business day, coverage hour, cut-off, buffer, escalation period or commercial remedy. It does not authorise technical or commercial decisions. Signed project procedures, calendars and named delegates control the actual workflow.