It was early 2024, and enterprise managers were stuck in a frustrating loop with spreadsheets.

Picture this: you're a manager at a large corporate client like Cielo or Mercado Pago, responsible for onboarding 200+ employees into Woba's platform. You download a template, fill it out carefully, upload it, and... "Error: Name field must be split into first and last name."

Okay, go back. Split all 200 names manually. Upload again. "Error: Domain conflict detected." What domain? Which employee? The system doesn't say. You reach out to your account manager. They reach out to the data team. Hours fly by. The friction compounds. The tool that should enable autonomy was creating dependency.

This was the reality for managers trying to bulk-import their teams. And it was bleeding time from everyone involved: managers, KAMs (Key Account Managers), customer success, and our data team.

Why this problem mattered: operational cost and user autonomy

Woba served major corporate clients with hundreds or thousands of employees. When onboarding or updating member lists, bulk operations weren't a nice-to-have, they were essential. But our import flow was:

• Rigid: Required splitting full names into first/last manually

• Opaque: Showed generic errors without line numbers or context

• Unforgiving: No preview or review step before applying changes

• Dependent: Managers needed KAM intervention for most uploads

The operational cost was real. KAMs spent hours troubleshooting uploads. The data team ran manual scripts to fix broken imports. And managers? They lost confidence in the tool.

The bet: validation upfront, review before applying

Working with the Manager Squad, we proposed inverting the paradigm:

Instead of:

1. Upload file

2. Apply changes blindly

3. Discover errors after the fact

4. Manual rollback and support tickets

It would be:

1. Upload file

2. Validate automatically (check required fields, formats, business rules)

3. Show preview with errors highlighted (line, column, reason, suggestion)

4. Let manager fix or confirm before applying anything

5. Track the journey with events

We called this guided bulk import with validation.

What I designed: teaching business rules through the interface

I worked closely with Product, Engineering, CS/KAMs, and Data to design a flow that would:

1. Embed instructions in the UI, not in a hidden tab

Instructions embedded in the UI, not hidden in a tab: empty states explaining what to do, inline examples, contextual tips. The interface teaches the rule.

The old template had an "instructions" tab that nobody read. We removed it and moved all guidance into the interface itself:

• Empty states explaining what to do

• Inline examples ("e.g., john.doe@company.com")

• Contextual tips next to each field

• Downloadable template that just worked

The UI teaches the rule without requiring a manual.

2. Accept full names and normalize them

Instead of forcing managers to split "John Doe" into "John" + "Doe" for 200+ rows, we:

• Accepted full names in a single column

• Applied smart parsing on our end

• Let managers review the split in the preview

Trade-off: More parsing logic on our side, but dramatically less manual work for managers.

3. Validate everything before touching the database

In behind the scenes, we built automatic validation for:

• Email format (valid syntax, no duplicates)

• Required fields (name, group)

• Domain conflicts (company domain rules)

• Group existence (must match existing groups)

Each error came with:

• Line number

• Column affected

• Reason ("Invalid email format")

• Suggestion ("Example: user@company.com")

4. The review screen: WYSIWYG of consequences

Validation preview showing exactly what's wrong: row 47, column 'Email', invalid format. Actionable errors with suggestions, not just "failed".

Before applying any changes, we show a comprehensive summary:

• Total rows uploaded

• Valid items (ready to create/update)

• Invalid items (with errors to fix)

• Actions planned: X members to create, Y to update, Z to ignore

Managers see exactly what will happen before clicking confirm. No surprises.

This applied the instructive WYSIWYG principle I'd used in other projects: What You See Is What You Get.

Trade-offs that unlocked the feature

Accept full names: convenience over rigid structure

We could've kept forcing first/last name splits. But the user's mental model is "I have a name column." So we met them there.

Trade-off: More parsing logic on our side, but it removed the #1 friction point.

Preview step: slightly longer flow for quality assurance

WYSIWYG summary before applying: X members to create, Y to update, Z to ignore. See exactly what will happen before clicking confirm.

Adding a review step means one more click. But it prevents:

• Accidental overwrites

• Incorrect group assignments

• Bulk errors that require manual cleanup

The cost of getting it wrong once outweighed the cost of one extra screen.

What changed in practice

The qualitative impact was immediate:

• Manager autonomy: Less dependency on KAMs and data team for bulk operations. Managers reported feeling confident uploading member lists.

• Data quality: Validation + review meant cleaner data entering the system. Fewer cleanup scripts. Better foundation for reports.

• Reduced support volume: Fewer "my import didn't work" tickets. KAMs spent less time troubleshooting uploads.

But here's the honest part: we didn't have comprehensive quantitative metrics in the first version.

We knew from Amplitude that:

• 64 unique users started the import flow (first 6 months after release).

• 21 unique users completed it.

• 32.8% completion rate.

The squad was redirected to other priorities before full instrumentation. So the precise quantitative impact remained an opportunity.

What I learned: design for the least confident user

1. Bulk operations need preview steps. When users are touching dozens or hundreds of records at once, they need to see consequences before committing. One extra click is worth the confidence.

2. Error messages are product design. "Invalid field" is useless. "Row 47, Column 'Email': Invalid format. Example: user@company.com" is actionable.

3. Embed instructions in the UI. Hidden documentation doesn't get read. Contextual guidance does.

4. Full instrumentation takes time. We didn't measure everything we wanted in V1. That's normal. What matters is documenting what's pending and having a plan to return.

5. Design for the scared user. Corporate managers doing bulk uploads are terrified of breaking things. The UI should make them feel safe, not anxious.

The foundation was laid

Guided member import wasn't perfect. We didn't have all the metrics I wanted. But it fundamentally changed how managers interact with bulk operations.

It transformed a chaotic, error-prone process into a predictable, safe, and autonomous flow. And it established patterns—validation, preview, instructive UI—that would influence other features at Woba.

It was a step toward treating managers as empowered users, not helpless ticket generators.