Designing ConnectWise: How We Solved Complex Operations and Event Engagement in One Ecosystem

Two problems in one building. IFTA had a problem that looked like two problems.

On one side of the organization: a support operations team drowning in repetitive member inquiries, email chains that stretched across days, knowledge scattered across documents nobody maintained, and manual workflows that consumed hours of staff time on tasks that should have been automated years ago.

On the other side: an events team running conferences where thousands of attendees showed up, wandered exhibit halls, attended sessions, exchanged a few business cards, and left — without having found the three people who could have changed their careers. The networking that justified the ticket price was left almost entirely to chance.

Support and events. Communication and connection. Two operational challenges in the same organization, both caused by the same underlying failure: people who needed to reach each other couldn't.

Members couldn't reach support efficiently. Support couldn't reach answers quickly. Attendees couldn't reach relevant peers effectively. Organizers couldn't reach attendees with real-time updates.

Every problem was a communication problem.

We designed two products to solve them — and packaged them into one ecosystem.

"IFTA didn't need two apps. They needed a communication infrastructure — one that worked for daily operations and annual conferences equally."

The ecosystem

These weren't two unrelated products that happened to share a client. They were two expressions of the same organizational need — helping IFTA connect with its members and helping members connect with each other.

The support platform handled the day-to-day: member inquiries, knowledge management, workflow automation, task coordination. The event platform handled the episodic: conferences, networking, meeting scheduling, session discovery.

Same brand. Same design language. Same audience (IFTA members interacted with both). Different contexts, different workflows, different interaction models — but one coherent ecosystem.

Product 01: ConnectWise AI

The support problem nobody admits

Here's what IFTA's support operations actually looked like before ConnectWise AI:

A member sends an email asking about membership renewal. It lands in a shared inbox. Someone reads it, searches through scattered documents for the answer, types a response, and sends it. Twenty minutes for a question that's been asked — and answered — hundreds of times.

Meanwhile, another email arrives asking the same question. Different staff member. Same twenty-minute process. Same answer.

Multiply this by hundreds of inquiries per week. Add the emails that get buried, the follow-ups that get forgotten, the tickets that nobody owns, and the knowledge that exists only in the heads of staff members who've been there long enough to remember the answers.

The result: a support team spending most of its time on work that shouldn't require a human being, while the complex, genuinely difficult member issues — the ones that need human judgment — waited in queue behind routine questions.

"The support team wasn't struggling because they lacked skill. They were struggling because 70% of their work was answering the same questions a well-organized AI could handle in seconds."

Building the AI's brain first

Most AI product stories start with the interface — the chatbot, the smart inbox, the automation dashboard.

We started with the knowledge base.

This was a deliberate sequencing decision, and it shaped everything that came after. An AI support system is only as good as the knowledge it draws from. If the knowledge base is incomplete, disorganized, or outdated, the AI generates unreliable responses — and unreliable AI is worse than no AI at all, because people stop trusting it.

The knowledge base module allowed support teams to:

• Create and manage FAQs — the most common questions, with verified answers

• Organize knowledge articles — structured, categorized, searchable content

• Configure categories and hierarchies — information architecture for the AI's understanding

• Maintain training content — material that improved AI response quality over time

• Define AI workflow triggers — which knowledge feeds which AI behavior

The knowledge base wasn't a documentation tool. It was the foundation layer — the structured intelligence that powered every AI capability in the platform.

We designed it to be maintainable by support teams, not engineers. Adding a new FAQ, updating an article, reorganizing categories — these were daily operational tasks, not technical projects. The easier it was to maintain the knowledge base, the smarter the AI would remain over time.

Smart email: the feature that earned trust

The AI-powered email workspace became the strongest differentiator in the support platform — and the feature that required the most careful design.

Here's what it did:

Inbox management — all member communications in one place, categorized, searchable, and prioritized.

AI-generated responses — for incoming emails, the system drafted responses based on the knowledge base. Not generic templates. Contextual, specific drafts that addressed the actual question.

Response quality evaluation — this was crucial. The AI didn't just generate responses and send them. It generated drafts and evaluated their quality. Was the response complete? Did it address the member's question? Was the tone appropriate? Quality scores gave support staff confidence before approving.

Customer context panel — when reviewing an email, staff could see the member's history: previous inquiries, membership status, recent interactions, open tasks. Context that made responses more personal and more accurate.

Task creation from conversations — if an email required follow-up action, staff could create a task directly from the conversation. The task inherited context — who requested it, what it was about, when it was due.

The trust architecture

Designing AI into a support workflow introduced a fundamental tension:

If the AI sends responses automatically, it's fast but risky. A wrong answer damages member trust and organizational credibility.

If every AI response requires manual approval, it's safe but slow. And the whole point of AI was to reduce the time spent on routine responses.

We designed a graduated trust model:

High-confidence responses — when the AI found a clear match in the knowledge base and the quality score was above a threshold, the draft was pre-approved for review. Support staff could glance, confirm, and send in seconds.

Medium-confidence responses — when the AI was less certain, drafts were flagged for more careful review. The quality evaluation highlighted which parts of the response might need editing.

Low-confidence or novel questions — when the AI didn't have sufficient knowledge base coverage, it didn't attempt a draft. Instead, it surfaced relevant articles and context, letting the human write from scratch with better information.

The system was honest about what it knew and what it didn't. That honesty — surfaced through quality scores and confidence indicators — was what made support staff trust it over time.

"We didn't design the AI to replace support staff. We designed it to handle the work that was stealing their time — so they could focus on the members who actually needed a human."

The dashboard as command center

The ConnectWise AI dashboard was designed to answer one question: "What needs my attention right now?"

At a glance, support managers could see:

• Task status — what's open, what's in progress, what's overdue

• Workflow activity — automated processes running, completed, or stalled

• Incoming emails — volume, priority, AI-handled vs. human-required

• Chatbot conversations — active sessions, resolved queries, escalations

• Team notifications — assignments, updates, internal communication

• Operational KPIs — response times, resolution rates, member satisfaction

The dashboard wasn't a passive display. Every metric was a pathway — clicking any card navigated to the relevant workflow. The dashboard was less "here's what's happening" and more "here's what you should do next."

Workflow automation

Beyond email and chat, the platform included a visual workflow manager for automating repetitive support operations:

• Ticket categorization — incoming inquiries automatically classified by type

• Response generation triggers — specific question types triggering AI draft responses

• Approval chains — responses requiring manager review before sending

• Internal routing — complex inquiries directed to the right team member

• Escalation rules — unanswered inquiries escalating based on time and priority

The workflow manager made automation visible. Support managers could see exactly how automated processes worked, modify them without engineering help, and understand why specific actions were triggered.

Visibility was essential. Automation that operates invisibly creates anxiety — "what is the system doing with our member communications?" Automation that's visible and configurable creates confidence.

Task management

The task management module bridged the gap between communication and action.

Support conversations often generate work that extends beyond the conversation itself: "We need to update this member's account." "Someone should follow up on this billing issue." "This complaint needs to be escalated to the operations team."

Tasks could be:

• Created from email conversations (inheriting context)

• Assigned to specific team members

• Tracked through completion stages

• Linked back to the original member inquiry

• Prioritized and deadline-managed

This closed the loop that most support tools leave open. A conversation isn't resolved when the email is sent — it's resolved when the underlying issue is fixed. Task management ensured that follow-through was tracked, not just communication.

Product 02: ConnectWise Event

The networking lottery

Here's what typically happens at a professional conference:

Two thousand attendees register. They arrive at a venue. They check in at a registration desk. They receive a badge and a printed agenda. They attend sessions based on titles that sounded interesting three months ago when they registered. During coffee breaks, they make small talk with whoever happens to be standing nearby. They exchange business cards with people they may or may not remember. They leave.

Out of two thousand attendees, a typical person meets maybe fifteen. Of those fifteen, maybe three are professionally relevant. Of those three, maybe one leads to a meaningful conversation.

The networking that justifies the ticket price — the connection that could become a partnership, a job offer, a collaboration, a mentor — is left almost entirely to chance.

That's not networking. That's a lottery.

ConnectWise Event was designed to change the odds.

"Conferences put thousands of relevant people in the same building and then provided absolutely no mechanism for helping them find each other. ConnectWise Event turned accidental encounters into intentional connections."

Starting before the event starts

The engagement didn't begin at check-in. It began at onboarding — days or weeks before the conference.

Users joining the platform completed a structured profile:

• Verify event participation — connect their registration to the platform

• Complete professional profiles — role, organization, expertise, interests

• Select interest areas — topics, industries, specializations

• Define networking preferences — what kind of connections they're looking for (mentors, partners, vendors, peers)

This information wasn't just profile data. It was the recommendation engine's fuel. Every interest selected, every preference defined, every expertise listed fed into the system's ability to surface meaningful connections.

By the time the conference started, the platform already knew who should meet whom.

Attendee discovery

The Explore experience was the heart of the event platform — the feature that transformed a conference from a physical space into a navigable network of people.

Users could discover relevant attendees through:

• Search — find specific people by name, organization, or role

• Interest filters — show attendees who share specific professional interests

• Industry tags — connect with people in the same or adjacent industries

• Personalized recommendations — AI-powered suggestions based on profile data and networking preferences

The recommendations weren't random. They were structured around the question: "Who at this event is most likely to be valuable to this specific person?"

A product manager looking for technical partners saw different recommendations than a sales director looking for prospects. A researcher looking for collaborators saw different suggestions than a CEO looking for vendors.

The algorithm considered mutual interests, complementary expertise, organizational relevance, and networking intent. Two people who both said they were looking for "potential collaborators in sustainable packaging" would see each other prominently.

Connection management

Discovering someone relevant was step one. Connecting with them was step two.

The connection management system mirrored professional networking patterns:

• Send connection requests — with optional context ("I'm interested in discussing your work on...")

• Accept or decline requests — with visibility into who the person is and why they're reaching out

• View networking history — past connections, meeting history, conversation threads

• Manage professional relationships — connections persisted beyond individual events

This wasn't LinkedIn inside a conference app. It was purpose-built for event contexts — shorter-term, more specific, more action-oriented. You weren't building a lifelong professional network. You were finding the five people you needed to meet this week and making sure it happened.

Meeting scheduling

The meeting scheduling system was the operational core of the networking experience — the mechanism that turned "I want to meet this person" into "We're meeting at 2 PM at Table 7."

Attendees could:

• Request meetings — choose a connection and propose a time

• Select time slots — from available shared windows

• Choose meeting type — physical (at the venue) or virtual (video call)

• Manage confirmations — accept, decline, or reschedule

• Join virtual sessions — for hybrid events or follow-up conversations

The scheduling system handled the coordination that makes event networking fail in practice. It's one thing to exchange cards with someone interesting. It's another to actually sit down for a fifteen-minute conversation. The platform managed the logistics that usually prevent good intentions from becoming good meetings.

"The hardest part of event networking isn't finding interesting people. It's finding thirty minutes when both of you are free and a quiet place to talk. The scheduling system solved both."

Event agenda

The agenda experience provided a comprehensive view of the event program:

• Multi-day navigation — events spanning multiple days with clear day-by-day structure

• Session schedules — detailed timing, descriptions, and speaker information

• Speaker profiles — background, expertise, and session links

• Venue details — room locations, floor maps, and wayfinding

• RSVP functionality — express interest in sessions and receive reminders

• Track navigation — filter by content track (technical, business, industry-specific)

The agenda wasn't a static schedule. It was a planning tool — helping attendees build their personal event experience before arriving, and adjust it in real time as sessions changed, speakers updated, or new opportunities emerged.

Real-time announcements

Events are operationally unpredictable. Rooms change. Sessions run late. Speakers cancel. Weather affects outdoor activities. WiFi goes down.

The announcements system provided real-time communication:

• Venue changes and room updates

• Speaker additions or cancellations

• Schedule adjustments

• Event reminders

• Operational notifications ("The west parking lot is full")

For organizers, this replaced the PA system, the printed signs taped to doors, and the volunteers stationed at intersections directing confused attendees. For members, it meant never missing a change that affected their schedule.

Credits-based networking

This was one of the most interesting business design decisions in the project.

Networking actions — sending connection requests, scheduling meetings, accessing premium recommendations — consumed credits. Users received a baseline allocation and could acquire more through engagement, upgrades, or organizational allotments.

The credits system served multiple purposes:

Quality control. When connections cost something, people are more intentional about who they reach out to. This reduced spam-like mass connection requests and increased the relevance of networking interactions.

Engagement incentive. Completing profile information, attending sessions, and responding to messages earned credits — encouraging active participation rather than passive attendance.

Monetization. For the organization, credits created a revenue model that aligned with the platform's value proposition. Users paid for the ability to network more — which is exactly the value the platform delivered.

The design challenge: making credits feel like a feature, not a restriction. We designed the credit system with full transparency — clear balances, understandable costs per action, and visible pathways to earn more. Users never felt ambushed by a paywall. They understood the economy before they participated in it.

Advertising management

The platform included a built-in advertising system — a feature that served event organizers rather than attendees.

Organizers could manage banner placements across multiple surfaces within the application:

• Home screen banners

• Agenda interstitials

• Attendee discovery sponsorships

• Session-level advertisements

This wasn't just a revenue feature. It was a sponsor integration layer — giving event sponsors visibility within the platform where attendees were most engaged. Sponsors appearing contextually (a cybersecurity company's banner in the cybersecurity track agenda) performed better than generic placements, and the system supported that targeting.

Designing two products simultaneously

Most projects involve designing one product for one audience. ConnectWise required designing two products for multiple audiences at the same time.

Different products, different rhythms

ConnectWise AI was a daily-use tool. Support teams lived in it eight hours a day. Every interaction needed to be efficient, every workflow optimized for throughput. The design language was dense, data-rich, and action-oriented. Dashboards, tables, inboxes, task lists.

ConnectWise Event was a periodic, high-intensity tool. Attendees used it intensely for three to five days during a conference, and barely at all between events. The design language was more exploratory, more social, and more visual. Discovery feeds, profile cards, agenda browsing, meeting coordination.

The design system had to support both rhythms — the operational cadence of daily support work and the social cadence of event networking — without making either feel forced.

Different users, shared trust

Support administrators needed to trust that the AI was generating accurate responses from reliable knowledge. Event attendees needed to trust that the platform was recommending genuinely relevant connections, not just showing random profiles.

Both trust requirements were addressed through the same design principle: transparency.

In ConnectWise AI, trust came from quality scores, source attribution (which knowledge base article powered this response?), and human review controls.

In ConnectWise Event, trust came from visible recommendation logic (why is this person being suggested?), mutual interest indicators, and credentialed profiles.

Different contexts. Same principle. Show the reasoning, not just the result.

Shared design foundations

Despite their differences, both products shared:

• Typography and color — consistent visual identity

• Component patterns — cards, lists, status indicators, action buttons

• Navigation principles — consistent information hierarchy

• Interaction patterns — consistent feedback, loading states, and transitions

• Design tokens — spacing, border radius, elevation, shadow patterns

A member who used ConnectWise AI for a support inquiry and ConnectWise Event for conference networking would feel — without articulating it — that both products came from the same world.

What was harder than expected

AI confidence is a UX problem, not a tech problem.

The AI could generate responses. Making support staff believe in those responses was an entirely separate challenge. We learned that confidence isn't about accuracy percentages — it's about showing the work. When staff could see which knowledge base article powered a response, they could evaluate its relevance themselves. When they could see a quality score with specific dimensions (completeness, relevance, tone), they could trust their judgment about whether to approve. Confidence was designed, not computed.

Event networking has a cold start problem.

The recommendation engine needed data to generate good recommendations. But at the start of an event, most attendees hadn't completed their profiles or defined their preferences. Early recommendations were weaker than later ones — which meant first impressions of the networking feature were the worst ones.

We addressed this through aggressive onboarding — making profile completion and interest selection feel essential, not optional. But the tension between "collect enough data for good recommendations" and "don't make onboarding feel like a survey" was constant.

Credits were controversial in user testing.

Some users loved the credits system — it made networking feel intentional and prevented spam. Others felt restricted — "I paid for this conference, why do I have to pay again to connect with people?"

The design solution was generous defaults and transparent earning mechanisms. Baseline credits were sufficient for meaningful networking. Power users who wanted to connect with everyone could earn or purchase more. But the initial emotional reaction to any form of metering required careful onboarding that explained the why before the what.

Two products meant two release cycles, two feedback loops, two sets of priorities.

Designing two products simultaneously meant managing two timelines, two sets of stakeholder feedback, and two competing priority lists. A breakthrough in the event platform's discovery algorithm didn't help the support platform's email workflow — and vice versa.

We managed this by treating the engagement as one project with two workstreams — shared design reviews, unified design system updates, and cross-product consistency checks. But the cognitive load of context-switching between "how should AI draft emails?" and "how should attendees discover each other?" was significant.

Reflection

ConnectWise was a project about communication in all its forms — AI-mediated support conversations, human-initiated networking connections, real-time operational announcements, structured meeting coordination, and knowledge sharing.

A few things this project taught us:

AI products are trust products.

The AI in ConnectWise AI wasn't difficult to design functionally. It was difficult to design trustworthily. Every AI-generated response needed to carry enough evidence — source attribution, quality evaluation, confidence level — for a human to make an informed decision about approving it. The AI's job wasn't to be right. It was to be verifiably right.

Event platforms fail when they optimize for content instead of connections.

Most event apps are digital programs — schedules, maps, session descriptions. ConnectWise Event succeeded because it was designed around people, not sessions. The agenda was important. The speakers were important. But the feature that made the platform worth opening was: "Here are three people you should meet today, and here's why."

Ecosystems need shared principles, not just shared components.

ConnectWise AI and ConnectWise Event shared a design system. But the deeper unification was in principles: transparency builds trust, communication should reduce friction not add it, and users should always understand why the system is doing what it's doing. Those principles held across AI-drafted emails and AI-recommended connections equally.

Credits-based systems need emotional design, not just economic design.

The credits model was economically sound. But the emotional experience of metering — of being told you "can't" do something because you've run out of credits — required careful design. Generous defaults, visible earning mechanisms, and transparent pricing turned what could have felt restrictive into something that felt intentional. The system didn't limit networking. It focused networking.

What ConnectWise became

ConnectWise became something that IFTA hadn't had before — a digital infrastructure for its two most important activities: supporting members and connecting them with each other.

The AI platform transformed support operations from reactive email chains into a structured, intelligent system that handled routine inquiries automatically and surfaced the complex ones that needed human judgment.

The event platform transformed conferences from networking lotteries into intentional connection experiences where the odds of meeting someone relevant went from chance to certainty.

Two products. One ecosystem. One principle:

People who need to reach each other should be able to.