How Aloware Built AloPedia: A Company-Wide Knowledge Agent That Lives in Slack

Originally published on the Aloware blog. Republished here with permission.

Aloware is an AI-powered contact center platform used by more than 1,000 B2B sales and support teams. As they scaled, the tool stack grew the way it always does: Confluence for docs, Jira for engineering, HubSpot for CRM, Chargebee for billing, Zoom for calls, Google Calendar for scheduling. Eight systems, each holding a different piece of how the company actually works.

The problem wasn't access. Most employees could log into most systems. The problem was the friction of doing it forty times a day — knowing which system to open, remembering where the record lived, running the lookup, closing the tab, opening the next one.

The information problem

When Aloware looked at how employees spent their time, the pattern was plain: someone needed to know something and spent twenty minutes tracking it down. Or they pinged a colleague, who also spent twenty minutes. Or they gave up.

New hires felt it hardest. A new sales rep needed weeks just to learn which system held what — before they could do anything useful. Experienced employees hit the same wall on unfamiliar queries, cross-department questions, anything that lived outside their usual tabs.

The patterns that kept showing up:

• Lookups requiring three or four apps to answer one question
• Teams pinging colleagues about things already documented somewhere
• Billing and CRM questions needing two systems for a complete answer
• Leadership meetings summarized in Zoom transcripts no one went back to read

Aloware's leadership set a goal: one place where any employee could ask anything and get an answer without leaving Slack. Not a search index. Not a filing system. Something that could actually answer.

This is what we've called the Actions Gap — the space between information existing somewhere and being usable by the person who needs it. The information was there. Getting to it was the work.

What they built

Aloware built AloPedia on Runbear — a company-wide knowledge agent deployed across five Slack channels, with DMs for sensitive queries.

Eight systems connected in a single deployment:

1. Confluence — internal docs, policies, process guides, product docs
2. HubSpot — live CRM records: deals, contacts, accounts, pipeline stages
3. Jira — engineering tickets, bug reports, feature requests, project status
4. Chargebee — subscription and billing records
5. Zoom — call transcripts and meeting recordings
6. Google Calendar — meeting history and scheduling context
7. Marketing artifacts — brand assets, campaign materials, product collateral
8. Aloware's own platform — internal product data

No custom code. Runbear's native connectors handled the integrations. Concept to company-wide deployment: a few weeks.

AloPedia went live in five channels — #Spice, #Marketing, #CX, #Tech-support, and #Product. Anything involving personal or sensitive account data went through DMs.

What employees actually ask it

"What's the status of the Acme Corp deal?"

AloPedia pulls the live HubSpot record and returns the deal stage, owner, amount, and last activity. No one opens HubSpot.

"What is our refund policy for annual plans?"

It searches Confluence, finds the policy, returns the exact text. The document stays in Confluence. The answer comes to the employee.

"Show me open tickets for the mobile app bug."

It queries Jira and returns the current list — status, priority, assignee — for each open ticket.

"What did we cover in Tuesday's leadership sync?"

It pulls the Zoom transcript and returns a summary: topics, decisions, follow-ups.

"Generate a billing report for this account."

It combines data from HubSpot and Chargebee and returns a structured report. That used to mean opening two systems, cross-referencing records, and assembling the summary by hand.

Each of these is a question asked in plain English, inside Slack, with a complete answer and no context switch. That's the pattern in our post on why ops teams don't need to be a bottleneck. The complexity of the question usually isn't the problem — the number of steps to answer it is.

Results

New hire ramp time is harder to put in a table. When a new employee can ask AloPedia where to find anything and get an accurate answer right away, the weeks spent learning the system map shrink considerably. They skip the orientation and start asking.

As Aloware's leadership put it:

"We wanted every employee to have access to a teammate that knows everything about how our company works. AloPedia does exactly that — it lives where we work and makes everyone faster."

What they got right

Permissions follow the user, not a shared account. AloPedia uses each employee's own OAuth credentials. A sales rep querying HubSpot sees their own pipeline. A director sees the whole team. A support rep in Jira sees what they have access to. The one-time setup is about thirty seconds. People trusted it quickly because it behaved the way they expected — their access rules, not a shared account with everything unlocked.

Confluence stayed the source of truth. Docs didn't move. AloPedia didn't ask anyone to maintain a new knowledge base or duplicate things elsewhere. It made what was already in Confluence available the moment someone asked. Teams kept their existing writing and review workflows. The agent handled retrieval.

Slack was the interface, not an addition to it. No new app, no new login, no behavior change. The interface is a Slack message — same as everything else. This is the premise behind the four pillars of inbox intelligence: tools that fit into what people already do tend to get used. Tools that require a new workflow tend not to.

No engineering involved. Eight integrations, five channels, permission handling — all configured through Runbear's native connectors. Aloware's ops team built and shipped it without filing a single ticket.

The tools that actually get used are the ones that slot into existing workflows. Employees didn't change how they worked. They just stopped opening four tabs to answer one question. This is also what the three types of ops requests gets at: AloPedia handles straight retrieval and multi-source synthesis without anyone in the loop — freeing people for questions that actually need a human.

How it works on Runbear

Runbear is a Slack-native AI platform that connects to your tools and lets you build agents inside your existing workflows. For Aloware, that meant linking eight enterprise systems to Slack and making the combined knowledge of all of them available through a message.

Setup is non-technical by design. Native connectors handle authentication, data access, and permissions. The agent improves over time as it learns the specific language and context of the team using it.

Employees stopped navigating between systems and started asking. By the time someone finishes typing, the answer is already there.

If your team is losing hours each week moving between systems to find things that already exist somewhere, this pattern is worth a look. The knowledge is there. The question is whether it's reachable.

Learn more about building agents on Runbear at runbear.io.