Someone may submit a website form and then call, leading the team to create two records unintentionally. However, a similar name or telephone number does not establish that two records belong to one person. Use this worksheet to review suspected duplicates before merging; it is not a rule for automatic deletion.
Separate the person from the request
One client may want a home and an office. Two requests do not necessarily mean a duplicate contact: preserve the purpose, budget and follow-up for each request. Family members may also share a telephone number. Review the contact's identity and the relationship between requests before deciding.
Copyable review table
| Field | What to record |
|---|---|
| Record identifiers | Both internal IDs, without publishing client information |
| Reason for review | Similar phone, matching email or closely timed enquiries |
| Additional evidence | Communication context or documented client confirmation |
| Important difference | Different name, independent property request or shared contact channel |
| Decision | Keep separate, link requests to one person, or merge after review |
| Information to preserve | Enquiry sources, appointments, notes and communication preferences |
| Owner and date | Who reviewed the case and when? |
Start with a small sample and establish an appropriate backup or recovery method before bulk changes. Check staff permissions and the system's actual merge and recovery capabilities. Moving a name and phone number does not necessarily move attachments or activity history.
Two decision examples
In a fictional case, two records share a name and email, and the communication history confirms that the person sent the same request twice. The reviewer checks notes and open appointments, identifies the surviving record, and preserves both enquiry sources. Merge only when the consequences are understood and supported by the system.
In another case, the phone matches but the names differ and each person has an independent requirement. Keep the records separate until the relationship is clear. A shared number is not a reason to reveal one person's request to another.
Check the result
Confirm that required requests, appointments and attachments remain available and that duplicate follow-up tasks were not created. If communication preferences conflict, do not automatically choose the more permissive option: review the source, date and current preference. Record the change and its author so colleagues can explain it later.
Use the worksheet outside the system first if necessary. Explore Devzonia's solutions and confirm supported operations with your team before acting; this worksheet does not assume a dedicated merge feature. Success means a clear record that preserves the person and their requests, rather than simply a smaller contact count.
