Collecting feedback after a data import or migration

Why an import is one of the riskiest moments

An import moves a customer's existing work into your product. They trust you with records they spent years building, and they expect everything to appear in the same order with the same details. When a row is missing, a date is shifted, or a field lands in the wrong column, the user notices within minutes, often while they are trying to do something urgent. The problem does not stay small. It changes how much they trust every later step.

Most products measure an import by whether the job finished. That tells you the code ran, not whether the result is right. The people who know whether the result is right are the users who just imported their data, and they are the ones you should ask while the details are still fresh.

When should you prompt after an import?

Prompt immediately after the import completes, on the completion screen. The user has just looked at a summary and is deciding whether to trust it. A question at that moment catches problems they would otherwise discover days later, after they have built more work on top of the wrong data.

Do not wait for an email or a follow-up message. By the time an email arrives, the user has moved on, and a missing record has already caused a missed deadline or a call to a colleague. Ask on the same screen where the summary appears, and keep the question visible until the user dismisses it.

What should the completion prompt ask?

Ask one clear question: "Did everything come across as expected?" Put two actions under it. The first is a button labeled "Something is missing or wrong" that opens the widget with the bug type preselected. The second is a short line that says "Everything looks right" and closes the prompt. Do not ask for a rating, because a rating after an import measures relief, not accuracy.

Use the data-escuta-open attribute on the first button, and the bug type will open automatically. A bug type is correct here, because a missing record is a defect, even when the cause is the user's file.

<section class="import-summary">
  <p>Imported 412 rows from your file. 3 rows were skipped.</p>
  <p>Did everything come across as expected?</p>
  <button data-escuta-open="bug">Something is missing or wrong</button>
  <button type="button" data-dismiss-import>Everything looks right</button>
</section>

How do you record the import source and counts?

Pass the import details to setMetadata before the widget opens. The source tells you which importer produced the problem, and the counts let you check each report against the job. A report that says "rows are missing" is much easier to act on when it carries the number of rows read, written and skipped.

function onImportFinished(job) {
  if (!window.EscutaProduto) return;

  window.EscutaProduto.setMetadata({
    event: "data_import",
    importSource: job.source,
    rowsRead: job.rowsRead,
    rowsWritten: job.rowsWritten,
    rowsSkipped: job.rowsSkipped,
  });
}

Do not put the imported data itself in metadata. Metadata is limited to 4 KB, and the rows often contain personal data you should not copy into a feedback store. Counts and the source name are enough to find the job in your own logs.

How do you check a report against the import job?

When a report arrives, open the import job in your admin tools using the source and the counts from the metadata. If the rows written match the rows read minus the rows skipped, the importer behaved as designed, and the user may need help with the file format. If the counts do not match, the bug is in your code.

Read the message text too. A user who writes "the dates are one day off" has described a specific defect, and you can search your importer for the date handling. Escuta Produto does not connect to your import logs, so you do this check by hand, with the job id in an internal note.

What to do when the import was wrong

Respond quickly. A user with a broken import needs a fix, a plan and an honest answer, in that order. Confirm the problem, say what you are doing about it, and give a time for the next update. If the fix needs a re-import, offer to run it for them or walk them through it, depending on what your product supports.

Once the fix is live, reply from your own email to each person who reported a problem. Escuta Produto does not send messages to customers automatically, so this reply is yours to write. The guide to telling a reporter a bug is fixed covers the wording, and the onboarding feedback guide explains how to make the first import a smoother experience for the next customer.

Reading import feedback across customers

Import reports cluster by source. If three customers using the same importer report missing rows, the importer has a bug, even if each report looks unique. Filter the inbox to the product and search for the importer name in the message text, or in your own spreadsheet of metadata, if you export the items to CSV.

Count distinct accounts for each importer and each kind of problem. A single customer with a bad file is a support case. Five customers with the same date problem is a defect to fix in the importer, and it may be worth a short note to the other customers who used that importer during the same week.

Setting up the completion prompt in Escuta Produto

Create the product and copy its public key. Add the widget to the app where imports run, and open the bug type from the completion screen. The widget docs describe the open attribute and the metadata call. Each report arrives with the import source and counts in its metadata, plus the page URL saved automatically, so the item can be matched to the job in your logs.

Test the flow with a small file that you know has a skipped row. Confirm the completion prompt appears, the report opens with the bug type, and the metadata shows the expected counts. The feedback after first success guide explains why a successful first step is a good moment to ask for the next piece of feedback.