Redesigning Enterprise Onboarding at Bettermode

Overview

Enterprise onboarding took 2–3 weeks. We focused on reaching a reviewable community preview with fewer handoffs.

Bettermode helps companies build branded online communities. Enterprise onboarding took 2–3 weeks and relied on repeated handoffs between the client, Customer Experience (CX), and design. Requirements were documented manually, clarified with the client, and interpreted again during the community build.

I redesigned this workflow with CX and engineering. The new approach used meeting transcripts and context notes to draft structured requirements, let CX review and edit them, and generated a community preview through the Bettermode API. Client review and approval remained part of the process.

Walkthrough of the onboarding interface, from project setup to requirements review. Dashboard records illustrate the interface; the measured beta and service outcomes are described separately below.

My role and the team's responsibilities

I led research, workflow and interface design, functional prototyping, and design QA. I worked with Jacob Harris, Customer Experience Director; Disha Sareen, Customer Success Manager; and Ali Aghamiri, Solution Engineer. Ali built the API-based community generation step. I defined the review experience and the visual quality required before sharing a preview with a client.

The delivery phase ran from August 2025 to January 2026. Earlier self-service, template, and design-service approaches informed the scope of this work.

What earlier onboarding approaches revealed

Self-service needed a starting point. A review of more than 200 new signups over six months found that 31% of enterprise customers completed basic setup in their first seven days. In recordings from 15 enterprise clients, repeated layout changes suggested that customers could operate the editor but struggled to decide how to structure their community.

Evidence from the self-service onboarding review.

Templates helped some customers, but enterprise needs varied. The library of 12 templates gave smaller communities a starting structure. Interviews with eight enterprise clients showed that brand requirements, navigation, audience segments, and content architecture often required more extensive changes.

Community templates and enterprise customization needs.

The design service added another handoff. CX held discovery calls and wrote briefs for designers to build from. This offered tailored communities, but incomplete briefs led to clarification and rework before design could begin.

The enterprise design service workflow.

Auditing the CX-to-design handoff

I reviewed 22 briefs submitted over two months and interviewed four CX specialists. Five briefs were missing brand details, eight used inconsistent section structures, and nine needed clarification before design could start. Average documentation time was 68 minutes per client.

CX specialists described spending 20–35 minutes revisiting recordings or notes after a call. Two had made personal Notion templates. The information was often available, but reconstructing and structuring it consumed time before the build could begin.

Choosing a transcript-based workflow

I explored three directions: improve the brief template, train CX on design requirements, or extract structured requirements from transcripts and use them to configure a community. A three-week template pilot with two specialists improved some structured fields, but qualitative requirements remained inconsistent. Training also left the documentation workload in place.

The transcript-based direction required more engineering work, so I tested extraction before committing to the interface. In about four days, I built a functional prototype using Cursor that processed transcripts into structured text.

Comparing directions for the onboarding workflow.

Early functional prototype used to test transcript-to-requirements extraction before designing the full onboarding interface.

Validation changed the review model

The CX Director reviewed outputs from eight anonymized transcripts alongside the manual briefs from the same calls, without knowing their source. The generated outputs were rated comparable or better for completeness in six cases. In two, they missed implied preferences that the CX specialist understood from the relationship and conversation.

That finding shaped two design decisions: CX needed a context-notes field before extraction, and generated requirements needed to remain editable. The review step preserved information that a transcript alone could not capture.

Transcript extraction validation and review findings.

Designing the handoffs and approval steps

The workflow connected three audiences. CX uploaded a transcript, added context, reviewed requirements, and triggered generation. Design reviewed the resulting community and flagged exceptions. The client received a preview, requested changes, and approved the direction before the final build.

User flows connecting enterprise clients, CX specialists, and the design team.

Review checkpoints across CX, design, and client approval. Summary diagram of the workflow described above.

Generation handled the first draft. CX, design, and the client retained responsibility for review and approval.

With engineering, I defined input, processing, and output layers. Extraction combined structured values such as colors and feature settings with inferred requirements such as tone and audience goals. A vocabulary mapping layer addressed differences between client terms and Bettermode's internal taxonomy.

Input, processing, and output architecture.

A review dashboard organized around eight sections

The interface grouped requirements into brand identity, navigation, CMS configuration, space and page architecture, member profile fields, feature configuration, competitor references, and explicitly rejected directions. CX could inspect and edit the information before it was used to configure a community. A captured requirement did not imply that the API could configure it: advanced member fields and other unsupported settings still needed manual implementation.

Competitor references and rejected directions came from CX and design feedback. They helped reviewers retain context that would otherwise be lost in a list of requested features. We also aligned internal labels with the terms CX used in client conversations.

Interface design for the requirements review dashboard.

Working through implementation with engineering

I documented field behavior, confidence indicators, required review conditions, and how vocabulary mismatches should appear. During the six-week build, I reviewed the live interface with engineering each week and resolved some editing interactions directly in the build.

One QA finding changed the confidence display: inferred fields were all appearing amber regardless of their confidence score. That made the warnings less useful. We corrected the behavior so the review interface could distinguish fields that needed attention. The indicator supported review; CX still needed to inspect and edit inferred requirements.

Implementation decisions and design QA.

Testing the workflow in three stages

Internal CX sessions: Four specialists each processed three anonymized transcripts while I observed and collected think-aloud feedback. Recorded completeness on structured sections was 94%, compared with 64% for manual briefs. This assessed structured information coverage, rather than correctness of every inferred requirement. Average review time was 14 minutes in these sessions; it was distinct from the later service documentation-time measure.

Design review: Three designers assessed six generated communities for brand accuracy, structural correctness, and configuration completeness. Average ratings were 4.1, 4.4, and 3.8 out of five respectively. Missing configuration was the weakest area, so we added standard enterprise defaults unless the client had explicitly excluded them.

Client beta: Five enterprise clients used the workflow. Time from discovery call to preview was 18–26 hours, compared with 8–14 days in the manual service. This measured preview delivery, not the full onboarding process.

Testing stages and findings from the onboarding rollout.

Client walkthroughs changed the approval experience

I observed three beta clients reviewing their previews remotely. Two were unsure where to request revisions, so we added a persistent Request changes action. All three wanted to share the preview with colleagues, which supported keeping the link accessible without login.

One client hesitated because Approve sounded like immediate publication. We changed the label to Approve for final build and added a confirmation step. The interface needed to communicate what approval authorized, as well as what the client should do next.

A post-launch failure exposed missing context

A client asked for a clean, minimal community, meaning simpler than their existing internal wiki. The generated preview interpreted this as a sparse design and omitted features the client expected.

We added an Ambiguities and open questions field to the context step so CX could record uncertainty before processing. The failure showed why inferred requirements still needed human interpretation and review.

Reported service outcomes

Full onboarding: Following launch, the project reported completion in under three days, compared with 2–3 weeks previously. This was the later service measure, separate from the five-client beta’s 18–26-hour time to preview.

CX documentation: Time fell from 68 to 17 minutes per client. The 14-minute figure in the internal sessions measured requirements review, a different task and testing stage.

Activation: First-14-day activation rose from 54% to 73%, a 19 percentage-point increase. The earlier 31% basic-setup figure described a separate historical analysis and should not be used as this result’s baseline.

Service throughput and rework: Monthly capacity rose from approximately eight to 32 clients. The rate of briefs requiring clarification fell from 41% to 18%. Capacity covered the service as a whole, rather than documentation alone.

These are reported post-launch service outcomes. The internal tests, client beta, and service reporting used different tasks and populations; their figures are presented separately rather than combined into one experiment.

Limits and what I would change

Some enterprise configurations, including custom domains, SSO, and advanced member fields, still required manual work because the API did not cover every option. The workflow reduced routine production work while keeping review and exception handling with CX, design, and engineering.

I would test client vocabulary earlier, include ambiguity capture in the first prototype, and agree API coverage before promising a complete configuration path. The project showed where automation saved time and where human context remained necessary.

API coverage set the limits of automation. Custom domains, SSO, and advanced member fields still required manual work.