Explanation:

In Salesforce Field Service, scheduling is based on Service Territories (the geographic or logical areas where service is delivered) and Service Territory Members (the technicians assigned to those territories).

Service Territory time zone: Defines the local time zone for scheduling work in that area.
Service Territory Member: Represents a technician who works in that territory, with their own Operating Hours (availability schedule).

In this scenario, the technician’s personal time zone is one hour behind the Service Territory’s time zone. This creates a scheduling problem: the system may think the technician is available when they’re not, or vice versa.

To fix this, you adjust the Operating Hours for that Service Territory Member by adding one hour to their start and end times. This ensures the technician’s availability matches the territory’s scheduling logic.

Why not the others?

A (Add one hour to Service Territory times): This would shift all technicians in the territory, not just the one member. Incorrect.

B (Change the time zone on the user record): The user’s time zone is for UI display, not scheduling optimization.

D (Subtract one hour from Service Territory times): Again, this affects the entire territory, not just one technician.

Real-world Example:
Service Territory is in New York (EST).
Technician lives in Chicago (CST), which is one hour behind.
If the territory’s operating hours are 9am–5pm EST, the technician’s availability must be set as 8am–4pm CST to align correctly. By adjusting the member’s operating hours in Salesforce, the scheduler sees accurate availability.

Reference:
Salesforce Help: Service Territory Members and Operating Hours

Explanation:

When two technicians are required for a job but can arrive at different times, the best practice is to create two separate Service Appointments. Each appointment can be scheduled independently, allowing flexibility in technician arrival times while still linking both appointments to the same Work Order. This ensures accurate tracking of technician time, resource allocation, and completion status.

This approach also supports reporting and optimization. Each technician’s appointment is visible in the Dispatcher Console, making it easier to manage workloads.

Why the Other Options Are Incorrect
B. One appointment with two required resources: This forces both technicians to be scheduled at the same time, which contradicts the requirement.

C. One appointment with two resources: Same issue — both resources must be onsite simultaneously.

D. Two appointments with Early Start: Overcomplicates scheduling; Early Start is not needed if separate appointments are created.

References
Salesforce Help: Service Appointments
Trailhead: Field Service Work Orders and Appointments

Explanation:

Each Asset record in Salesforce has a standard field called Installation Date, which captures when an asset (product) was installed. Reporting can be done by creating a report filtered on the Installation Date field—making it straightforward to analyze volumes over specific periods.

“Assets include an Installation Date field for tracking installation metrics.” (Salesforce Assets Data Model)

Why the Others are Incorrect:
A: Work order related list doesn’t capture installation date; it links service events.
B: Custom field on products consumed isn’t standard, requires custom development, and doesn’t link directly to reporting on installed products.
C: Field history tracking on asset tracks changes, not installation volume.

Explanation:

The "Customer First" scheduling policy is a standard out-of-the-box policy designed to balance two competing interests: company efficiency and customer satisfaction. This policy prioritizes Service Objectives that favor the customer’s preferences (such as using a "Preferred Resource") while still including rules to help clear the backlog. It is the only policy that specifically weights the "individual customer service preferences" as a primary driver for the scheduling engine's decision-making.

Why the others are incorrect:
A (Emergency): This policy is used for high-priority, "right now" jobs. It focuses on the nearest available technician and ignores preferences in favor of speed.
B (High Intensity): This is not a standard Salesforce scheduling policy.
C (Soft Boundaries): This policy is designed to allow technicians to work across territory lines if it helps clear the schedule, but it does not prioritize individual customer preferences.

Reference:
Salesforce Help: Standard Scheduling Policies

Explanation:

Utilizing a custom Price Book specific to each country represents the most straightforward, maintainable, and compliant approach for multinational pricing in European deployments. Each European country typically has different currencies, tax regulations, competitive landscapes, and pricing strategies, necessitating separate Price Books. Creating country-specific custom Price Books allows Universal Containers to:

Manage different currencies natively within each Price Book
Apply country-specific pricing strategies without cross-border contamination
Maintain clear audit trails for country-specific pricing decisions
Simplify reporting by country since each Price Book corresponds to a geographical market
Ensure compliance with local pricing regulations and tax requirements

This approach also supports efficient operations—when creating Work Orders or Opportunities in a specific country, users simply select the appropriate country Price Book, ensuring correct pricing without manual adjustments. The structure scales easily as Universal Containers expands to additional European countries, as each new market gets its own dedicated Price Book.

Why Other Answers Are Incorrect
Option B (Standard Price Book with pricing rules) attempts to force all European countries into a single Price Book structure, which creates significant operational challenges. The standard Price Book can only support one currency, making multinational pricing impossible without complex workarounds. Pricing rules could theoretically adjust prices by country, but this creates a fragile, complex system that's difficult to maintain and audit.

Option C (Custom Price Book with pricing rules) represents a middle ground but still suffers from complexity. While a single custom Price Book avoids using the standard one, it still forces all countries into one currency structure. Pricing rules would need to handle all country variations, creating maintenance overhead and potential for pricing errors across different currencies and tax regimes.

Option D (Standard Price Book specific to each country) is conceptually contradictory—there is only one standard Price Book in Salesforce. You cannot have multiple "standard" Price Books; the standard Price Book is a singular system object. While you could theoretically rename and repurpose it for one country, this would prevent using it for other purposes and violates Salesforce best practices.

References:
Salesforce Multi-Currency Implementation Guide specifically recommends: "For organizations operating in multiple countries with different currencies, create separate custom Price Books for each country/currency combination." The guide further explains that "this approach simplifies currency management, ensures pricing accuracy, and supports country-specific reporting requirements."