TL;DR
- Problem: Support was scattered, untracked, and overwhelming for ops and devs.
- Goal: Centralize support requests and empower users through a searchable FAQ.
- Solution: Built an internal ticketing system + knowledge base from scratch.
- Results: +480% usage growth, -50% redundant tickets, validated as internal standard.
The problem
With fast scaling came chaos:
- Support requests were sent by SMS, WhatsApp, calls, or ad hoc Slack messages.
- No traceability, no prioritization, no ownership.
- Engineering and Ops teams were constantly interrupted, hurting delivery.
I witnessed this firsthand while co-working from the warehouse. One ops lead had 4 conversations going at once to solve the same issue, none documented.
We needed a centralized, intuitive, no-training-required system to streamline support and surface recurring problems.
Discovery & research
Observations
- Co-worked with warehouse and ops teams for 2 weeks
- Noted entry points for support: WhatsApp, SMS, in-person, Slack, email…
Interviews
- 5 Ops leads
- 4 warehouse agents
- 2 engineering team leads
Pain points
Ops Teams
"I answer the same question 10 times a week."
- No single source of truth
- Time wasted in repeated explanations
Engineering
"We lose time triaging noise from real bugs."
- Tickets came with no context
- No priority indication
Warehouse agents
"I just ask whoever is available."
- Lack of digital process
- Often resorted to WhatsApp/voice messages
Design Strategy
How might we…
How might we...
Build a low-tech, easy-to-use system for all teams?
How might we...
Reduce noise by empowering users to self-solve?
How might we...
Create structure without friction?
Design Principles
- Zero training required
- Smart routing over smart tools
- Search-first, ticket-second logic
- Mobile-first access for field agents
System Overview
Knowledge Base
- Searchable by keyword
- Structured articles organized by product/team
- Contains step-by-step guides, screenshots, and contextual explanations
- Continuously updated based on support trends and recurring issues
FAQ Section
- Quick answers to common and repetitive questions
- Designed to reduce low-complexity tickets
- Auto-suggested during ticket submission
- Derived from top-used knowledge base content




Ticketing System
- Form auto-suggests FAQ entries before submission
- Customizable issue categories
- Status tracking: pending, solved, escalated
- Admin backend for assignment and comments
- Kept tech simple to launch fast and evolve gradually
- Used plugins + custom dev for smart behaviors
- Mobile-first UI for warehouse agents




Adoption Strategy
- Soft launch with ops team
- Weekly updates based on usage patterns
- Embedded tracking to detect common keywords and trends
- Created onboarding doc + 2-min explainer video
- Integrated into company-wide onboarding for new hires
Impact & Results
Quantitative results
- +480% usage growth over 12 months
- -50% in repetitive tickets thanks to FAQ-first logic
- Became official internal support tool adopted org-wide
- Led to backlog clean-up and better engineering focus
Qualitative wins
- Improved trust between ops and product/dev teams
- Surfaced deeper recurring issues that were previously hidden
- Reduced reliance on “heroes” to answer everything



Learnings & Reflection
“Designing the system wasn’t the hardest part, getting people to trust it was.”
What Worked
- Starting from the ground with real pain
- Delivering fast = building credibility
- Low-code tools = high adoption + easy iteration
What I’d Improve
- More early engagement with engineering to align on scope
- Connect the platform with existing tools (e.g. Jira, Confluence)
- Earlier feedback loop with end users on search behavior
Final Words
This case wasn’t about flashy UX. It was about building internal trust through a functional, reliable support system. The success didn’t come from UI polish; it came from listening, simplifying, and proving value fast.
It taught me the value of:
- Leading without a mandate
- Turning complaints into structured insight
- Designing systems that scale without needing scale themselves