How MYLO Prepares a Lead File for Calling

MYLO prepares a lead file before calling by turning an uploaded business list into a reviewed set of campaign records. The guided stage identifies the phone-number column, preserves useful business fields, normalises values for the selected country, marks invalid or missing numbers, identifies duplicates, and presents a preview for human review. Only an approved result becomes input to deterministic campaign execution. Uploading a spreadsheet does not authorise calls, prove consent, or validate that every person may lawfully be contacted. The customer remains responsible for the source, purpose, permissions, suppression obligations, contact times, and accuracy of the list. MYLO’s role is to make preparation visible and controlled so a malformed file does not silently become an active outbound campaign.

Start With an Authorised Source

Before opening the file, identify where the records came from and why the business intends to call them. A customer list, requested-callback list, appointment reminder list, and purchased prospect list have different legal and operational risks. File cleaning cannot create consent or convert an unsuitable source into an acceptable one.

The business should document the campaign purpose, intended audience, lawful basis or consent process as applicable, suppression sources, permitted schedule, and internal owner. Remove data that the campaign does not need. A telephone campaign generally should not carry unrelated identity documents, payment information, health details, or free-text notes merely because they happen to exist in the source spreadsheet.

Use a Clear Input Structure

A practical file uses one header row and one record per row. Column names should be understandable, such as phone, customer_name, account_reference, language, or appointment_date. Avoid merged cells, hidden totals, decorative title rows, several tables on one sheet, formulas whose displayed values can change, and phone numbers stored in ways that lose leading digits.

CSV can be a simple exchange format, while a supported spreadsheet format may be easier for business users. The exact accepted formats, size, encoding, and required columns should come from the current MYLO product interface rather than an assumption. If the file cannot be read safely, preparation should stop with an actionable explanation instead of guessing at its layout.

Identify the Phone Column

MYLO can guide the user in selecting which column contains the destination phone number. A header called mobile may be obvious, but files often contain office_phone, alternate_number, or several contact fields. The system should not silently choose between several plausible columns when that choice changes who will be called.

A preview helps the user confirm that the selected column contains phone-like values and that adjacent fields still line up with the correct person. If several numbers per person are needed, the campaign design must state which one is primary and how alternatives are treated. It should not accidentally turn one business record into repeated calls across every number.

Clean and Normalise Without Inventing Data

Preparation can remove harmless presentation characters such as spaces, brackets, or hyphens and interpret recognised prefixes under the chosen country context. It can detect blanks, impossible characters, and values that do not meet the configured structural expectations. Normalisation should produce a consistent dialable representation while retaining enough evidence to explain the transformation.

Cleaning must never invent missing digits, assume a country from weak evidence, or describe structural validation as proof that a number belongs to the named person. A well-shaped number may still be disconnected, reassigned, on a suppression list, or inappropriate for the campaign. Those are separate business and compliance questions.

Handle Invalid Records and Duplicates Explicitly

Invalid rows should be separated from eligible rows with understandable reasons: missing number, unsupported characters, invalid length for the selected context, duplicated normalised destination, or another defined preparation error. Do not quietly drop rows without reporting the count. The user needs to know whether a file of 1,000 rows produced 995 callable records or only 300.

Duplicate handling should use the normalised destination, because two differently formatted values may represent the same phone. The business must decide whether one call per number is appropriate when several records share it. Keeping the first row, keeping the newest record, or merging fields are business decisions; MYLO should present the conflict rather than invent a policy.

Review a Campaign Preview

The preview should show the intended campaign name and type, selected phone column, country context, total input rows, eligible records, invalid records, duplicates, and a small privacy-conscious sample. It should also show the mapping of useful fields that may be available to the agent or IVR. Sensitive data should not be exposed broadly in the review screen or copied into logs.

Review is the point to discover shifted columns, unexpected country codes, blank names, expired appointments, and wrong audience segments. Spot-check the start, middle, and end of the source rather than approving only the first few rows. If the preparation changes, generate a new preview; approval of an older preview should not silently authorise a different result.

Approval Is Not the Same as Execution

Approving the prepared list confirms that the reviewed data may proceed to the next campaign stage. It does not mean the campaign should immediately originate calls without its other requirements. MYLO still needs the selected connection flow, eligible caller-ID pool, agent or IVR destinations, schedule, pacing, retry policy, recording decision, capacity checks, and a functional test.

Once the campaign is active, deterministic services—not an LLM—should own lead claiming, pacing, attempt state, capacity, retry eligibility, pause behaviour, and recovery. This boundary prevents a conversational assistant from improvising operational decisions during a live campaign.

Practical Example: Appointment Reminders

A clinic exports 1,240 upcoming appointments with patient reference, first name, mobile number, appointment date, and location. Its authorised team confirms the reminder purpose and applicable contact rules, then removes clinical notes because the calling workflow does not need them. The user selects mobile as the phone column and the correct country setting.

Preparation finds blank numbers, malformed values, and repeated destinations for family members. The clinic reviews each category and decides how shared numbers should be treated. The approved preview contains only eligible records and the fields needed for the reminder. The team then configures the specific campaign type, schedule, recording decision, caller IDs, and IVR response flow, and completes a functional test before wider calling.

Failure Handling and Data Protection

If parsing fails, the system should preserve the uploaded source according to the approved retention policy, report the reason, and avoid creating a partly usable campaign. If a later validation fails, the approved lead set should not be mutated invisibly. Corrections should create a clear new preparation result with its own review evidence.

Limit file access to authorised users. Protect uploads at rest and in transit within the supported deployment, avoid including raw rows in general logs, and delete source or derived data according to purpose and policy. Exporting invalid rows for correction is itself a data-handling action and should preserve access controls.

Lead-File Preparation Checklist

• Document the list source, campaign purpose, audience, and responsible owner.
• Confirm applicable consent, suppression, schedule, and contact requirements.
• Remove fields the campaign does not need.
• Use one header row, one record per row, and clear column names.
• Select the phone column and country context deliberately.
• Review normalised, invalid, missing, and duplicate counts.
• Resolve shared numbers and duplicates with an explicit business rule.
• Spot-check a privacy-conscious preview across the whole file.
• Approve the exact prepared result, not an earlier version.
• Complete campaign configuration and functional testing before live execution.

Good preparation makes the campaign’s input explainable. It reduces avoidable failures while keeping the crucial boundary clear: MYLO can structure and validate records, but the customer decides whether those records should be contacted.

Define an Acceptance Record for the Prepared List

Before moving to campaign configuration, save a concise acceptance record that identifies the source version, uploader, preparation time, selected phone column, country context, input count, eligible count, rejected categories, duplicate decision, and approving user. Include a checksum or another supported identity for the exact source or prepared result where available. This protects against a later file with the same name being mistaken for the approved one.

Reconcile the counts mathematically: every input row should be explained as eligible, invalid, blank, duplicated, suppressed, or another documented category. If categories overlap, explain the precedence so totals remain understandable. Approval should fail safely if the underlying result changes after preview. This evidence gives a later operator a reliable starting point without exposing the full audience in a general log.

Final Handoff to Campaign Setup

The approved preparation result should enter campaign setup as an immutable reference, not as a spreadsheet that can still be edited in place. The setup summary should repeat the eligible count and source identity so the operator can detect a mismatch before calling. If a new suppression, correction, or audience change arrives, generate and approve a replacement result.

This handoff preserves a clean boundary: preparation determines which reviewed records are eligible inputs; campaign configuration determines how, when, and with which resources they may be attempted. Neither stage replaces the customer’s legal and business authority.

Persist Only the Approved Usable Lead Set

After MYLO identifies the intended mobile-number column, ambiguous mappings must be confirmed. Numbers are normalised, duplicates removed and unusable rows discarded. The retained count is reported before the approved usable list is persisted. AI may help understand the uploaded file, but deterministic runtime services—not an LLM—decide which persisted record is eligible for the next call.