Version 2 vs 17
Version 2 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.
= Product Overview =
Pebkac has three main views
- user home page
- ticket view for user
- ticket view for customer
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
- be 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 and new ones added. Customers should also have a list of their other tickets handy on any ticket single view page.
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. The user home page should show the various queues and the status they have.
= Data Overview =
- ticket
-- id
-- PHID
-- owner_phid
-- queue_id
-- subject - eg subject of initial email
-- status -- OPEN | ASSIGNED | CLOSED
-- lastSupportedTime -- when the ticket last got some lovin' or was created
-- INDEX(owner_phid, status, lastSupportedTime)
-- INDEX(queue, status, lastSupportedTime)
- ticket_transactions
-- id
-- phid
-- ticket_id
-- data
- queue
-- id
-- phid
-- name
-- configuration
= 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.
= Product Overview =
Pebkac has three main views
- user home page
- ticket view for user
- ticket view for customer
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
- be 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 and new ones added. Customers should also have a list of their other tickets handy on any ticket single view page.
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. The user home page should show the various queues and the status they have.
= Data Overview =
- ticket
-- id
-- PHID
-- owner_phid
-- queue_id
-- subject - eg subject of initial email
-- status -- OPEN | ASSIGNED | CLOSED
-- lastSupportedTime -- when the ticket last got some lovin' or was created
-- INDEX(owner_phid, status, lastSupportedTime)
-- INDEX(queue, status, lastSupportedTime)
- ticket_transactions
-- id
-- phid
-- ticket_id
-- data
- queue
-- id
-- phid
-- name
-- configuration
= Complaint Sources =
- twitter
- email
- IRC