# rfp questionnaire csv import failed encoding: how to fix it

An RFP questionnaire CSV import encoding failure means the file isnt true UTF-8. Re-save it explicitly as UTF-8 CSV and import again. Questionnaires with international characters hit this constantly, and one bad byte can kill the whole import.

```text
rfp questionnaire csv import failed encoding
```

## When to use this skill
- Questionnaire CSV imports fail on encoding
- Imported questions show garbled text

## When not to use this skill
- Columns misalign (a delimiter issue)
- Rows truncate (a size issue)

## Tool compatibility
RFP questionnaire CSV imports.
Related area: CSV and Excel data import pipelines.
Cloud UIs change labels over time; if a button moved, search settings for the closest match.

## Before you start
- Sign in to the tool and keep one tab open so sessions stay clean
- Copy the exact error text and note the time it happened
- Set aside 15 to 20 minutes; most of these resolve in a single pass

## Quick diagnosis
Make sure this is the right skill before you invest the 15 minutes.
- If you are dealing with questionnaire CSV imports fail on encoding, start at step 1 below.
- If instead columns misalign (a delimiter issue), stop here; you need a different skill.
- If neither quite matches, compare your screen against the verbatim error block at the top; that block is exactly what this skill covers.

## Fix it in steps
### 1. Open the file in a text editor

```
Look for garbled characters around quotes, dashes, and accented letters.
```
Expected: mojibake marking the encoding problem.

### 2. Re-save as UTF-8 CSV

```
Explicitly export or save with UTF-8 encoding.
```
Expected: characters render correctly on reopen.

### 3. Re-import the questionnaire

```
Upload the cleaned file.
```
Expected: import completes without encoding errors.

### 4. Spot check special characters

```
Open a few imported questions with accents or symbols.
```
Expected: they display correctly.

## Confirm each step worked
Run through this checklist before moving on. If a check fails, redo that step instead of pushing ahead.
- Step 1 (open the file in a text editor): Expected: mojibake marking the encoding problem.
- Step 2 (re-save as utf-8 csv): Expected: characters render correctly on reopen.
- Step 3 (re-import the questionnaire): Expected: import completes without encoding errors.
- Step 4 (spot check special characters): Expected: they display correctly.

## Quick recap
1. Open the file in a text editor
2. Re-save as UTF-8 CSV
3. Re-import the questionnaire
4. Spot check special characters

## Still stuck?
Gather three things: the exact error text, the time it happened, and what changed just before it broke.
Check the vendor status page for an active incident. Then open a support ticket with those three things;
it cuts the back-and-forth in half. For agent runs, attach the last 50 lines of the agent log too,
since the loop or timeout signature in the log usually names the cause.

## Variant phrasings
### questionnaire csv encoding error
Same UTF-8 re-save fix. If this matches what you saw, the steps above apply as written.

### csv import failed encoding questionnaire
International question sets trigger this most. If this matches what you saw, the steps above apply as written.

## Why it happens
Questionnaire CSVs often come from systems that write legacy encodings. The importer reads UTF-8, so non-ASCII bytes misparse and the import aborts on the first bad row.

## Edge cases
- Smart quotes from Word are the number one offender
- Tab-delimited files misnamed as csv add confusion, fix both
- BOM headers are handled fine, leave them

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7Y5NJl-8ZMmk9NfLXV_0SQ