Ref No.

Description Fully Capable (FC),

Capable (C), Partially
Capable (PC), Not
Capable (NC)

A. Customer Care/Walk In Dashboard

A.1 User Profile
a.1.1Ability to pre-register customers to the kapamilya rewards program
-          First Name and Last Name fields should be separate and both are required
fields
-          Address field should have minimal free-form text fields. Have a drop-down
field for State, City and Country
a.1.2Ability to pull customer information
a.1.3 -          Full Profile (All LOB accounts in kapamilya name)
a.1.4 -          Current Points
a.1.5 -          Historical Transactions (Earn, Burn & Transfer History)
a.1.6Ability to edit customer information
a.1.7 -          Edit full profile (e.g. Name, Mobile number, email and etc.)
a.1.8 -          Link/Unlink a customer’s LOB accounts
a.1.9Ability to view a customer’s eSOA for the past 12 months, 6 mos, or on a specified
period
a.1. -          Email to customer
a.1. -          SMS to customer
a.1. Ability to deactivate a customer’s rewards program account
a.1. Ability to maintain multiple customer tier levels
a.1. Ability to upgrade, downgrade, or retain tier level
A.2 Redemption
a.2.1Ability to see all available rewards
a.2.2Ability to redeem rewards for the customer
-          Ability to select shipment methods for physical goods
-          System to provide the questions to validate customer’s identity (for
Customer Care)
a.2.3Ability cancel redemption transactions of the customer
a.2.4Ability to view all redemptions
A.3 Earn
a.3.1Ability to provide points to the customer (applicable for Customer Care)
a.3.2Ability to link provided points to service request system (applicable for Customer
Care)
a.3.3Ability to view earned points and its expiration
A.4 Logs
a.4.1Audit trail for customer care modifications to customer account
a.4.2Audit trail for all retrieved information per customer care agent
a.4.3Audit trail for all redemptions by an agent for the customer
a.4.4Audit trail for all points given to the customer per agent
a.4.5Audit trail for user account creation/edit/deletion

B. Earn Rules
b.1 Facility to maintain & earn points depending on type of transactions:
b.1. - Thru viewing (e.g. IWANTTV or SKYONDEMAND) based on # of
minutes/seconds and tier (paying or not)
b.1. -Top-up (parameterized by amount or frequency)
b.1. - When completing a purchase depending on amount of retail items
(from Online Store or ACJO)
b.1. - Upon registration to Rewards Program
 b.1. - When completing a purchase depending on type of services (e.g. PPV,
SkyBroadband, SkyMobi, Upgrades, New Installation etc.)
b.1. - Enrollment to other services (e.g. Auto Debit Arrangement)
b.1. - Other transactions like early payment, submission of DTT warranty
card, subscription to eSOA
b.1. - Frequency of purchase
b.1. - Through browsing
b.1. - Through social media actions
b.2 Facility to earn extra points (i.e. double, triple, etc)
b.2. - Providing additional information during registration to Rewards
Program
b.2. - On a specified period (e.g. Monday)
b.2. - Tenure (e.g 6th month, anniversary etc.)
b.2. - Special Promos or Campaigns
b.2. - Birthday as gift
b.3 Facility to earn points upon customer referrals
b.4 Earned points can be real-time or batch updating depending on source
b.5 Earned points can be setup globally, per line of business, or per product/service

b.6 Automatic pooling at customer level regardless of source

b.7 Facility to identify source of earning and transaction date
b.8 Facility to set different points for certain products or services
b.9 Facility to define bonus points for promotions and marketing campaigns
b.10 Facility to earn points based on customer tier levels
b.11 Top-up of points is possible via payment gateway

C. Burn Rules, Wallet, and Settlement

c.1 Burning of points
c.1.1First-in, first-out (FIFO) burning of earned points
c.1.2Real-time updating of points balance upon redemption
c.1.3Can accommodate partial redemption = points plus cash-out via payment gateway
or charged to bill
c.1.4System to keep per Kapamilya detailed redemption activities/transactions specifying
points consumed per transaction
c.1.5Capability to capture recommendation and present to Kapamilya (from Big Data
Analytics) on what products are relevant to the Kapamilya based on his historical
behavior/transactions
c.1.6Capability to push expiring and perishable products to the Kapamilya via SMS, email,
Web or App if the Kapamilya is online, – allow discount definition/configuration for
those nearing expiration
c.1.7Sample Burn Rules Model
c.2 Transfering of Points
c.2.1Points can be transferred from one Kapamilya to another by choosing from list of
enrolled Kapamilyas [refer to Account Maintenance Page (Enrollment of Fellow
Kapamilya) for the enrollment process]
c.2.2Points to be transferred should be whole numbers only (fraction of a point not
allowed)
c.2.3Transferred points should reflect real-time on both the source and recipient’s
Kapamilya accounts
c.2.4With capability to charge a transfer fee depending on set rules
c.2.5Option for transferred point to inherit status and expiration from the source or
renew
 c.2.6The system should allow us to define charges for each transfer transaction which will
also be deducted from the sender’s rewards wallet.
c.2.7The system should allow us to define maximum limit for the transfer transaction –
this can either be in terms of number of transfer transactions or number of points
that can be transferred
c.3 Expiration of Points
c.3.1Parameterized based on when points were earned and on last activity at customer
level
c.3.2For transferred points, the date of transfer of source Kapamilya will be treated as
the earned date of the beneficiary or the expiration of the transferred points will
inherit the expiration of the points of the sender
c.4 Kapamilya Wallet Management
c.4.1The system should be able to maintain reward points counter per LOB and
consolidated
c.4.2The system should also allow us to define expiration rules and present points earned
with date when they will expire
c.4.3Regular update to the Kapamilya on the points earned for the period, total
accumulated points as of the period, number of points expiring, points consumed
for the period – API for these information should be available to the different
channels such as SMS, email or Web/app

c.4.4An account/role or a campaign should be able to extend the expiry of a Kapamilya’s

points either individually or globally
c.4.5An account/role or a campaign should be able to hold the expiry of a Kapamilya’s
Points. 
c.4.6 Just in case we have a network wide downtime, we may choose to extend the expiry
of all points. At the same time, we may want to hold the expiring points of a
kapamilya
c.5 Inter-LOB Settlement
c.5.1The system should allow for a creation of a separate P&L for the Rewards System.

c.5.2The system should track points earned by the Kapamilya from each LOB participating
in the program and should correspondingly record in the Reward P&L

c.5.3The system should likewise track redemption made by the Kapamilya for each LOB
products and should likewise record the purchase
c.5.4Periodically (based on accounting cut-off), the system should generate all the
transactions made to each LOB for proper charging – the system should
automatically generate accounting entries to be recorded in the financial systems
(subsidiary and general ledgers).

c.5.5The system should also track and generate report for reward points breakage –
specifying from which LOB this came from.

D. Products and Rewards

d.1 Product Definition
d.1. Facility to maintain inventory of items that can be availed by the Kapamilya
d.1. Items can be assigned a product type/classification (e.g. physical, digital etc.)
d.1. System should generate a system generated or internal sequence numbering per
item.
d.1. Items should have user defined item code.
d.1. Items should have short and long names. Short names maybe used for printing
material. Long names are for screen display.
d.1. Items should have a description. Product details and specifications can be stored in
this field.
 d.1. Facility to upload or maintain an image or picture of item
d.1. Items should have date of effectivity. Start date and end date an item can be availed.

d.1. Facility to maintain the quantity of an item that can be offered. The system should
be able to indicate also if the quantity is limitless.
d.1. Facility to monitor the availments per item
d.1. Facility to maintain a threshold quantity per item and provide notification when
reached.
d.1. Facility to maintain and idicate the status of an item.
- Awaiting effectivity - start date haven't reached.
- Active - within start and end date and with quantity available
- No quantity - within start and end date but quantity depleted
- Expired - end date reached
- Suspended - within start and end date but user overrides status to prevent
availment.

d.1. Facility to assign GL account code for SAP integration

d.1. Each item have an amount pertinent to the rewards company
d.2 Product Availment
d.2. Items that are chargeable to points can be availed by (1) pure points or (2) partial
points plus peso amount.
d.2. Items are assigned to program. Program assignments have effectivity period.
d.2. Items can be availed by Kapamilya if Kapamilya is allowed in the program and the
items is assigned to the same program.
d.3 Product and LOBs
d.3. Facility to maintain list of LOBs - Company name, contact person, contact details,
contract reference, etc.
d.3. Items are assigned to LOB that is responsible in delivering and provisioning the item.

d.3. System should be able to store reference number of item in relation to LOBs
internal coding.
d.3. System should be able to store the cost of the item in relation to put payment cost
to the LOB.
d.3. System should be able to indicate if taxable or not, and the tax amount.

E. User Access Management

e.1 Facility to create new user accounts
e.2 Facility to edit & delete user accounts
e.3 Facility to control access/features depending on
e.3. - Access Rights (Add, Delete, etc.)
e.3. - Roles (End User, Administrator, Processor, Customer Care etc.)
e.3. - Company, Regions / Territories, Groups
e.4 System must be password protected and must comply to ABS-CBN Information
Security policies

F. Integration
f.1 Supports SOAP, JSON and ODBC
f.2 Supports API Integration
f.3 Supports batch processing (file based)
f.4 Supports web services
f.3 Must be able to integrate to core platforms of involved LOBs (e.g. SAP, Siebel, etc.)

G. Reporting and Monitoring

g.1 Audit trail to capture date/time stamps, user access, and updates/changes made.
Date and time stamps should be based on the time zone of the region
g.2 Monitor total earn-burn per customer across LOBs
g.3 Monitor total earn-burn per product
g.4 Monitor % based on a specified period -
g.4.1 - Percentage of customers who are members (Participation Rate)
g.4.2 - Percentage of members actively participating in the program through
earning/redeeming points (Activity rate)
g.4.3 - Length of membership (Tenure )
g.4.4 - Rate at which members drop out of the program based on a defined
threshold e.g. 6 months of inactivity (Attrition or churn rate)
g.5 Customers that registered but not activated (i.e. no transactions)
g.6 List of deactivated of accounts
g.7 Report generation related to inventory
g.7.1 - Active Inventory
g.7.2 - Most Availed
g.7.3 - Non-moving inventory
g.8 Full customer data of registered Kapamilyas (i.e. name, contact number, address,
and other customer related info)
g.9 Export to pdf, excel, and csv formats

H. General and Non-Functional Requirements

h.1 System must be available 24/7
h.2 System must be web-enabled and available via internet in a secured portal
h.3 System must be easy to use and must be have user friendly interface (e.g. Tablet-like
UI)
h.4 System must be compatible to all web browsers (e.g. IE, Safari, Chrome, etc.)
h.5 System can be easily upgraded to the next version upgrade without changing original
or existing configuration and customization
h.6 System must be backward compatible.
h.7 Cloud Readiness
h.8 Website should be mobile responsive. (To date, traffic to TFC.tv is 55% coming from
mobile)
h.9 Enterprise grade model
h.10 Supports clustering and scaling
h.11 Supports high availability
h.12 Supports DR (disaster recover)
Remarks