Defect and Issue Register: the "Issue–Responsible–Deadline" Model

Why you need a register if you already have chats and email

Chats and email are handy for quick exchange, but they are poor tools for control. Messages get pushed up and lost in forwarded chains, and verbal requests often aren't recorded at all. As a result, small problems like a leaky bathroom, a squeaky server-room door or a missing panel label can live for weeks until they become an incident.

The danger of these "small things" is that they accumulate and become more costly. A small leak becomes damage to finishes and wiring, a loose fastener becomes an injury risk, and "the fan is a little noisy" becomes equipment downtime. A defect and issue register lets you see the queue of problems, keep to deadlines and verify fixes, not just "pass to someone to do."

The register solves three tasks: tracking (nothing disappears), deadline control (overdues and workload are visible) and verification (we close only after confirmation). It's important to record not just the issue, but the responsible person, the deadline, what was done and who accepted it.

To avoid turning the register into a dump of everything, agree on the boundary from the start. A defect is a deviation from the norm or a fault that needs fixing. An improvement is a change "to make it better" (for example, moving furniture or adding sockets). Improvements can be tracked separately or marked as a different type.

Minimum rules to make the system work:

• Any remark from an inspection, email or chat is entered into the register the same day.
• Each record has one responsible person and a deadline (a specific date).
• Closure happens only after verification (photo, re-inspection, act).
• If a deadline is missed, change the deadline with a reason — do not stay silent.
• One object — one register, so versions don't split.

Record model: issue — responsible — deadline — resolution — check

For the register to work, each record must be verifiable. Write so anyone can come to the site and unambiguously say: fixed or not. Instead of "poorly fastened" write: "cable tray in the corridor on the 2nd floor detaches from the wall by 30–40 cm, screw heads visible."

A card is based on a simple set: where, what is wrong, who is responsible, when to fix it, what was done and who accepted. Without these fields records quickly start to "sink":

• object and zone (building, floor, room, node);
• date and author of the record;
• defect description (1–2 sentences) and severity;
• confirmation (usually photo before and after);
• responsible person and deadline.

The "responsible — deadline" pair matters more than any comments. The responsible person is one person, even if there are several performers. The deadline should be realistic, accounting for access, procurement and approvals.

The "resolution" field is filled in after the work: exactly what was done, which materials were used and how it is proven (photo, act, journal note). Example: "replaced door closer, adjusted; door closes without impact; photo after."

The "check" field separates work from result. State who checked, when and the outcome (accepted/not accepted) with a short reason. If not accepted — record what remains and a new deadline. This prevents small problems from cycling back.

Statuses and rules for issue flow

Each issue should have a single current status and clear transition conditions. Then you can immediately see where a task is "stuck" without asking in chats.

A practical set of statuses:

• New — the issue is recorded and needs a responsible person.
• In progress — a responsible person and plan exist.
• Resolved — the performer reports the work is done and provides proof.
• Under inspection — an inspector is assigned and checking the result.
• Closed — inspection passed and result accepted.

A common confusion is between "resolved" and "closed." "Resolved" is the performer's claim: "I did it." "Closed" is the inspector's decision: "accepted and requires no further action." If the check fails, the issue goes back to "in progress" with a concrete reason.

Use the "Rejected" status carefully: only if the problem is not confirmed, relates to another object or was already fixed earlier. Always record the reason for rejection — otherwise the register becomes a tool to "hide" awkward questions.

A simple rule helps with deadlines: allow one postponement without approval (for example, due to site access); after that, any change needs a reason and confirmation. The reason must be specific: "no access to the server room before 15:00", not "didn't make it."

Severity sets expectations and prevents small issues from piling up: emergency (hours), planned (days), cosmetic (a week or two). To avoid "perpetual" tasks put stop signals:

• no responsible person within 24 hours — escalate;
• status "in progress" without updates for more than 3 days — request status;
• overdue deadline — a new plan and check date are mandatory;
• more than 2 cycles "in progress -> under inspection -> in progress" — analyze the cause.

How to link defects with inspections and walkthroughs

Each register entry should have a clear source. Minimum: planned inspection, ad-hoc check (after a complaint, incident, weather) or an employee report. This helps understand context quickly and avoid disputes about "when it appeared."

It's convenient when each inspection has a number and a short card: date and time, route or zone, who conducted it and the overall findings. Then you attach an issue to a specific inspection: "Inspection №2026-02-03-01, 3rd floor, corridor by the elevator." During acceptance you return not to a chat but to the point of recording.

Inspection template: so nothing is forgotten

A short checklist by zones and typical problems works best: entrance area, corridors, restrooms, electrical room, server room, parking. Leave a field per item for "normal/issue" and a short comment. This makes comparing inspections easier and helps separate real defects from one-off occurrences.

Differentiate repeat issues by meaning. If the same problem recurs in the same place (for example, the same radiator leaks again) mark it as a repeat with a link to the previous record and briefly note what was done before. If location or cause differs, create a new record — otherwise statistics and responsibility blur.

Photos and geotags: what helps

Photos are useful when they allow a decision: a wide shot (where it is) and a close-up (what exactly). Usually 1–2 shots suffice. A geotag helps on large sites, but don't make it mandatory for every small issue. A stable link to zone and inspection number is more important than trying to gather "perfect" data that delays inspections.

How to link defects with contractor work

Linking to contractor work prevents issues from hanging between operations and procurement. Practical rule: if the fix requires a license, special equipment, access to engineering systems, closures or a budget above your maintenance limit, convert the issue to a contractor task. Sometimes the reverse happens: a contractor finds new defects during planned work — these should be logged as separate items.

Add a "Contract" block to the card: request/order number, contractor, brief scope, estimate (or limit), start and end dates. Then you can find the issue by the order number and split one order into several issues by rooms or nodes.

To avoid arguments over "who should do it," predefine roles: who fixes, who accepts the result, who confirms scope and payment, who provides access and safety. Store this in the card or a short procedure — the main thing is consistency across objects.

Record not only before/after photos but also documents: act of completed works, as-built scheme (if needed), warranty period note and contacts for warranty calls. This saves time if the problem repeats a month later.

For hidden works and multi-step jobs do not close the issue at once. Break it into stages: "access/demolition", "hidden works", "restoration/finishes", "inspection". After "hidden works" make a mandatory check and acceptance note.

Classifiers you need so the register doesn't turn into chaos

Without unified directories entries will diverge. One person writes "corridor 2", another "corridor II", a third "2nd floor by the elevator." Filters stop working, reports lie and small issues get lost.

Minimum set of classifiers to standardize:

• object and zone: building, floor, room, node (for example, "Building A - 2nd floor - corridor - by elevator");
• defect category: electrical, HVAC, IT, finishes, safety;
• severity: 3–4 levels with clear criteria;
• performer type: maintenance team, IT, contractor, supplier;
• source: inspection, request, contractor work.

Define severity by rules, not "by eye": high — risk of injury or equipment shutdown; medium — affects comfort and may lead to failure; low — cosmetic without risk.

Agree on naming rules. A good description answers "what is wrong" and "where exactly":

• Bad: "Light not working."
• Good: "Building A, 2nd floor, corridor by the elevator: lamp №3 does not light, flickers when switched on."
• Bad: "Pipe leaking."
• Good: "Boiler room: drip at supply connection, wet spot 20 cm, requires tightening or gasket replacement."

This approach makes the register manageable: issues are easy to search, assign, verify and close without arguments.

Step-by-step setup of a register from scratch

Start with agreements, not a spreadsheet. A register works when everyone understands its purpose: so small problems don't get lost and responsibility and deadlines are visible. Appoint an owner of the process (usually the head of operations or facility administrator) who monitors rules and record quality.

Next, create a simple issue card. The fewer fields, the more likely people will fill it daily. Initially, space, description, photo (if available), responsible person, deadline and a check field are usually enough.

Basic launch steps:

• Define the register goal and appoint one owner who can change rules.
• Collect 20–30 typical situations and base the card template on them.
• Create directories: object, zone/room, category, performer.
• Configure statuses and rules: who sets the deadline, who accepts work, when proof is required.
• Run a pilot on one object for 2–3 weeks and fix what prevents daily entries.

Agree on default deadlines at setup. For example: "critical" — today, "high" — 24 hours, "normal" — 3 days. Also define what counts as closure (resolved + checked) versus merely "done."

Simple example: in a school small tasks like replacing a door closer were always lost. The pilot showed people wrote "fix door" without a location. Adding a mandatory "zone" field and a list of rooms stopped such tasks from bouncing between people.

Roles and responsibility: avoid "that's not mine"

Each step must have an owner. Otherwise records turn into a conversation where everyone sees the problem but no one must close it.

Anyone who spots a deviation on site can create an issue: engineer, security, cleaning staff, tenant representative. It’s important to capture context immediately so the responsible person doesn't spend time clarifying: location, proof (photo/video), what exactly is wrong and how it impacts operations, date and source.

The dispatcher/coordinator or area manager usually assigns the responsible person and confirms the deadline. They have an overview of workload and the authority to set priorities. The deadline is best discussed with the performer, but the assigner must have the final decision — otherwise postponements become routine.

A checker role is mandatory. This is someone who did not perform the work but accepts the result: is the issue actually fixed, is it safe, are there no loose ends. Without verification, "resolved" quickly becomes a formality.

Simple rule: one responsible person per issue. If multiple services are involved, keep one owner of the result and assign sub-tasks or mark others as co-performers with internal deadlines.

Handle overdues briefly and factually, without looking for blame. A 10-minute format works: what prevented closure, what will be done today and who accepts, is a deadline change needed and why, are there repeat issues and how to remove their root cause.

Reports that help manage, not just count

If the register is disciplined, reports become a management tool. Focus on data that helps make decisions this week, not on everything available.

A weekly snapshot is best built around issue movement: how many new, how many closed, how many became overdue, how many are stuck "under inspection." This shows quickly where the process stalls: in execution, acceptance or assignment.

Keep 5–7 recurring metrics to avoid drowning in indicators:

• new, closed and overdue issues for the period;
• average time to resolve (from registration to "resolved");
• share of overdues by responsible person and by object;
• workload: how many open issues each responsible person has;
• repeat issues (for example, same node/zone within 30 days).

A separate "top zones" report with repeat problems (lift lobbies, restrooms, server rooms, roofs, parking) helps move from patching to root-cause work: cleaning regime, weak materials, operational errors.

For contractor control, a few signals per contractor are enough: percent of overdue tasks, how many tasks were returned for rework after inspection, number of repeats from their works, average closure time.

Common mistakes and traps when running a register

The most common mistake is turning the register into a catch-all. Then people stop using it: you can’t find important items and can’t tell what was actually done.

Mistakes that break the process

Common traps include:

• Too vague descriptions: "make it right", "fix", "look into it". From such records you cannot accept the work.
• Closure without verification. The performer marks "done", the record is closed, but nothing changed on site.
• No ownership of deadlines. A responsible person is named but no one enforces dates and postponements become normal.
• Mixing different task types. Defect, improvement, procurement and project work sit in one flow and fight for priority.
• Duplicates and parallel registers. The same issue lives in three places with different statuses.

How not to fall into these traps

Use a rule: each record must have a clear result and clear verification. For example, instead of "fix door closer" write "the corridor door on 2nd floor closes on the first attempt without impact; check after adjustment."

Separate flows: defects in one register, improvements and procurement in separate lists. Then defects are easier to manage: who is responsible, by what date and who verifies acceptance on site.

Short daily checklist for control

Daily control works best as a short ritual: 10 minutes in the morning and 2–3 minutes after lunch. The goal is simple: small problems don't get lost and big ones don't go overdue.

Morning 10 minutes: what to check

Run through five points:

• today's deadlines: what must be done by end of day and who is responsible;
• overdues: what prevents closure and what new realistic deadline is;
• new records: is there a clear location, description and priority;
• closures: is there proof of resolution and an acceptance note (who and when);
• contractor work: what finishes this week and what needs acceptance (act, photos, on-site check).

Then assign 1–2 quick actions: who to message, what to clarify, where to arrange access. One clear request with a deadline is often better than long threads.

Mini-check for inspections and acceptance

Ensure issues reflect reality. All new defects from an inspection should be linked to that walkthrough: date, route/zone and who was present. If an entry appears without linkage, ask: did this come from an inspection, a user or a contractor?

Maintain a short list of red flags for honest closures:

• closed without acceptance by the assigned checker;
• comment exists but no on-site proof;
• marked "resolved" but the issue appears again on a follow-up inspection;
• contractor finished work but the zone's issues weren't updated.

If this is done daily, the register becomes a working control tool, not an archive.

Example scenario: from inspection to closure

A typical day on site: an office, a warehouse and a small server room. Small problems are frequent and usually get lost: a lamp burned out in a corridor, a seal leaking at the warehouse gate, one of the server-room ACs making noise and intermittently throwing an error.

An operations engineer and a security officer do a planned inspection. They check typical points: lighting, doors and closers, restrooms, emergency exits, server-room temperature. Each defect is entered immediately into the register: description, location (floor, room, zone), photo, priority, responsible person and deadline. The record is linked to that inspection and its date so you see where it came from and who recorded it.

After the inspection two contractor tasks appear: replace two office corridor lamps and fix the leak at the warehouse gate. Each issue in the register is linked to contractor work: request number, contractor, agreed work window and on-site contact.

Acceptance is a separate step — a real "check," not a formality. After the performer marks "resolved" the engineer goes to the site: checks lamps light, verifies the leak is gone after gate operation. Confirmation is recorded (photo "after", measurement, short comment). Only then the status changes to "closed" and the history shows: inspection -> issue -> contractor work -> resolution -> check.

After a month the effect is usually visible: fewer repeats, clearer deadlines and a traceable history for each small problem — who was responsible and why a deadline was moved, if it was.

Next steps: how to automate the process carefully

Automation works best when you start small. Choose one object (or one object type), set a single issue card template and agree on one report that people actually read (for example, overdue and repeat issues). This creates clear rules and doesn't break team habits.

Moving from a spreadsheet to a ticketing system is useful when tasks get lost between shifts, the number of contractors and approvals grows, repeats appear, and audits require a clear history. If a spreadsheet already has dozens of rows per week and many fields, a system with roles and statuses will save time.

Add integrations step by step to avoid complicating the launch: inspections and walkthroughs (create an issue from a checklist), contractor works (acts and photo reports return to the card), stock and spare parts (why a deadline shifts), asset linkage (serial number, warranty, repair history), notifications and escalations.

For inspections and audits the most important thing is history: who found it, who took it into work, what was done, how it was proven and why a deadline changed. Then the argument "we fixed it" is solved by one card review.

If you need to link issue tracking with inspections, contractors and IT infrastructure, it's often best to do this with an integrator. GSE.kz (gse.kz) as a manufacturer and system integrator in Kazakhstan helps build such a connection: from process and roles to infrastructure and support, so the pilot doesn't stop halfway.