The request lifecycle

A request goes through up to four statuses from filing to closure. The status tells residents and admins where things stand. Stuck requests at any stage are how community trust erodes - this article is about keeping things moving.

The four statuses

Status	What it means	Resident sees?
New	Just filed, no one has looked at it yet	Yes
Acknowledged	A board member or admin has seen it and is tracking it (often used for Neighborhood Requests being recognized)	Yes
Under Investigation	Someone is actively working on it	Yes
Closed	The request is done; no more action expected	Yes

Status moves forward generally - but you can move back to Under Investigation from Closed if something reopens.

New

The default state when a request is created.

What it signals: nobody on the admin side has looked at it. The resident is waiting.

How long it should stay this way: 24 hours, max. If a request is New longer than that, residents start to feel ignored.

A practical rule: at least one board member should check the request queue every weekday. The first action - even just acknowledging it - matters more than the eventual resolution.

The board can file one too. Most requests come from a resident, but not all of them do. Requests in the admin sidebar, then New Ticket: say whether you are filing on behalf of A resident or The Board, pick a type or tap Let Herald decide and let the description sort it out, attach a photo if you have one, and tick Check this against the covenants if you want it screened like any other intake. That is how the call you took on the phone, the thing somebody raised at a meeting, or the fence you noticed yourself ends up on the same board as everything else instead of in a text thread.

Acknowledged

Someone has seen the request and confirmed it’s been received. Often used for Neighborhood Requests where the board is recognizing a community-wide concern but not yet investigating.

Typical use:

• A neighbor reports a broken streetlight → Acknowledged (“we see it, we’re contacting the city”)
• A resident files a general suggestion → Acknowledged (“we got it, will discuss at the next meeting”)

It tells the resident “you’ve been heard” without committing to immediate action.

Under Investigation

Someone on the board is actively handling the request.

Use cases:

• A complaint where you’re verifying the violation (driving by, checking photos)
• An ARC request you’re reviewing
• A maintenance issue you’ve contacted a vendor about
• A general question you’re researching before responding

The status implies action is happening - make sure it actually is. If a request sits in Under Investigation for two weeks with no comments, the resident assumes it’s been forgotten.

A good practice: add a comment when moving to this status, even if it’s just “Looking into this - checking with the architectural committee.”

Closed

The request is done. No further action expected.

For each request type, “closed” means something specific:

Type	What “Closed” means
Complaint	Either the violation was confirmed and a notice was issued, or it was dismissed with a reason
ARC	Approved (with any conditions) or denied (with explanation)
Neighborhood Request	The work is complete or the underlying issue is addressed
General	The board has provided an answer or taken the requested action

Status transitions

New → Acknowledged or Under Investigation

When an admin opens the request and starts tracking or working on it.

Acknowledged → Under Investigation

When the board moves from “we see it” to “we’re actively working on it.”

Under Investigation → Closed

The decision is made and communicated.

Backwards: Closed → Under Investigation

When a resident replies to a closed request and the board needs to take new action. Common cases:

• Resident pushes back on an ARC denial with new information
• Maintenance work was supposedly resolved but the issue persists
• New evidence on a dismissed complaint

The status can move back. There’s no penalty for re-opening; sometimes it’s the right thing.

Herald’s Quick Take

Deciding what to do is the slow part of a request. Typing it is not. Open any ticket and Herald offers to read it for you: Ask Herald what to do. Click it and Herald goes through the whole thread, the photos on the ticket and in its replies, your covenants, and the prior tickets at that same address, then comes back with a take.

What lands:

• A headline and a summary - what this actually is, in a sentence you could read out at a meeting.
• The covenants it matched, as chips. Tap one and you get the quoted text and where it came from, so you can check the citation instead of trusting it.
• History at the address - “3 prior at this address,” with what happened on them.
• A recommendation, with the reasoning underneath it. Why? opens the rest: the risks Herald sees, the alternatives it weighed and when each is the better call, and the questions it still has.
• A governance gap when there is one - the awkward case where your documents don’t actually cover the thing being complained about. Advisory, not a verdict.
• A confidence percentage and a timestamp, at the bottom, always.

When the thread doesn’t support a call, Herald says so instead of guessing. The card reads Herald needs more before it can advise and lists what it would need. That’s the honest answer, and it’s the one you want.

The take is saved on the ticket, so the whole board reads the same one instead of each member generating their own. If the ticket changes afterwards - a new reply, a new photo, a type or status change - an amber line appears across the top saying so, with Refresh next to it. Age alone never stales a take. Only a change to what it read does.

Solve It

Under the recommendation is a button that names the action in plain words: Solve it: close with a warning, Solve it: close with a fine - $250.00, Solve it: approve it. There are sixteen actions Herald is allowed to recommend and no more. It cannot invent a seventeenth.

Here’s the important part: the button writes nothing. It opens the flow you would have opened yourself, with Herald’s draft already in the fields - the notice to the offending address, the acknowledgement to whoever reported it, the fine amount, the letter body. You read it, change what you want, and that flow’s own confirm button does the work. A person sends every message HomeHerald sends on a ticket.

Three rules it follows without being asked:

• A button you can’t use never appears. An action that doesn’t apply to this ticket’s type, or needs something your community hasn’t turned on, or would act on a ticket that’s already Closed, is hidden rather than shown greyed out.
• Drafts don’t travel between outcomes. Each alternative under Why? has its own Use this instead, and text written about one outcome never rides into another - a “you have been fined $250” paragraph can’t end up in a warning. Those fields open empty and the flow’s own AI Draft button refills them for the outcome you actually picked.
• “Nothing to do here” is a real answer. When that’s the recommendation there is no button, because there is nothing to execute.

Comments and updates

Every status change is logged in the request’s history. Comments are added in-thread and visible to:

• The reporter
• The board / admin
• The accused (for complaints, once the violation is issued)

Notifications

The system sends emails on status changes:

• Resident → Admin notifications: when a new request is filed
• Admin → Resident notifications: when status changes, comments are added, or a fine is issued

Service-level expectations

These are guidelines, not rules. Use what fits your community.

Type	Expected first response	Expected resolution
Complaint	24 hours	7-14 days for normal cases
ARC	48 hours	Within 30 days (your bylaws may specify)
Neighborhood Request (urgent)	4 hours	Same day or next
Neighborhood Request (routine)	24 hours	30 days
General	24-48 hours	Varies by question

Common situations

”A request has been New for a week and nobody noticed”

That’s a process gap. Two ways to fix:

1. Set up notifications. Enable email pings for new requests under your profile so they don’t slip past.
2. Designate an owner. Pick one board member as the “request triage” person. They acknowledge everything within 24 hours and route to the right person.

”A complaint is being investigated for a month and the reporter is asking for updates”

Update them in-thread: “We’re still gathering info, expect a decision by [date].” Don’t go silent. The investigation taking time is fine; not communicating is the problem.

”I marked something Closed but the resident isn’t satisfied”

If they reply, the request can move back to Under Investigation. Hear them out. Sometimes you’ll change your mind; sometimes you’ll re-close with more explanation. Either way, keep the conversation going.

”This came in as the wrong type”

It happens constantly - somebody files a maintenance issue as a complaint, or an ARC request lands as a general question. The type isn’t locked in. Open the ticket, click the type under Type in the header (or the type chip in the details sidebar), pick the right one under Reclassify as, add a line saying why, and click Reclassify.

What happens next is the point. Your reason goes into the thread, the old AI screening is archived instead of overwritten, and Herald re-checks the whole thread against your covenants for the new type. Money and decisions are never rewritten by a type change: if the ticket already carries a fine, a recorded outcome, an ARC decision, or a Herald Shield resolution, HomeHerald stops and tells you exactly what survives before it lets you continue.

”We have 50 closed requests cluttering the dashboard”

Closed requests should already be hidden from active dashboards by default. If you’re seeing them, toggle the filter. They remain searchable.

Where to go next

• The four request types - picking the right type at filing time
• Issuing a fine - what happens when a complaint becomes enforcement
• Escalations and repeat offenders - automated handling of repeat violations
• Publishing to the public board - community visibility on resolutions