Loading…
How we automated FAQ responses at Grab
GrabPreeti Karkera
Summary
Internal engineering on-call engineers at Grab spent substantial working hours handling repetitive questions in Slack channels, such as how-to inquiries and access permission requests. To resolve this without building an in-house tool, the team conducted an anonymized vendor comparison and selected OneBar through an employee voting process and a phased proof-of-concept. Initial rollouts were restricted by contract to 20 channels, leading the team to prioritize deployment based on Slack message volume and member counts. Populating the knowledge base required roughly a quarter of consistent updates alongside tech talks, while a targeted crowdsourcing campaign among new onboarders expanded the glossary and grew usage to approximately 3,000 users.
Context
On-call engineers at Grab spent significant time in Slack channels answering repetitive queries that were already documented, hindering productivity and operational work.
Approach / What changed
Evaluated vendors via blind employee voting, conducted a three-phase proof-of-concept with OneBar, prioritized 20 high-traffic Slack channels using analytics, and crowdsourced knowledge base entries and acronym glossaries through onboarder campaigns.
Takeaways
- Anonymizing vendor names and highlighting core feature differences prevented user bias toward familiar brands during the selection process.
- A 20-channel contract constraint was addressed by using Slack analytics to prioritize channels with the highest monthly message volume and member counts.
- Achieving accurate automated responses required about one quarter of consistent knowledge base feeding supported by targeted onboarding campaigns.
Related reading
Grab ·
Automatic rule backtesting with large quantities of data
Evaluating new or modified risk rules previously required Grab analysts to run slow offline Presto queries, manually construct payloads, or run rules in shadow mode for days. To standardize and accelerate this workflow, Grab developed an automated backtesting system powered by an AWS EMR Spark pipeline. Historical events are continuously ingested via Kafka and a Kubernetes stream pipeline into S3 using Snappy-compressed Parquet. Users configure replay intervals and rule definitions directly in the rule engine UI, which triggers asynchronous Spark jobs through Amazon SQS and Lambda. This automated simulation replaces multi-week shadow mode runs and generates downloadable aggregation metrics on transactions, user counts, and treatment outcomes.
Chao WangGrab ·
How facial recognition technology keeps you safe
Grab utilizes facial recognition technology across its platform for driver authentication, passenger verification, and digital electronic Know Your Customer (e-KYC) processes. The core pipeline consists of image preprocessing through face detection and alignment, anti-spoofing checks, feature extraction into high-dimensional vector embeddings, and downstream verification or search. To counter spoof attacks like screen replays, synthetic moiré patterns are generated and cropped face patches are used during training and inference to focus on local structures rather than global semantic noise. Face verification challenges involving shallow ID datasets and masked faces are resolved using semi-Siamese training architectures and masked data augmentations.
Kai Feng TeeGrab ·
How we evaluated the business impact of marketing campaigns
Grab needed a scalable, centralised way to evaluate the business impact of millions of marketing messages sent across expanding campaigns. Manual analysis by marketing analysts produced inconsistent results and failed to scale, leading to the creation of multi-touch attribution and controlled experiment methodologies. The team designed a Marketing attribution model (MAM) that credits touchpoints based on relevance and recency, while using stratified hold-out groups to assess single campaign lift against baseline metrics. Statistical significance calculations, implemented using the jStat library based on the central limit theorem, ensure observed business metric differences like gross merchandise value are not random. The system provides campaign managers with direct access to impact analyses while the team works on challenges surrounding smaller sample sizes and hold-out group constraints.
Jie ZhangGrab ·
Graph concepts and applications
Real-world systems generate dynamic, non-random connections that traditional statistical approaches fail to characterize or forecast. Graph models represent these structures through vertices and edges, abstracting complex networks into mathematically tractable relationships. Common data representation formats include the Resource Description Framework (RDF), which models subject-predicate-object triples with IRIs, literals, and blank nodes, and Labeled Property Graphs (LPGs), which store arbitrary key-value properties directly on nodes and edges. Graph databases, derived from the LPG model, treat relationships with equal weight to entities, delivering responsive traversals for highly interconnected systems. While they offer agility and explicit relationship modeling, graph databases lack a standardized query language and remain poorly suited for standard transaction-focused workloads compared to relational databases.
Wenxiang Lu