An automated message can be perfectly written and still reach the wrong person. That happens when an old enquiry looks active, two advisers hold separate versions of a customer or a shared email address gets mistaken for one traveller. Before you switch on another workflow, check the records that will drive it. A tidy-looking database can still contain some awkward surprises.

This is a practical clean-up exercise for an existing travel CRM. You don't need to redesign every field or buy another system to begin. Start with the records feeding the first automation you intend to use, then work outwards as you learn where the problems enter.

Define the records you will correct

Export a dated sample containing the record identifiers and the fields your intended automation uses. Keep the original unchanged and make proposed corrections in a separate working copy. Include contact and enquiry identifiers so a reviewer can trace each change back to its source. Assign someone to approve uncertain matches before any corrections reach the live database.

Pipedrive's import guidance provides a useful example of why record types matter. It explains that deals with the same name aren't automatically treated as duplicates during import. For people, its matching process uses the name alongside organisation, phone or email information. A spreadsheet that looks repetitive to you may therefore create several legitimate deal records or merge contact information, depending on the record type and matching fields.

Write down what counts as a duplicate in your business before anyone starts merging. A repeated copy of the same enquiry is different from a new enquiry by the same customer. Two family members sharing an email address are still two people. Give staff a place to flag uncertainty instead of asking them to resolve every ambiguous match immediately.

Check the matching rule before merging anything

Choose a small sample of suspected duplicates and inspect the original conversation beside each record. Look for differences in names, travelling parties and booking references. Confirm which details are current with the colleague handling the relationship where possible. A matching phone number is a clue, not permission to combine everything attached to it.

HubSpot's duplicate-record documentation describes reviewing potential contact or company matches and either merging or rejecting them. The duplicate-management tools have subscription and permission requirements. This is a useful reminder to check what your own software actually permits before planning a mass clean-up. A feature mentioned in a demonstration may not be available under every account arrangement.

Before any live merge, ask your provider about recovery limitations and prepare an appropriate backup. An export alone may not recreate every relationship between records, and some systems cannot reverse a merge. Keep a record of the identifiers you merge and the reason for the decision. After one approved merge, compare the result with your saved sample: check that notes, attachments and linked enquiries still belong to the right record.

Correct the fields that decide what happens next

Focus first on fields used to start, stop or route work. An owner field decides who receives a task; an enquiry status may decide whether a reminder is prepared. Dates can determine whether the record appears overdue. You need consistent meanings for these fields before a workflow can use them sensibly.

For each field, agree what evidence supports a change. "Quote sent" should mean the proposal has actually left the business, rather than being saved halfway through preparation. A booking should move out of the active sales queue when its confirmed position is recorded. Check how pending supplier confirmation is represented so staff don't close the conversation too early.

Use a clearly labelled fictional example to test the rule. Suppose Alex submits an enquiry on Monday, receives two options and then books by phone with another adviser. The clean record should allow the team to identify that booking before another quote reminder is prepared. Our follow-up playbook explains the communication side; this exercise checks whether the underlying data supports it.

Decide which system can correct which fact

A connected setup needs agreement about where corrections happen. Contact information may be maintained in one application while booking status originates elsewhere. If staff update both independently, the next synchronisation may bring an old value back. Ask your provider to explain the update rules and show what happens when the systems disagree.

For each shared field, name the system allowed to supply the final value and document how a conflicting correction is resolved. Check a corrected sample again after the next synchronisation. Give someone responsibility for investigating values that revert or duplicates that return. Keep those exceptions outside the next automation test until the cause is understood.

Travelgenix's Travelify page describes customer history alongside bookings and a viewer for website enquiries. Those records have different operational purposes even when staff can reach them within one product. During setup, ask us to demonstrate how a correction affects the connected workflow your team intends to use. Apply the same request to any other platform you operate.

Test automation with deliberately awkward records

Use invented test contacts and keep customer-facing sending disabled while checking the first workflow. Include a duplicate enquiry, a customer who has already booked and a record without an assigned owner. Add a case where the trip date has changed. Check the result of each case against the action your team expected.

Pay particular attention to stopping conditions. A workflow that starts correctly can still continue after a reply or a change of plan. Confirm how staff pause it and how queued actions behave when records are merged. Keep contact preferences and marketing permissions under the control of the person responsible for those rules; a data clean-up should never silently change them.

Pick the first automation your team wants to use and list the fields it depends on. Assign one colleague to review a manageable sample of those records this week. Turn the exceptions they find into specific correction rules before you let that workflow act on the wider database.