Structured data entry
High-volume entry against a written field standard, with formats validated on the way in.
Data work is the easiest thing to outsource badly. Somebody types four thousand rows, nobody checks them, and six months later a campaign goes out to a list where a third of the emails bounce and the company names are inconsistent enough that reporting is meaningless. The problem is never the typing, it is the absence of a validation step and a written field standard.
We run data work with the checking built in. Field formats and validation rules are defined before entry starts, records are entered against a written standard, a sample is verified independently at an agreed rate, and error rates are reported rather than assumed. Research work is the same discipline applied to sourcing: named sources for every data point, a stated confidence level, and a plain note when something could not be verified rather than a plausible guess.
Accuracy is a process, and processes have measurable error rates
Every supplier promises accurate data entry and almost none define what that means. Accuracy is not a quality of a person, it is a property of a process, and a process without a verification step has an error rate nobody knows.
We define the standard before entry starts: field formats, permitted values, what to do with ambiguous source data, and what a record must contain to be considered complete. Then a sample of completed work is independently verified at an agreed rate, and the error rate that comes out of that sample is reported to you rather than kept internal.
It changes the conversation from an assurance to a number. For clean structured entry we work to 99 per cent or better at field level and prove it. For messy sources we tell you what the realistic rate is before you commit, because a promise that cannot be kept is worse than a lower number you can plan around.
Research is only useful if the source is recorded
A researched dataset without sources is a set of assertions. Six months later, when a record turns out to be wrong, there is no way to tell whether the source was bad, the interpretation was wrong or somebody guessed, and no way to fix it except redoing the work.
So every researched data point carries its source and, where relevant, a date and a confidence marker. Verified means it was confirmed from a primary source. Inferred means it was reasoned from related data and might be wrong. Not found means exactly that, and it is left blank rather than populated with something plausible.
That last discipline is the one that separates useful research from expensive fiction. A field filled with a confident guess is worse than an empty one, because an empty field prompts somebody to check and a wrong one does not.
Cleaning a CRM without destroying it
The most common data request we get is a cleanup of a CRM that has been accumulating for years: duplicates, half-populated records, inconsistent company names, dead contacts, deals that were closed in someone's head but never in the system. It is genuinely worth fixing, and it is also where the most damage gets done.
We start with profiling rather than cleaning: how many records, how many duplicates by which matching rule, which fields are populated and to what standard, how many contacts bounce, how old the oldest activity is. That report is often the most valuable deliverable on its own, because it tells you whether the problem is worth the cost of fixing.
Then merge and deletion rules are agreed with you in writing before anything is touched, work is done on a backup or in a staged environment where the platform allows it, and merges are reversible for an agreed period. A cleanup that removes real customers is far more expensive than the mess it replaced.
Where automation helps and where it should not be trusted
Some data work should be scripted. Format normalisation, deduplication on exact and near-exact matching, validation against a pattern, bulk enrichment from a reliable source, and any transformation applied identically to thousands of rows. Humans are worse at these than scripts and get more tired.
Some data work should not be. Deciding whether two similarly named companies are the same entity, reading an ambiguous scanned document, judging whether a job title means the person is actually the buyer, and anything where the correct answer depends on context that is not in the data.
We use automation where it improves accuracy and tell you when we have. What we do not do is run a scraper over a source, deliver the output unchecked and describe it as research. That is the practice that produces lists where a third of the contacts are wrong and everybody's sending reputation pays for it.
Handling, storage and the rules around personal data
Data work touches information that matters. Customer records, contact details, financial documents, sometimes personal data with legal obligations attached. The handling rules should be agreed before the first file moves, not improvised.
Our default is that work happens inside your systems or a controlled environment we provide, not on local machines, and never on personal cloud accounts. Files are transferred through a channel you nominate. NDAs are signed before access. Access is revoked at the end of the engagement and any working copies are destroyed.
Where the data is personal and falls under India's data protection framework or a foreign regime such as GDPR, we scope the controls with you explicitly before quoting, and we would rather decline a job than take it on with the compliance question unresolved.