Famstack Users Guide

Defines the band structure used to classify employees in the organization (e.g., Band A, Band B, Band C, etc.).

Purpose: Used for employee categorization, reporting, and organizational hierarchy. Bands typically represent different levels of seniority or compensation ranges.

Usage: When creating or editing employee profiles, you can select from the configured bands. This helps maintain consistency in employee classification across the organization.

Example Values: Band A, Band B, Band C, Band D, Band E, Band F

Defines the grade levels within each band (e.g., A 1, A 2, B 1, B 2, etc.).

Purpose: Provides a more granular classification system within bands. Grades help differentiate between employees at similar band levels.

Usage: Used in employee profiles to specify exact grade level, which may be used for compensation, reporting, and organizational structure purposes.

Example Values: A 1, A 2, B 1, B 2, B 3, C 1, C 2, C 3, D 1, D 2, D 3, E 1, E 2, F 1, F 2

Defines the list of technical and professional skills that can be assigned to employees.

Purpose: Used for skill-based resource allocation, project assignment, and matching employees to projects based on required skills.

Usage: When creating employee profiles or searching for resources, you can assign and filter by these skills. This helps ensure employees are matched to projects that require their expertise.

Example Values: Java developer, Web developer, UI developer, Data Analyst, Business analyst, Backend developer, Data scientist

Defines the business domains or practice areas in which employees work.

Purpose: Used to categorize employees by their area of expertise or business domain. Helps in resource planning and domain-specific reporting.

Usage: Assigned to employees to indicate their primary domain of work, which can be used for filtering, reporting, and resource allocation.

Example Values: DPG, Data science, DE, DM

Defines the list of professional certifications that employees can hold.

Purpose: Tracks professional certifications and credentials held by employees. Useful for compliance, skill verification, and project requirements.

Usage: Assigned to employee profiles to record their certifications. Can be used for filtering employees with specific certifications when assigning to projects.

Example Values: Certification 1, Certification 2

Defines the list of countries where employees are located or can work.

Purpose: Used for geographic reporting, timezone management, and location-based resource allocation.

Usage: Assigned to employees to indicate their work location. Helps in understanding geographic distribution of resources and managing timezone considerations.

Example Values: India, Singapore, USA, UAE, UK

Defines specific office locations and cities where employees work.

Purpose: Provides detailed location information for employees, useful for office management, local reporting, and resource planning.

Usage: Assigned to employees to specify their exact work location. Can include both domestic and international office locations.

Example Values: Bengaluru, Mumbai, Hyderabad, Gurugram, New Delhi, Dubai, and various US locations (WA - Washington, CA - California, NY - New York, etc.)

Defines the types of employment arrangements in the organization.

Purpose: Categorizes employees by their employment contract type. Used for reporting, compliance, and resource planning.

Usage: Assigned to employees to indicate whether they are permanent, contract, consultant, or intern. This affects billing, reporting, and resource availability.

Example Values: Permanent, Contract, Consultant, Intern

Defines the major business divisions or units within the organization.

Purpose: Represents the top-level organizational structure. Used for high-level reporting, resource allocation, and organizational hierarchy.

Usage: Assigned to employees and projects to indicate which division they belong to. Helps in divisional reporting and resource management.

Example Values: Market Intelligence, Research AI, AI-Labs, Life Sciences, Digital & Advanced Analytics, Support

Defines the departments within divisions. Provides a more detailed organizational structure.

Purpose: Represents departmental organization within divisions. Used for departmental reporting, resource allocation, and organizational management.

Usage: Assigned to employees to indicate their department. Can be used for filtering, reporting, and understanding departmental resource distribution.

Example Values: Market Intelligence, Research AI, Advisory, Insights & Analytics, Artificial Intelligence & Product Engineering, Life Sciences, Digital & Advanced Analytics, Finance & Accounts, Human Resources, Information Technology, Sales, and many more

Defines sub-departments or teams within departments. Provides the most granular organizational structure.

Purpose: Represents teams or sub-units within departments. Used for detailed organizational reporting and team-level resource management.

Usage: Assigned to employees to indicate their specific sub-department or team. Helps in team-level reporting and resource allocation.

Example Values: Includes various sub-departments like AMRI, Global Primary Research, Visual Services, Quality Assurance, Product Management, Talent Management, Data Processing, Analytics, and many more

Defines job titles and designations used in the organization.

Purpose: Standardizes job titles across the organization. Used for organizational hierarchy, reporting, and employee classification.

Usage: Assigned to employees to indicate their job title. Used in organizational charts, reporting, and understanding the hierarchy.

Example Values: Includes executive roles (Senior Vice President, Vice President, Associate Vice President), management roles (Senior Director, Director, Senior Manager, Manager), technical roles (Principal Data Scientist, Senior Data Scientist, Data Scientist, Lead Software Engineer, Senior Software Engineer), and operational roles (Senior Analyst, Analyst, Trainee, Intern)

Defines the educational qualification levels for employees.

Purpose: Tracks educational background of employees. Used for reporting, compliance, and understanding workforce qualifications.

Usage: Assigned to employee profiles to record their highest educational qualification. Can be used for filtering and reporting purposes.

Example Values: Doctorate, Masters, Bachelors, Diploma

Defines the service categories that employees can be assigned to based on their role and function.

Purpose: Categorizes employees by the type of service they provide. Used for resource allocation, billing, and service-based reporting.

Usage: Assigned to employees to indicate their service category. Helps in understanding resource distribution across different service types.

Example Values: Advisory, AI-Labs, Delivery, Enabler, Leadership, Presales, Product, Sales, Support

Defines a hierarchical structure for practices, with primary practices containing secondary practices.

Purpose: Organizes employees and projects by practice areas in a hierarchical structure. Allows for both primary and secondary practice assignments.

Structure: Two-level hierarchy:

• Level 2 - Primary Practice: Top-level practice areas
• Level 1 - Secondary Practice: Sub-practices within primary practices

Usage: Employees and projects can be assigned to both a primary practice and one or more secondary practices. This allows for flexible categorization and cross-practice collaboration.

Example Structure:

• Primary Practice → Secondary Practice, Secondary Practice 1
• Primary Practice 1 → Secondary Practice, Secondary Practice 1, Secondary Practice 2

Defines the teams within the organization. Teams can be dynamically created and managed.

Purpose: Represents working teams or groups of employees. Used for team-based project assignment, reporting, and resource allocation.

Usage: Teams are created and managed separately. Employees are assigned to teams, and teams can be assigned to projects. This enables team-based collaboration and reporting.

Note: Team names are typically managed dynamically and may not appear in the configuration if teams are created on-demand.

Controls whether projects can have only one service line selected, or multiple service lines.

When Enabled: When creating or editing projects, you can select only one service line. This simplifies project setup and ensures projects are focused on a single service area.

When Disabled: Projects can have multiple service lines, allowing for more complex projects that span multiple service areas.

Use Case: Enable when projects typically focus on a single service area. Disable when projects often involve multiple service lines and you need to track work across different service areas.

Controls whether projects can have multiple service lines with individual time and cost estimates for each.

When Enabled: Projects can include multiple service lines, each with its own estimated hours and costs. This allows for detailed estimation and tracking across different service areas.

When Disabled: Service line estimates are not available or limited. Projects may only have overall estimates without service line breakdown.

Use Case: Enable when you need detailed cost and time breakdowns by service line for budgeting and planning. Disable when simple project-level estimates are sufficient.

Defines a three-level hierarchical structure for categorizing project work: Service Line → Delivery Category → Task Category.

Purpose: Provides a comprehensive categorization system for project work, enabling detailed tracking, reporting, and billing by service line, delivery category, and task category.

Structure: Three-level hierarchy:

• Level 3 - Service Line: Top-level service categories (e.g., Coding, Analysis, Reporting, Data Processing)
• Level 2 - Delivery Category: Sub-categories within service lines (e.g., QC, General, Programming, Adverse Event)
• Level 1 - Task Category: Specific task types within delivery categories (e.g., Coding - OE, Review - OE, Overview - OE)

Usage: When creating tasks or work items, you select from this hierarchy. This enables detailed categorization of work for accurate tracking, billing, and reporting.

Example Structure:

• Coding → QC → QC - OE, QC - OS, Overview - OE
• Coding → Programming → Coding - OE, Review - OE, Re-work/changes - OE
• Analysis → PM, Data Analysis, Data Processing, QC, Presentation/Insights
• Project Management → QA, Setup, Closure, General, Quality, Re-work, Fieldwork

Controls whether employees can only be assigned to projects that match their assigned service lines.

When Enabled: When assigning employees to projects, only employees whose service lines match the project's service line are available for selection. This ensures proper skill matching.

When Disabled: Any employee can be assigned to any project regardless of service line matching.

Use Case: Enable when you want to ensure employees are only assigned to projects that match their expertise. Disable when cross-service line assignments are common and desired.

Controls whether project category selection is available when creating or editing projects.

When Enabled: Projects can be assigned to categories, allowing for better organization and filtering of projects.

When Disabled: Project category selection is not available. Projects cannot be categorized.

Use Case: Enable when you need to organize projects by categories for reporting and management purposes.

Defines the list of categories that can be assigned to projects.

Purpose: Used to classify projects by type, client, or other organizational criteria. Helps in project organization, filtering, and reporting.

Usage: Assigned to projects during creation or editing. Can be used to filter project lists and generate category-based reports.

Example Values: Project Category2, Project Category3, Project Category4, Project Category5, Project Category6, Project Category7, Project Category8

Defines categories for project deliverables and delivery types.

Purpose: Used to categorize project deliverables and delivery methods. Helps in tracking different types of deliverables and delivery approaches.

Usage: Used when creating tasks or deliverables to indicate the delivery category. Can be used for reporting and tracking delivery types.

Example Values: Task Category, Task Category1, Task Category2, Task Category3, Task Category4, Task Category5, Task Category6, Task Category7

Defines categories for individual tasks within projects.

Purpose: Provides a classification system for tasks. Helps in organizing and categorizing different types of work within projects.

Usage: Assigned to tasks to indicate their category. Can be used for task filtering, reporting, and organization.

Example Values: Task Act Category, Task Act Category1, Task Act Category2, Task Act Category3, Task Act Category4, Task Act Category5, Task Act Category6, Task Act Category7

Defines the types of services that projects can provide.

Purpose: Categorizes projects by the type of service they deliver. Used for service-based reporting and project classification.

Usage: Assigned to projects to indicate the service category. Helps in understanding the distribution of projects across different service types.

Example Values: Full Service, MRPO, Sample Only, Qualitative

Controls whether a purchase order must be linked to a project before it can be created or activated.

When Enabled: Projects cannot be created or activated without an associated purchase order. This ensures all projects have proper authorization and billing setup.

When Disabled: Projects can be created without purchase orders. Purchase orders are optional.

Use Case: Enable when all projects must have purchase orders for compliance and billing purposes. Disable when some projects may not require purchase orders (e.g., internal projects).

Controls whether purchase orders can be imported from Salesforce integration.

When Enabled: Purchase orders can be automatically imported from Salesforce, reducing manual data entry and ensuring data consistency.

When Disabled: Purchase orders must be created manually in the system. Salesforce integration for purchase orders is not available.

Use Case: Enable when you have Salesforce integration and want to automate purchase order creation. Disable when purchase orders are managed entirely within this system.

Controls whether project accounts are filtered by user teams or available across all teams.

When Enabled: Project accounts are restricted to teams. Users can only see and select accounts from their assigned teams.

When Disabled: Project accounts are available across all teams. Users can see and select accounts from any team.

Use Case: Enable when you want to maintain team boundaries for account access. Disable when accounts should be shared across teams.

Controls whether task/deliverable estimated end dates are automatically updated when the project's estimated end date is changed.

When Enabled: When you change a project's estimated end date, all associated deliverables' estimated end dates are automatically adjusted proportionally. This maintains the relationship between project and deliverable timelines.

When Disabled: Deliverable dates remain unchanged when project dates are modified. You must manually update deliverable dates if needed.

Use Case: Enable when you want automatic synchronization between project and deliverable dates. Disable when deliverable dates should be managed independently.

Defines the default email addresses that receive notifications when purchase orders are created, updated, or have status changes.

Purpose: Ensures relevant stakeholders are automatically notified about purchase order activities without requiring manual email configuration for each purchase order.

Usage: These email addresses are automatically included in purchase order notifications. Additional recipients can be added for specific purchase orders if needed.

Example Values: DAAfamstack.com, DGfamstack.com

Defines the default email addresses for the finance team that receive purchase order notifications.

Purpose: Ensures the finance team is automatically notified about purchase order activities for financial tracking and processing.

Usage: Finance team email addresses are automatically included in purchase order notifications. Separate from general purchase order notifications to ensure finance visibility.

Example Values: DG.famstack.com, MIAfamstack.com

Defines the default email addresses that receive notifications when projects are created, updated, or have status changes.

Purpose: Ensures relevant stakeholders are automatically notified about project activities without requiring manual email configuration for each project.

Usage: These email addresses are automatically included in project notifications. Project-specific recipients can be added if needed.

Example Values: DG.DAAfamstack.com, DG.MIAfamstack.com

Defines the default email addresses for the finance team that receive project notifications.

Purpose: Ensures the finance team is automatically notified about project activities for financial tracking, billing, and budget management.

Usage: Finance team email addresses are automatically included in project notifications. Separate from general project notifications to ensure finance visibility.

Example Values: DG.DAAfamstack.com, DG.MIAfamstack.com

Defines the default email addresses that receive notifications related to personally identifiable information handling in projects.

Purpose: Ensures data compliance and security teams are notified about PII-related activities for compliance monitoring and data protection.

Usage: These email addresses receive notifications when projects involve PII data or when PII-related activities occur. Critical for data compliance and security.

Example Values: datacompliancefamstack.com

Defines the default email addresses that receive notifications when deliverables are created, updated, or completed.

Purpose: Ensures relevant stakeholders are automatically notified about deliverable activities and milestones.

Usage: These email addresses are automatically included in deliverable notifications. Helps keep stakeholders informed about project progress and deliverable status.

Example Values: DG.DAAfamstack.com, DG.MIAfamstack.com

Defines the tools and software applications that can be used in projects.

Purpose: Tracks which tools are used in projects for resource planning, skill requirements, and project setup.

Usage: Assigned to projects to indicate required or used tools. Can be used for resource allocation and ensuring projects have access to necessary tools.

Example Values: Microsoft Office, Power BI

Defines the products or solutions that projects are related to or deliver.

Purpose: Tracks which products are associated with projects for product-based reporting and resource allocation.

Usage: Assigned to projects to indicate related products. Helps in product-based project tracking and reporting.

Example Values: Microsoft Office, Power BI

Defines the types of surveys that can be conducted in projects.

Purpose: Categorizes projects by survey methodology. Used for survey-based projects to specify the type of survey being conducted.

Usage: Assigned to projects that involve surveys to indicate the survey type. Helps in planning, resource allocation, and methodology tracking.

Example Values: Online, CATI, CAPI, Mobile, Recruit to Web, IDI (Recruitment only), IDI (Recruitment, Interview), TDI (Recruitment only), TDI(Recruitment, Interview), Mystery Shopping, FGD (Recruitment only), FGD (Recruitment, Moderation), Ethnography (Recruitment only), Ethnography(Recruitment, Moderation), Others

Defines the timezones that can be assigned to projects.

Purpose: Ensures projects are scheduled and managed according to the correct timezone. Important for global projects and client coordination.

Usage: Assigned to projects to indicate the primary timezone. Affects scheduling, deadlines, and time-based reporting.

Example Values: AU (Australia), SG (Singapore), IST (Indian Standard Time), GMT (Greenwich Mean Time), EST (Eastern Standard Time), PST (Pacific Standard Time), CST (Central Standard Time)

Defines whether project samples are provided by clients or generated internally.

Purpose: Tracks the source of project samples for reporting and project setup purposes.

Usage: Assigned to projects to indicate sample source. Helps in understanding project requirements and resource needs.

Example Values: Client, Internal

Defines the currencies that can be used for project billing and financial tracking.

Purpose: Supports multi-currency projects and ensures proper financial tracking in the project's currency.

Usage: Assigned to projects to indicate the billing currency. Affects cost estimates, invoicing, and financial reporting.

Example Values: USD (US Dollar), EUR (Euro), GBP (British Pound), SGD (Singapore Dollar), AUD (Australian Dollar), INR (Indian Rupee)

Defines service lines that can be used specifically for feedback collection and management.

Purpose: Categorizes feedback by service line, enabling service-line-specific feedback tracking and reporting.

Usage: Used when creating feedback requests to associate them with specific service lines. Helps in organizing and analyzing feedback by service area.

Example Values: Feedback Service Line, Feedback Service Line 1, Feedback Service Line 2

Defines the categories of work that are not billable to clients. These represent internal activities, administrative work, and other non-client-facing activities.

Purpose: Provides a comprehensive list of non-billable work categories for accurate time tracking and reporting. Helps distinguish between billable and non-billable hours.

Usage: When logging non-billable time entries, you select from these categories. This ensures consistent categorization of non-billable work across the organization.

Example Values: Internal Team Meeting and Admin Work, Snacks / Lunch / Dinner, Knowledge Development and Training, Imparting Trainings, Technical Downtime / IT issues, Client Meeting, Internal product/solution development and Support, CSR, Documentation, Timesheet Updation, Handover, Marketing Collaterals, POC, Project Management (Mails, Queries and Task), Reading Manuals and R&D, Recruitment Activities/Interviews, Onsite Client Visits, Presales Proposals, QC Changes, Feedback Sharing, Additional Support

Defines non-billable categories that don't require additional detail fields when logging time.

Purpose: Simplifies time entry for certain categories that don't need detailed information. Reduces data entry time and complexity.

Usage: When logging time for these categories, additional fields (like project details, descriptions, etc.) are hidden or not required. This streamlines time entry for routine activities.

Example Values: Leave, Holiday, Internal Team Meeting and Admin Work, Snacks / Lunch / Dinner, Knowledge Development and Training, Imparting Trainings, Technical Downtime / IT issues

Defines the divisions that can be associated with non-billable work.

Purpose: Allows categorization of non-billable work by division for divisional reporting and resource allocation.

Usage: Assigned to non-billable time entries to indicate which division the work relates to. Helps in understanding non-billable time distribution across divisions.

Example Values: RAI, LS, MIA, DAA

Defines client partners that can be associated with non-billable work (e.g., internal meetings with client partners, presales activities).

Purpose: Tracks non-billable activities related to specific client partners for relationship management and reporting.

Usage: Assigned to non-billable time entries when the activity relates to a specific client partner. Helps in tracking relationship-building activities.

Example Values: Client Partner 1, Client Partner 2, Client Partner 3, Client Partner 4

Defines the types of studies and methodologies that can be specified in bid requests and sales opportunities.

Purpose: Categorizes sales opportunities and bid requests by study type and methodology. Helps in understanding the types of studies being pursued and won.

Usage: Assigned to bid requests to indicate the type of study being proposed. Used for reporting, resource planning, and understanding sales pipeline by study type.

Example Values: Online Quantitative, Online Quant - Central Location Test, Face to Face Quantitative, CATI Quantitative, Online Qualitative, Offline Qualitative (Specify – FGDs, IDIs), Others

Defines the list of client names used in sales opportunities and bid requests.

Purpose: Standardizes client naming in the sales module. Ensures consistent client identification across bid requests and sales opportunities.

Usage: Assigned to bid requests and sales opportunities to indicate the client. Used for client-based reporting and tracking sales activities by client.

Example Values: Client Name 1, Client Name 2, Client Name 3, Client Name 4

Defines the types of decision makers involved in sales opportunities.

Purpose: Categorizes decision makers by their role and function. Helps in understanding the decision-making structure and targeting appropriate stakeholders.

Usage: Assigned to contacts or stakeholders in bid requests to indicate their decision-making role. Used for stakeholder analysis and sales strategy.

Example Values: BDM (Business Decision Maker), ITDM (IT Decision Maker), Financial DM (Financial Decision Maker), Travel DM (Travel Decision Maker), Advertiser / Marketing, Logistics / Procurement

Defines the job title levels of decision makers in sales opportunities.

Purpose: Categorizes decision makers by seniority level. Helps in understanding the level of decision makers involved and tailoring sales approaches.

Usage: Assigned to contacts in bid requests to indicate their designation level. Used for reporting and understanding decision-making hierarchy.

Example Values: Manager+, VP+ (Vice President and above), C Level (C-Suite executives)

Defines the size categories for companies in sales opportunities.

Purpose: Categorizes potential clients by company size. Used for market segmentation, reporting, and understanding the types of companies being targeted.

Usage: Assigned to bid requests or client records to indicate company size. Helps in sales strategy and resource allocation based on company size.

Example Values: Small Business, SMB (Small and Medium Business), LE (Large Enterprise)

Defines revenue/turnover ranges for companies in sales opportunities.

Purpose: Categorizes companies by revenue size. Used for market analysis, reporting, and understanding the financial scale of potential clients.

Usage: Assigned to bid requests or client records to indicate company turnover. Helps in sales strategy and opportunity assessment.

Example Values: Upto $100mn, 100 – 300mn, 500+mn

Defines the types of medical professionals that can be targeted in healthcare-related sales opportunities.

Purpose: Categorizes target audiences for healthcare and life sciences sales opportunities. Used for healthcare-specific bid requests and studies.

Usage: Assigned to bid requests in the healthcare/life sciences domain to indicate the target medical professional types. Helps in study design and resource planning.

Example Values: General Physicians / Family Physicians, Cardiologist, Dentist, Pediatrician, Oncologist, Plastic Surgeon, Pulmonologist, Veterinary, Lab Technician/Lab Director

Defines the types of patients that can be targeted in healthcare-related studies.

Purpose: Categorizes patient populations for healthcare studies. Used for healthcare-specific bid requests and study design.

Usage: Assigned to bid requests in the healthcare domain to indicate target patient categories. Helps in study design and understanding study requirements.

Example Values: Diabetic, Cancer, Asthma, Obesity, Psoriasis, Anxiety/Hypertension, Skin infection, Chronical disease

Defines the types of hospitals that can be involved in healthcare studies.

Purpose: Categorizes healthcare facilities for healthcare-related studies. Used for healthcare-specific bid requests and study planning.

Usage: Assigned to bid requests in the healthcare domain to indicate hospital types. Helps in study design and resource planning.

Example Values: Private, Government

Defines the countries where sales opportunities and studies can be conducted.

Purpose: Tracks the geographic scope of sales opportunities. Used for geographic reporting and understanding market coverage.

Usage: Assigned to bid requests to indicate target countries. Helps in geographic reporting and resource allocation by region.

Example Values: US, UK, Australia, Brazil, Canada, China, France, Germany, India, Japan, Mexico, Spain, UAE, Italy, Netherland, Malaysia, Thailand, Philippines, Indonesia

Defines the default email addresses that receive notifications for bid requests and sales opportunities.

Purpose: Ensures relevant stakeholders are automatically notified about bid request activities, status changes, and sales opportunities.

Usage: These email addresses are automatically included in bid request and sales notifications. Helps keep the sales team informed about opportunities and activities.

Example Values: bidsfamstack.com

A locked configuration cannot be modified at the current level. It inherits its value from a parent level (organization, team, etc.).

When Locked: The configuration value is read-only and cannot be changed. You must modify it at the parent level if changes are needed.

When Unlocked: The configuration can be customized at the current level, allowing for level-specific customization.

A hidden configuration is not visible in the user interface, even though it may have a value.

When Hidden: The configuration field does not appear in forms or settings pages. Users cannot see or interact with it.

When Visible: The configuration appears in the interface and can be viewed and modified (if not locked).

An overridden configuration has been customized at the current level, overriding the parent value.

When Overridden: The current level has its own value that differs from the parent. This allows for level-specific customization.

When Not Overridden: The configuration uses the parent value. Changes at the parent level will affect this level.