Naming and handoff workflow
The approval decision is not the end of the workflow. Once a render is safe to use, the team still has to label it clearly, separate it from draft or risky images, and hand it to the right person without losing the quote or revision context. That is where many showroom mistakes start.
Showrooms often spend energy on generating and reviewing images, then treat the final handoff as an admin detail. In practice, that last step determines whether the right visual reaches the client, the installer, or the next internal conversation. If naming is vague or the handoff pack mixes statuses, the team has already lost control.
A polished draft image can sit beside a genuinely approved visual and appear equally ready. Without a clear status in the name and folder logic, people rely on memory or chat history instead of the workflow.
Multi-designer teams often create several room versions quickly. If revision markers are inconsistent, an older export can be mistaken for the current design and reused in follow-up emails or presentations.
The designer may remember exactly what changed between options. The person presenting the visual later may not. Handoff discipline exists to make the image understandable without the original designer standing beside it.
That is why naming is not a cosmetic preference. It is part of review control. A strong naming rule makes the image legible; a strong handoff rule makes the decision around the image legible.
The first cue should anchor the image to the household, development, or showroom job so teams are not searching by aesthetics or remembering file dates.
Kitchen island angle, bedroom wardrobe wall, bathroom vanity view, or another specific room cue should appear in the name so the pack can be skimmed quickly.
Use a revision label the team already understands, such as `RevA`, `RevB`, or `Quoted`. If the revision is unclear, the handoff can never be fully trusted.
`Draft`, `Review`, `Retry`, `Approved`, or a similarly explicit status should appear either in the file name or the workflow system. Do not assume the folder alone carries enough meaning.
Some teams also add an owner or date stamp. That can help, but it is secondary. The core job is to stop someone from asking, `Which of these is the right one?` after the render has already left the review context.
The cleanest naming rule is usually the shortest one that still answers the important operational questions. A common pattern for KBB teams is:
Client-Room-Revision-View-StatusHarper-Kitchen-RevB-Island01-ApprovedSingh-Bedroom-Quoted-WardrobeWall-ReviewCole-Bathroom-RevA-Vanity02-DraftThe exact syntax matters less than consistency. If one designer writes `Final`, another writes `Ready`, and a third uses dates only, the team still has to decode what each file means. Naming discipline works because it removes interpretation.
Keep the names plain. Avoid emotional terms like `best`, `nice`, or `send-this-one`. Those labels feel helpful in the moment, but they do not tell the next reviewer or salesperson what commercial state the image is actually in.
Once the batch review is complete, pull the approved images into a clearly marked set. Do not leave them mixed with retries, alternates, or visually attractive drafts that are still commercially risky.
The handoff should make it obvious which design revision the render supports. If a quote changed after the render was created, the image needs to be rechecked rather than silently reused.
The next person should receive more than a JPEG. They should know whether the render is approved for client presentation, approved only for internal comparison, or still subject to caveats.
If an image needed extra explanation during review, it should not travel with the clean client set. Move it into a second-pass lane with the quote-safe review notes instead.
The handoff should state what happens next: send to client, hold for revision meeting, add to showroom pack, or keep for internal discussion only. If the next action is missing, the image tends to float into the wrong lane.
Kitchen packs often need view cues like `Island`, `TallWall`, or `DiningView` because several angles may be presentation-safe at once. The handoff also benefits from option cues when clients are comparing layout or finish routes.
Bedroom naming often needs wardrobe or joinery references because visually similar views can imply different fitted-storage decisions. Revision control matters more than style labels here.
Bathroom batches usually need tighter view naming because vanity, shower, and sanitaryware details carry high commercial meaning. A vague `bathroom-final` label is rarely enough for a finish-sensitive room.
Room-specific naming cues are most useful when they reflect how the team talks about the room already. The point is not to invent a taxonomy. It is to make handoff faster without making it looser.
Clear naming does not remove the need for clear presentation language. A correctly labelled image can still create expectation problems if the client is not told what the render is showing and what remains illustrative.
That is why naming and handoff should connect directly to the client-briefing workflow. The approved image, the current revision, and the talking points should all support the same story. If the file says `Approved` but the presenter still needs to guess which caveat applies, the handoff is incomplete.
In other words, the name tells the team what the image is. The briefing tells the client how to read it.
ARQ sits after the original design tool. The source room still comes from Winner, Virtual Worlds, SketchUp, ArtiCAD, AutoKitchen, 2020 Fusion, Compusoft, or another KBB workflow. ARQ is the layer where teams can queue exports, compare attempts, keep review state visible, and make the final approved set easier to identify and hand off.
That is especially useful once several people touch the same project: one designer exports, another reviews, a manager signs off, and a salesperson or founder uses the image in the client conversation. The operational value is not just the render itself. It is keeping the approved image tied to the right status and context as it moves.
ARQ fits when your showroom already exports room views and wants a clearer path from queue to approval to client-safe delivery. It helps keep draft attempts, approved visuals, and review context separated so the right image reaches the right person with less ambiguity.
Start a founder-led pilotAt minimum: client or project, room, revision, view, and status. That usually gives enough context for another team member to understand the image without opening supporting messages first.
Folders group the work, but they do not remove ambiguity inside a batch. If the individual image names are vague, approved and exploratory visuals can still get mixed up.
Usually no. Approved client-safe images should travel as a separate set so presenters do not accidentally pick up a draft, a retry candidate, or an image that still needs quote review.
No. ARQ is a post-export workflow. The design tool still creates the room; ARQ helps organise render production, review, approval, and handoff around the resulting visuals.