Data Entry Specialist

Screening notes

Experience

5 years of data work for US clients, starting in straight entry and moving into migrations. Last two years I ran CRM migrations at a Manila outsourcing firm — the largest was 41,000 contact records out of a legacy Access database into HubSpot, done over six weeks with a 0.3% error rate measured on a 400-record audit sample the client pulled themselves, not one I chose. Before that, three years of invoice and purchase-order entry at 300–400 documents a day.

Tools

Excel (XLOOKUP, Power Query, conditional formatting for duplicate detection), Google Sheets, HubSpot, Airtable, OpenRefine for messy datasets, Adobe Acrobat for PDF extraction. I use Power Query rather than manual cleanup wherever the source is consistent enough, because a repeatable transform can be re-run when the client sends a corrected file and hand-editing cannot.

Scenario answer

Asked: Halfway through migrating 4,000 customer records you notice about 200 have phone numbers in a different format and a handful have obviously impossible dates of birth. You were asked to finish today. What do you actually do?

I would stop and send a message before touching another record, and I would not finish today. Here is why and what I would actually do. The 200 phone numbers and the impossible dates are two different problems and conflating them is the mistake. The phone formats are a formatting problem. That I can solve without asking: they are almost certainly a mix of local and international notation, or numbers that lost a leading zero because a spreadsheet read them as numbers. I would write one transform that normalises everything to a single format, run it, and spot-check thirty of the two hundred by eye. I would not hand-edit two hundred cells — hand-editing is where new errors come from, and it cannot be re-run if the client sends a corrected export. The impossible dates of birth are a data problem and they are not mine to decide. A date of birth of 1900-01-01 or 2087-03-14 usually means one of three things: a required field somebody typed junk into, a system default, or a genuine transposition. Which one it is changes what should happen, and only the client knows. Guessing at a person's date of birth in a customer database is the kind of quiet error nobody finds for two years. So: I pull those records into a separate tab, with the row number, the original value and what I think the cause is. Then one message to the client, today, early enough that they can answer today: here is what I found, here is what I have already fixed, here are the N records I need a decision on, and here is the one I would recommend. Short, and with the sheet attached. Then I would say plainly that I will not finish today. I would finish the 3,800 clean records, hold the flagged ones, and give a realistic time for the rest once I have the answer. A migration delivered on time with 200 invented dates of birth in it is worse than one delivered a day late, and it is worse in a way that only shows up after everyone has stopped paying attention. One more thing I would do unasked: check whether the 200 bad phone numbers and the handful of bad dates are the same records. If they are, that is a batch — an import from one source, or one period — and the client will want to know that far more than they want the individual rows.

Work sample

Asked: Given a messy spreadsheet (duplicates, inconsistent name and date formats, one impossible value), describe the exact steps you'd take to clean it — in order — and what you'd flag to the client rather than fix yourself.

CLEANING A MESSY CONTACT LIST — the exact steps Assumption: a CSV export, a few thousand rows, going into a CRM. Deliverable is a clean import file plus a flagged-exceptions sheet. BEFORE ANYTHING 0. Copy the raw file and never touch the original again. Every step below runs on the copy. If step 6 goes wrong I want to restart from truth, not from my last save. 1. Row-count the raw file and write the number down. The final import count plus the flagged count must equal it. This is the check that catches silently dropped rows, which is the failure nobody notices. STANDARDISE, IN THIS ORDER 2. Trim whitespace on every text column first. Half of what looks like a duplicate is "Maria " versus "Maria". 3. Names: split into first and last only if the source is consistently "First Last". If it contains titles, suffixes or two-word surnames, do not auto-split — flag the ambiguous ones instead. Auto-splitting names is how "Van Der Berg" becomes a first name. 4. Dates: convert everything to ISO (YYYY-MM-DD). The trap here is the ambiguous ones — 03/04/2024 is two different dates depending on the source's locale. I check the source's locale once, apply it, then verify by finding any date where the day component exceeds 12 and confirming those parse the way I expect. If a file contains both formats mixed, the file cannot be converted safely and that goes to the client. 5. Phones: normalise to E.164. Restore leading zeros lost to numeric formatting, add country codes where the source's country is known. 6. Emails: lowercase, trim, and validate the shape. An invalid email is flagged, not deleted — the client may have the correct one elsewhere. DUPLICATES 7. Exact duplicates on email first — those are safe to merge. 8. Then fuzzy duplicates: same last name plus same phone, or same email domain plus same first name. These are NOT auto-merged. They go to the exceptions sheet with both rows side by side, because merging two real people who share a surname and a company phone number is unrecoverable once the source is gone. FLAG, DO NOT FIX 9. Anything in this list goes to the exceptions sheet rather than getting a value I made up: - impossible dates (future births, pre-1900, obvious defaults like 1900-01-01) - values in the wrong column (an email in the phone field — usually one shifted row, and if so the rows around it are shifted too, which is worth saying) - records missing a field the CRM requires - fuzzy duplicate pairs Each row gets: row number, field, original value, why it was flagged, and my suggestion. FINISH 10. Reconcile the count from step 1. Clean + flagged = raw. If it does not balance, find the difference before delivering. 11. Spot-check 30 random rows against the raw file by eye. Not the first 30 — random, because errors cluster. 12. Deliver both files together and lead the message with the exceptions, not with the clean count. WHAT I WOULD FLAG RATHER THAN FIX, IN ONE LINE Anything where being wrong is invisible. A mangled phone number gets discovered the first time someone calls it. An invented date of birth never does.

Availability

Full-time, flexible PHT with 3–4 hours of US overlap. Available in two weeks.

Screening notes

Experience

4 years of data operations, two of them supporting a US logistics company from Bogotá on US Central hours. Daily work was entering and validating shipment records — around 250 a day — plus a monthly reconciliation between the client's spreadsheet and their TMS. I found and reported a recurring mismatch where a weight field was being entered in kilograms by one warehouse and pounds by another; it had been running for about seven months and was skewing their freight cost analysis. Nobody asked me to look, it just did not add up.

Tools

Excel and Google Sheets (advanced formulas, pivot tables, some Apps Script), Airtable, Zoho CRM, SQL basics for pulling records to check against

Scenario answer

Asked: Halfway through migrating 4,000 customer records you notice about 200 have phone numbers in a different format and a handful have obviously impossible dates of birth. You were asked to finish today. What do you actually do?

I would not finish today, and I would say so before the end of the morning rather than at 5pm. The two issues are not equivalent. The phone formats are mechanical — I can normalise them with a formula and verify a sample. That does not need anyone's permission and it does not need to stop the work. The impossible dates of birth do need permission, because fixing them requires deciding what the correct value is, and I do not have that information. A date that reads 01/01/1900 is almost always a system default rather than a real entry, but "almost always" is not a basis for writing something into a person's record. So my actual sequence: 1. Continue the migration for the clean records so momentum is not lost. 2. Build a normalisation for the phone numbers and run it, then check a sample of around 30 by eye against the source. 3. Pull every anomalous record into a separate sheet with the row reference, the original value, and my reading of what caused it. 4. Message the client before lunch — not at the end of the day — with the exceptions sheet, what I have already handled, what I need a decision on, and my recommendation for each. Sending it early is the difference between an answer today and an answer tomorrow. 5. Say clearly that the deadline will slip on the flagged subset, and give a new one. The reason I would not just fill in the dates and move on is that this kind of error is invisible after delivery. A wrong phone number gets found the first time someone dials it. A wrong date of birth sits in the database looking exactly like a right one, and three years later somebody runs an age-based report on it. I would also check whether the bad records cluster — same import batch, same date range, same source system. If they do, the client has one problem rather than two hundred, and that is the more useful thing to tell them.

Work sample

Asked: Given a messy spreadsheet (duplicates, inconsistent name and date formats, one impossible value), describe the exact steps you'd take to clean it — in order — and what you'd flag to the client rather than fix yourself.

CLEANING A MESSY LIST — my procedure SETUP 1. Work on a copy. The original file stays untouched so I can always go back and compare. 2. Record the starting row count. At the end, clean rows plus flagged rows must add back up to it. STEP BY STEP 3. Trim leading and trailing spaces across all text fields. This has to happen before duplicate detection or half the duplicates will not match. 4. Standardise capitalisation on names and cities (proper case), but leave anything that looks like an acronym or a company name alone. 5. Dates: pick one target format, YYYY-MM-DD, and convert. Where the source mixes DD/MM and MM/DD I look for rows where the first component is above 12 to work out which convention the file follows. If both conventions appear in the same file I stop and ask, because a wrong guess silently corrupts about half the dates. 6. Phone numbers: strip formatting characters, restore any leading zeros the spreadsheet removed, and apply the country code. Verify the resulting lengths are consistent. 7. Emails: lowercase and check for a valid structure. Invalid ones get flagged. DUPLICATES 8. Sort by email and remove exact duplicates where every field matches. 9. Where two rows share an email but differ in other fields, do not merge automatically — they go to the exceptions list, because deciding which version is current is the client's call. WHAT I FLAG RATHER THAN FIX 10. Impossible values — dates in the future, ages over 120, placeholder entries like 000-000-0000 or test@test.com. 11. Data in the wrong field, which usually means a row shifted during export and the neighbouring rows need checking too. 12. Records missing a required field. DELIVERY 13. Reconcile against the starting count. 14. Spot-check a random sample of rows against the original. 15. Send both the clean file and the exceptions list, and lead with the exceptions so they are not missed.

Availability

Full-time, 8am–5pm CT from Bogotá. Two weeks' notice.

Screening notes

Experience

3 years of data entry work. I started as an encoder at a Cebu BPO doing medical records, then moved to a US client where I entered orders into their system from PDF purchase orders, around 150 a day. I have a typing speed of 72 words per minute with 99% accuracy and I am known for being very careful and detail-oriented. I always double-check my work before submitting it.

Tools

Microsoft Excel, Google Sheets, Microsoft Word, Adobe Acrobat, and the client's internal order system

Scenario answer

Asked: Halfway through migrating 4,000 customer records you notice about 200 have phone numbers in a different format and a handful have obviously impossible dates of birth. You were asked to finish today. What do you actually do?

I would first finish normalising the phone numbers so they are all in the same format, because consistency in the data is very important and the client will want them to look uniform. For the records with the impossible dates of birth, I would correct them as best I can. If the date is clearly a typing error I would fix it, and if it is not clear I would leave the field blank rather than putting in something wrong. I would then continue with the rest of the migration so that I can meet the deadline, as I was asked to finish today. I would work through the remaining records carefully and double-check my entries as I go. At the end I would send the client a summary noting how many records had formatting issues and how many had date problems, so they are aware of what I found during the migration. I take accuracy very seriously and I would make sure the final file is as clean and correct as possible before handing it over.

Work sample

Asked: Given a messy spreadsheet (duplicates, inconsistent name and date formats, one impossible value), describe the exact steps you'd take to clean it — in order — and what you'd flag to the client rather than fix yourself.

STEPS FOR CLEANING A MESSY LIST 1. Open the file in Excel and save a copy as a backup. 2. Use the TRIM function to remove extra spaces from all the text columns. 3. Use PROPER to fix the capitalisation of the names so they are consistent. 4. Sort the data by the email column so that duplicates appear next to each other. 5. Use Conditional Formatting to highlight duplicate values, then review them and delete the ones that are exact duplicates. 6. For the dates, select the date column and use Format Cells to change them all to the same date format. 7. For the phone numbers, use Find and Replace to remove any dashes, brackets and spaces so they are all just digits. 8. Look through the data for any values that are obviously wrong, such as a date of birth in the future, and correct them or leave them blank. 9. Check the whole file one more time from top to bottom to make sure nothing was missed. 10. Save the cleaned file with a new name and send it to the client. WHAT I WOULD FLAG TO THE CLIENT I would tell the client about any records where information was missing or looked incorrect, and about how many duplicates I removed, so they know what was changed.

Availability

Full-time, can work night shift PHT. Available immediately.