Proximus Emerging Business: Infonet, a Department Knowledge Base That Published in Real Time
How Infonet, a self-built phpBB knowledge base, let a fast-growing B2B telecom support team share what it knew faster than the corporate intranet could.
Proximus' Emerging Business unit was the B2B front line for new data products — corporate and SME connectivity, BlackBerry Enterprise Server, the early mobile-data stack — in a telecom market expanding faster than its documentation. As B2B Emerging Business Specialist I ran 1st-line B2B data support plus 2nd-line technical and VIP support, and built Infonet, a server-based phpBB knowledge base, so the department could publish procedures, findings and field tips in real time, rather than queueing them behind the corporate intranet team.
Context
Emerging Business lived up to its name: the products moved faster than anyone could document them. New data tariffs, APN configurations, BlackBerry Enterprise Server 4.0 rollouts, device quirks, corporate-customer edge cases — the knowledge that resolved a ticket was often three days old and living in one person's head or one person's mailbox.
The official channel for that knowledge was the corporate intranet, owned by a central team with its own backlog and publishing cadence. By the time a procedure cleared review and went live, the product had often moved on. The support floor was effectively running on tribal knowledge: ask the colleague who solved it last time, hope they're in today.
In a telecom environment growing this fast, that gap compounds. Every undocumented fix is re-discovered by the next agent, every VIP escalation re-litigates a problem someone already solved, and onboarding a new specialist means shadowing rather than reading. The department didn't need a better intranet — it needed a place it actually controlled.
Approach
I set up a phpBB instance on a department server — Infonet — and turned a forum engine into a structured knowledge base: categories per product line and support tier, sticky threads for canonical procedures, and ordinary threads for the running log of findings and workarounds. The tooling was deliberately boring — phpBB was free, well understood, and ran on hardware we already had — because the point was adoption, not architecture.
The editorial model was the real design decision. Anyone in the department could publish; the knowledge base trusted the support floor to write down what it had just learned, the moment it learned it. Canonical procedures were curated into stickies and kept current; the rest stayed as a searchable, timestamped conversation. That inverted the intranet model — instead of central review before publishing, the team published first and curated continuously.
Adoption was earned by making the knowledge base the fastest path to an answer. When a tricky BlackBerry Enterprise Server case or a corporate APN problem got solved, the resolution went into the base while it was fresh, and the next agent found it by searching instead of asking. Once the base was demonstrably faster than walking over to a colleague's desk, using it stopped being a policy and became a habit.
Key decisions
- Build the knowledge base on a department-controlled server instead of waiting on the central intranet team's publishing queue.
- Use phpBB — free, familiar, already-supported tooling — so the barrier to contributing was as low as posting a forum message.
- Let the whole department publish, not just a designated documentation owner: capture knowledge at the moment of resolution.
- Curate canonical procedures into sticky threads while keeping the raw findings log searchable and timestamped.
- Structure categories around product lines and support tiers so an agent's mental model matched the navigation.
- Make the base the fastest route to an answer, so adoption was driven by usefulness rather than mandate.
Results
- →The Emerging Business department gained a knowledge base it owned and could publish to in real time, with no dependency on the corporate intranet's review cadence.
- →Procedures, findings and field tips were captured at the moment of resolution instead of being lost to mailboxes and tribal memory.
- →Repeat B2B data and BlackBerry Enterprise Server issues were resolved by search rather than re-discovery, across 1st-line, 2nd-line and VIP support.
- →New specialists could onboard by reading the base rather than shadowing colleagues.
- →The department proved that the team closest to the problem is the right team to publish the fix — a model that held up as the B2B data business kept expanding.
Lessons learned
- ▸When documentation can't keep pace with the product, the bottleneck is usually the publishing model, not the writers. Move publishing to the people closest to the work.
- ▸Boring, well-understood tooling beats the perfect platform. phpBB worked because everyone could already use it on day one.
- ▸A knowledge base is adopted when it's the fastest way to an answer — not when it's mandated. Optimise for time-to-answer.
- ▸Real-time, peer-published knowledge with light continuous curation outperforms central review-then-publish in any fast-moving environment.
Is your team's hardest-won knowledge stuck behind a publishing queue?
I help organisations turn tribal knowledge into something the team can actually find — from real-time knowledge bases to AI-assisted retrieval over private corpora. 30-minute discovery call, no pitch.