A client may report that a record in a business system is wrong and ask the software team to “just fix the data”. Sometimes the correction is straightforward, but a direct edit can hide an application defect, bypass normal business rules or change information the client did not actually authorise. Small software houses benefit from treating data-fix requests as controlled operational changes: establish the intended state, understand why the application cannot produce it normally and preserve enough context for support afterwards.
Capture the exact record and observed problem
Start with identifiers and the current visible state rather than a broad request to change “that customer” or “the last order”. Record what the client believes is wrong and where they see it. Avoid assuming that the database value is necessarily the source of the problem; the issue may involve display logic, synchronisation or another system.
Clarify the intended business state
A technical team should not invent the value a client wants. Obtain a clear authorised description of the intended outcome through the agreed support or change route. Where the correction has business consequences, make sure the right client owner is involved rather than relying on an informal message from whoever noticed the issue.
Ask why the normal application route cannot be used
If users can safely correct the information through the supported product workflow, that may preserve validation and audit behaviour better than a direct intervention. If the normal route is unavailable, blocked or would create a different problem, record that reason. This helps distinguish a genuine data repair from a convenience request that bypasses product controls.
Assess connected data before making a narrow edit
A field that appears isolated in the interface may feed reports, integrations or related records. The team should use its system knowledge to understand relevant dependencies before changing production data. Do not promise that an edit is harmless merely because the visible request concerns one value.
Separate one-off correction from software defect
If incorrect data resulted from a reproducible bug, create or link the appropriate defect work rather than treating the manual correction as the full resolution. Conversely, do not label every client data error as a product bug without evidence. Keeping the two work streams connected but distinct makes later support clearer.
Use a proportionate approval and execution record
Record who approved the intended state, who performed the intervention and what was changed. The level of formality can match the system and risk, but a production edit should not depend on a technician remembering a chat message months later. Sensitive information should remain within the organisation's appropriate systems rather than being copied unnecessarily into tickets.
Verify the result from the user's perspective
After the controlled change, confirm that the application now presents the intended state and that relevant processing behaves as expected. A database command completing successfully is not the same as the business problem being resolved. Where appropriate, ask the client to confirm the outcome through the normal support route.
Look for patterns in repeated data fixes
Recurring manual corrections may point to product usability, validation, integration or support-training problems. Review the pattern rather than normalising direct edits as routine service. This process is distinct from bug-report intake and client configuration handover: it governs a request to alter live client data while preserving the boundary between authorised business correction, technical execution and any underlying software improvement work.