Version 1 vs 17
Version 1 vs 17
Content Changes
Content Changes
= Overview =
Pebkac is the customer support application within Phabricator. Its name is an acronym which stands for "problem exists between keyboard and chair." Despite this goofy name, pebkac takes customer support very seriously, enabling users to track customer issues all over the Internet and respond as closely to the source of the complaint as possible.
= Design Overview =
The heart of pebkac is the "ticket". A ticket
- represents a single issue, e.g. the site is down
-- NOTE: there may be more than one ticket for a single problem
- maps to 1 or more customers facing the problem
-- offline processes should condense tickets across customer based on "problem"
- maps to 1 or more places where the complaint was placed
-- offline processes should condense tickets across places based on "customer"
- contains a complete record of communication
Within pebkac, users operate on the ticket object primarily. When users interact, communication "automagically" happens as close to the source of the complaint as possible -- e.g. twitter complaints get tweet backs or whatever the kids call those things these days.
The ticket view should
- surface all known communication for the ticket
- surface pertinent information about the customer(s) facing the problem
- designed for both throughput and accuracy
The ticket view should also be viewable by the customer(s) though with pertinent information and abilities stripped out.
Tickets benefit from an organization mechanism known as queues. Queues can represent problems or types of problems, or otherwise be used as an arbitrary mechanism to group tickets for processing.
= Complaint Sources =
- twitter
- email
- IRC
= Overview =
Pebkac is the customer support application within Phabricator. Its name is an acronym which stands for "problem exists between keyboard and chair." Despite this goofy name, pebkac takes customer support very seriously, enabling users to track customer issues all over the Internet and respond as closely to the source of the complaint as possible.
= Design Overview =
The heart of pebkac is the "ticket". A ticket
- represents a single issue, e.g. the site is down
-- NOTE: there may be more than one ticket for a single problem
- maps to 1 or more customers facing the problem
-- offline processes should condense tickets across customer based on "problem"
- maps to 1 or more places where the complaint was placed
-- offline processes should condense tickets across places based on "customer"
- contains a complete record of communication
Within pebkac, users operate on the ticket object primarily. When users interact, communication "automagically" happens as close to the source of the complaint as possible -- e.g. twitter complaints get tweet backs or whatever the kids call those things these days.
The ticket view should
- surface all known communication for the ticket
- surface pertinent information about the customer(s) facing the problem
- designed for both throughput and accuracy
The ticket view should also be viewable by the customer(s) though with pertinent information and abilities stripped out.
Tickets benefit from an organization mechanism known as queues. Queues can represent problems or types of problems, or otherwise be used as an arbitrary mechanism to group tickets for processing.
= Complaint Sources =
- twitter
- email
- IRC