Category: Без рубрики

  • 9.1. ITIL defines 34 management practices.

    Practices help organisations perform work in a consistent and effective way.

    ITIL defines 34 management practices.

    These practices are grouped into three categories: general management practices, service management practices, and technical management practices.

    Not all practices are required in every organisation.

    Practices should be adapted based on organisational context, size, and needs.

    The value of a practice depends on how well it supports value creation.

    Practices can be combined and used together to support service value chain activities.


    2. How This Applies to TakeCars (Car Rental Marketplace)

    This video sets the frame for the practice-heavy part of ITIL, and the key message is adaptation, not completeness.

    a) TakeCars does not need “all 34 practices”

    For TakeCars:

    • Implementing all practices formally would be wasteful
    • What matters is whether practices support value creation

    Early-stage or scaling marketplaces succeed by:

    • Using a small number of practices well
    • Keeping them lightweight and outcome-focused

    This is fully aligned with ITIL 4.


    b) Practices as capability bundles, not bureaucracy

    Each practice is a reusable capability:

    • People
    • Rules
    • Data
    • Tools
    • Partners

    For example, at TakeCars:

    • Incident management exists even without a ticketing system
    • Service level management exists even without formal SLAs
    • Relationship management exists even without account managers

    The exam recognises this implicit adoption.


    c) Selecting the right practices for TakeCars

    High-impact practices for a car rental marketplace typically include:

    • Incident management
    • Service request management
    • Problem management
    • Service level management
    • Relationship management
    • Supplier (partner) management
    • Information security management
    • Continual improvement

    Others may remain minimal or informal.


    d) Exam-critical insight

    If the exam asks:

    “How should practices be applied?”

    Correct logic:

    • Practices should be adapted
    • Not all practices are mandatory
    • Context matters

    Answers implying:

    • All practices must be fully implemented
      Are incorrect.

    3. Key Things to Read / Remember Right Before the Exam

    Practices overview (high probability)

    • ITIL defines 34 practices
    • Grouped into three categories
    • Adapted to organisational context
    • Support value creation via the service value chain

    Common exam traps

    • Practices are prescriptive → False
    • All practices must be used → False
    • Practices operate independently → False

    One-line memory hook

    Practices are adaptable capability sets that support value creation, not a mandatory checklist.

  • 8.16. Service relationship management


    Service relationship management is the practice of establishing and nurturing the links between a service provider and its consumers.

    The purpose of service relationship management is to maintain positive and productive relationships with service consumers.

    Service relationship management focuses on communication, collaboration, and trust.

    It helps ensure that both the service provider and the service consumer understand their responsibilities.

    Effective service relationship management supports value co-creation and long-term success.


    2. How This Applies to TakeCars (Car Rental Marketplace)

    This video brings together many earlier concepts and explains how they are sustained over time in a marketplace environment.

    a) Service relationship management is the “trust engine” of TakeCars

    TakeCars does not succeed by single transactions.
    It succeeds by:

    • Repeat bookings
    • Long-term hosts
    • Reduced disputes
    • Predictable behaviour on all sides

    Service relationship management is what enables this.


    b) What service relationship management looks like in TakeCars

    Communication

    • Clear, consistent messaging
    • No surprises in rules or pricing
    • Timely updates when issues occur

    Poor communication destroys trust faster than technical failure.


    Collaboration

    • Hosts treated as partners, not inventory
    • Customers guided, not blamed
    • Support empowered to resolve issues, not just close tickets

    Collaboration directly affects outcome quality.


    Trust

    • Fair dispute resolution
    • Consistent rule enforcement
    • Transparent decisions

    Trust is cumulative and fragile.


    c) Responsibilities must be understood by all parties

    Many TakeCars problems come from:

    • Guests not understanding their obligations
    • Hosts misunderstanding platform rules
    • Platform expectations not being explicit

    Service relationship management exists to prevent this confusion.


    d) Exam-critical insight

    If the exam asks:

    “What is the purpose of service relationship management?”

    Correct logic:

    • Maintain positive, productive relationships
    • Support communication, collaboration, and trust
    • Enable value co-creation

    Answers that focus only on contracts or enforcement are incomplete.


    3. Key Things to Read / Remember Right Before the Exam

    Service relationship management (high probability)

    • A practice
    • Focuses on relationships, not transactions
    • Emphasises communication, collaboration, and trust
    • Supports long-term value co-creation

    Common exam traps

    • Relationship management is optional → False
    • Relationship management is one-way → False
    • Relationship management replaces SLAs → False

    One-line memory hook

    Service relationship management sustains trust so value can be co-created over time.

  • 8.15. Service level agreements

    Service level agreements should focus on outcomes, not just activities.

    Defining service levels based only on activities can lead to services that appear busy but do not deliver value.

    Outcome-based service levels help ensure that services support customer objectives.

    Service level agreements should be realistic, measurable, and clearly understood by all parties.

    Regular review of service level agreements helps ensure they remain aligned with business needs.


    2. How This Applies to TakeCars (Car Rental Marketplace)

    This video reinforces a core ITIL principle that is especially relevant for marketplaces: measuring the right thing.

    a) Activity-based vs outcome-based SLAs at TakeCars

    Activity-based SLAs (weak):

    • Number of emails sent
    • Tickets closed per day
    • Messages replied to

    These can be met while customers remain unhappy.


    Outcome-based SLAs (strong):

    • Percentage of bookings confirmed within X time
    • Percentage of trips completed without incidents
    • Refunds completed within Y days
    • Customer satisfaction after trip completion

    These reflect real value.


    b) Why TakeCars must avoid activity-only thinking

    A support team can:

    • Close tickets quickly
    • Send many messages

    And still fail to:

    • Resolve pickup issues
    • Prevent cancellations
    • Restore trust

    ITIL explicitly warns against this trap.


    c) Practical TakeCars examples

    • SLA: “Support responds within 2 hours”
      Activity-based, weak on its own
    • SLA: “Pickup issues resolved before rental start time in 95% of cases”
      Outcome-based, value-focused

    The second aligns directly with customer objectives.


    d) Exam-critical insight

    If the exam asks:

    “What should SLAs focus on?”

    Correct answer:

    • Outcomes
    • Value
    • Customer objectives

    Answers focused only on effort or activity are incorrect.


    3. Key Things to Read / Remember Right Before the Exam

    Outcome-based service levels (high probability)

    • SLAs should focus on outcomes
    • Activities alone do not guarantee value
    • Measurable and realistic targets matter

    Common exam traps

    • More activity equals better service → False
    • SLAs should measure effort → False

    Always choose:

    • Outcome-oriented wording

    One-line memory hook

    Busy services do not equal valuable services; outcomes define success.

  • 8.14. Service agreements


    Service level agreements are only one type of service agreement.

    Other types of service agreements may include operational level agreements and underpinning contracts.

    Operational level agreements are agreements between different parts of the same organisation.

    Underpinning contracts are agreements with external suppliers that support service delivery.

    All types of service agreements should be aligned to ensure consistent service performance.

    Clear alignment between agreements helps avoid gaps or conflicts in service delivery.


    2. How This Applies to TakeCars (Car Rental Marketplace)

    This video explains why SLAs alone are not enough and why alignment across agreements is critical in a multi-party marketplace like TakeCars.

    a) Three agreement layers in TakeCars terms

    Even if not formally documented, all three exist.


    1. Service Level Agreements (SLA)

    Between:

    • TakeCars and customers
    • TakeCars and hosts (implicitly)

    Examples:

    • Confirmation time expectations
    • Refund handling promises
    • Support availability

    These define what customers expect.


    2. Operational Level Agreements (OLA)

    Internal agreements within TakeCars.

    Examples:

    • Support team response targets
    • Escalation timelines
    • Engineering response to incidents

    If internal teams cannot meet these, external SLAs will fail.


    3. Underpinning Contracts (UC)

    Agreements with external suppliers.

    Examples:

    • Payment processors
    • Insurance providers
    • Cloud hosting
    • Verification services

    These underpin TakeCars’ ability to meet its SLAs.


    b) Alignment failure is a common marketplace problem

    Typical failure pattern:

    • SLA promises refunds in 3 days
    • Payment provider settles in 5 days
    • Support team is blamed

    This is an underpinning contract misalignment, not a support failure.


    c) Why alignment matters more as TakeCars scales

    As volume increases:

    • Small mismatches turn into systemic failures
    • Manual workarounds stop working
    • Customer trust erodes quickly

    ITIL’s emphasis on alignment is very practical here.


    d) Exam-critical insight

    If the exam asks:

    “Why must service agreements be aligned?”

    Correct logic:

    • To ensure consistent service delivery
    • To avoid gaps and conflicts
    • To support achievement of service levels

    Any answer implying SLAs operate in isolation is incorrect.


    3. Key Things to Read / Remember Right Before the Exam

    Types of service agreements (must be recognised)

    • Service Level Agreements (SLA)
    • Operational Level Agreements (OLA)
    • Underpinning Contracts (UC)

    Know who they are between.


    Alignment principle (high probability)

    • All agreements must support each other
    • Misalignment causes service failure
    • Alignment supports consistent performance

    Common exam traps

    • SLAs are the only service agreement → False
    • OLAs are external → False
    • Underpinning contracts are optional → False

    One-line memory hook

    SLAs promise value, OLAs enable delivery, and underpinning contracts make it possible.


  • 8.13. Service level agreement

    Service level agreements are documented agreements between a service provider and a service consumer.

    Service level agreements describe the services to be provided and the agreed service levels.

    They define responsibilities and expectations for both the service provider and the service consumer.

    Service level agreements may include targets, metrics, roles, escalation paths, and review mechanisms.

    Service level agreements should be clear, realistic, and aligned with business needs.

    They should be reviewed regularly and updated when requirements or circumstances change.


    2. How This Applies to TakeCars (Car Rental Marketplace)

    This video clarifies what SLAs are and what they are not, which is essential in a marketplace where formal contracts are often lightweight or implicit.

    a) SLAs at TakeCars are mostly implicit but still real

    Even without a signed PDF called “SLA”, TakeCars operates with SLAs embedded in:

    • Terms and conditions
    • Help centre articles
    • Booking confirmation messages
    • Host onboarding rules

    Customers and hosts behave as if SLAs exist, whether you formalise them or not.


    b) What an SLA looks like in TakeCars terms

    A TakeCars-style SLA typically defines:

    • What service is provided
      • Platform access
      • Booking handling
      • Support availability
    • Service levels
      • Confirmation time
      • Support response time
      • Refund turnaround
    • Responsibilities
      • What TakeCars does
      • What hosts must do
      • What customers must do
    • Escalation
      • When issues are escalated
      • Who makes final decisions

    Lack of clarity in any of these leads directly to disputes.


    c) Realistic and business-aligned SLAs matter

    Over-promising creates:

    • Support overload
    • Host churn
    • Customer dissatisfaction when promises are missed

    Under-promising creates:

    • Lost conversions
    • Perception of low quality

    ITIL’s emphasis on “clear and realistic” is especially important for TakeCars.


    d) Review and adaptation in a marketplace

    As TakeCars evolves:

    • New cities
    • New host types
    • Seasonal demand spikes

    SLAs must evolve as well. Static expectations break under growth.


    e) Exam-critical insight

    If the exam asks:

    “What do SLAs do?”

    Correct logic:

    • Document agreed service levels
    • Clarify responsibilities and expectations
    • Support consistent service delivery

    Answers implying SLAs:

    • Guarantee outcomes
    • Eliminate disputes
      Are incorrect.

    3. Key Things to Read / Remember Right Before the Exam

    Service level agreements (high probability)

    • Documented agreements
    • Between provider and consumer
    • Define services, service levels, and responsibilities
    • Reviewed and updated as needed

    SLA vs service level management

    • SLA: the document
    • Service level management: the practice that manages and reviews SLAs and performance

    Do not confuse the two.


    Common exam traps

    • SLAs are permanent → False
    • SLAs guarantee value → False
    • SLAs replace service level management → False

    One-line memory hook

    SLAs document expectations; service level management ensures they are met.

  • 8.12. Service level management


    Service level management is the practice of setting clear business-based targets for service performance.

    The purpose of service level management is to ensure that service levels are achieved and that services deliver value to customers.

    Service level management involves negotiating, agreeing, monitoring, and reporting on service levels.

    Service level management helps align service performance with customer expectations and business needs.

    It supports continual improvement by identifying gaps between agreed service levels and actual performance.


    2. How This Applies to TakeCars (Car Rental Marketplace)

    This video moves from what service levels are to how they are actively managed, which is critical for scaling a marketplace.

    a) Service level management at TakeCars = expectation control

    In TakeCars terms, service level management is about:

    • Deciding what reliability looks like
    • Communicating it clearly
    • Measuring whether it is achieved
    • Acting when it is not

    Without this, expectations drift and dissatisfaction grows.


    b) Practical service level management activities in TakeCars

    Negotiating and agreeing

    • Defining realistic confirmation times
    • Setting host response expectations
    • Clarifying support availability

    Even if not a formal SLA, this happens through:

    • Terms
    • Help pages
    • Booking confirmations

    Monitoring

    • Booking confirmation time
    • Host cancellation rates
    • Support response times
    • Refund turnaround time

    These metrics must reflect business impact, not just activity.


    Reporting

    • Internal dashboards for operations
    • Host performance summaries
    • Trend reports to identify deterioration

    Reporting without action has no value.


    Acting on gaps

    • Coaching or restricting underperforming hosts
    • Improving automation
    • Adjusting policies if targets are unrealistic

    This links directly to continual improvement.


    c) Exam-critical insight

    If the exam asks:

    “What is the purpose of service level management?”

    Correct logic:

    • Ensure agreed service levels are achieved
    • Align performance with customer and business needs
    • Support continual improvement

    Answers focusing only on documentation or reporting are incomplete.


    3. Key Things to Read / Remember Right Before the Exam

    Service level management (high probability)

    • A practice, not just an agreement
    • Sets, monitors, and reports on service levels
    • Ensures services deliver value
    • Supports continual improvement

    Service levels vs service level management

    • Service levels: performance targets
    • Service level management: the practice that manages them

    This distinction is frequently tested.


    Common exam traps

    • Service level management is only about SLAs → False
    • Service level management is reactive only → False
    • Service level management is purely technical → False

    One-line memory hook

    Service level management actively aligns service performance with expectations and value.

  • 8.11. Service levels


    Service levels are defined targets for the performance of a service.

    Service levels are agreed between the service provider and the service consumer.

    Service level agreements document service levels and define what is expected from the service.

    Service levels should be based on business needs and customer expectations.

    Monitoring service levels helps ensure that services are delivering the expected value.

    If service levels are not met, improvement actions may be required.


    2. How This Applies to TakeCars (Car Rental Marketplace)

    This video explains how expectations are formalised and why ambiguity here creates disputes and dissatisfaction.

    a) Service levels in TakeCars terms

    Service levels answer questions such as:

    • How quickly should a booking be confirmed?
    • How fast should support respond?
    • What reliability level is expected from hosts?
    • What happens when expectations are not met?

    Even if undocumented, service levels always exist. If they are not explicit, customers invent their own.


    b) Explicit vs implicit service levels

    Explicit service levels

    • Confirmation within a stated time window
    • Support response within X hours
    • Refund processed within Y days

    These reduce uncertainty and disputes.

    Implicit service levels

    • “I assumed the car would be there”
    • “I expected immediate support”
    • “I thought cancellations were impossible”

    Implicit expectations are dangerous because they are invisible until broken.


    c) Marketplace-specific service level complexity

    TakeCars must manage layered service levels:

    • Platform service levels (availability, support)
    • Host service levels (response time, reliability)
    • Third-party service levels (payments, insurance)

    Failures often occur at handovers between these layers.


    d) Exam-critical insight

    If the exam asks:

    “What are service levels?”

    Correct logic:

    • Defined targets for service performance
    • Agreed between provider and consumer
    • Based on business needs and expectations

    Answers implying:

    • Service levels are internal only
    • Service levels are fixed and universal
      Are incorrect.

    3. Key Things to Read / Remember Right Before the Exam

    Service levels (high probability)

    • Defined performance targets
    • Agreed with service consumers
    • Based on business and customer needs
    • Monitored and reviewed

    Service level agreements (SLA) nuance

    • SLAs document service levels
    • SLAs do not create value by themselves
    • Value comes from meeting the agreed levels

    Common exam traps

    • Service levels are optional → False
    • Service levels are purely technical → False
    • Service levels never change → False

    One-line memory hook

    Service levels formalise expectations and make performance measurable.


  • 8.10. Constraints


    Constraints are factors that limit or restrict the way a service can be used.

    Constraints may be related to policies, regulations, technology, resources, or skills.

    Removing or reducing constraints can increase the value of a service.

    However, some constraints are necessary to manage risks or comply with legal and regulatory requirements.

    Service providers should understand which constraints affect service consumers and how these constraints impact outcomes.

    Balancing constraints and freedom of use is essential for effective service management.


    2. How This Applies to TakeCars (Car Rental Marketplace)

    This video explains why friction exists and how it should be handled deliberately, not accidentally.

    a) Constraints in TakeCars terms

    Constraints are not always failures. They are often intentional.

    Common TakeCars constraints:

    • Age limits
    • Deposit requirements
    • Mileage limits
    • Geographic restrictions
    • Insurance exclusions
    • Time-bound pickups and returns

    These constraints shape how the service can be used.


    b) Good constraints vs bad constraints

    Necessary constraints

    • Protect vehicles and hosts
    • Manage insurance risk
    • Ensure legal compliance
    • Reduce fraud and misuse

    Examples:

    • Minimum driver age
    • Identity verification
    • Damage liability rules

    These constraints preserve warranty.


    Harmful or accidental constraints

    • Overly complex rules
    • Hidden exclusions
    • Manual approvals that delay pickups
    • Poorly explained policies

    These constraints destroy:

    • Utility (cannot use the service as intended)
    • Perceived value (frustration outweighs benefit)

    c) Constraint removal as a value lever

    Increasing value at TakeCars often means:

    • Removing unnecessary steps
    • Simplifying rules
    • Making constraints visible and predictable

    Examples:

    • Clear upfront deposit explanation
    • Standardised pickup instructions
    • Default policies instead of case-by-case decisions

    This aligns directly with ITIL’s guidance.


    d) Exam-critical insight

    If the exam asks:

    “What is the role of constraints in service management?”

    Correct logic:

    • Constraints limit service use
    • Some constraints reduce value
    • Some constraints are necessary for risk and compliance
    • Balance is required

    Answers implying “constraints should always be removed” are incorrect.


    3. Key Things to Read / Remember Right Before the Exam

    Constraints definition (high probability)

    • Factors that limit or restrict service use
    • Can be technical, legal, policy-based, or resource-based

    Exam traps

    • All constraints reduce value → False
    • Constraints should be eliminated → False
    • Constraints are always negative → False

    Look for balanced wording:

    • “Remove unnecessary constraints”
    • “Manage constraints appropriately”

    One-line memory hook

    Constraints shape how a service is used; the goal is balance, not elimination.

  • 8.9. Utility and warranty – detailed


    Utility and warranty are influenced by several factors.

    Utility may be affected by whether the service supports the required outcomes and removes constraints for the service consumer.

    Warranty may be affected by availability, capacity, continuity, and security.

    Availability refers to whether the service is accessible when needed.

    Capacity refers to whether the service has sufficient resources to meet demand.

    Continuity refers to whether the service can continue to operate during disruptions.

    Security refers to whether information and assets are protected.

    Service providers must consider these factors to ensure that services deliver value.


    2. How This Applies to TakeCars (Car Rental Marketplace)

    This video explains what actually makes utility and warranty succeed or fail in practice.

    a) Utility drivers in TakeCars

    Utility depends on:

    • The service supporting the trip purpose
    • Constraints being removed

    Examples:

    • Correct car type for terrain and group size
    • Location aligned with travel plan
    • Clear rules that do not block usage

    Utility fails when:

    • Car restrictions block planned use
    • Pickup location is impractical
    • Terms are unclear or restrictive

    b) Warranty drivers mapped to TakeCars

    Availability

    • Is the car actually available at the agreed time?
    • Are backups in place if a host cancels?

    Capacity

    • Are there enough cars during peak season?
    • Can support handle spikes in issues?

    Continuity

    • Can TakeCars operate during:
      • Host no-shows
      • Platform outages
      • Payment failures

    Security

    • Are payments protected?
    • Is customer data secure?
    • Are vehicles protected against misuse?

    All four are explicitly named in ITIL exams.


    c) Marketplace failure patterns

    Most negative experiences come from warranty failures:

    • Availability failure: host cancels
    • Capacity failure: no cars during holidays
    • Continuity failure: support unreachable
    • Security failure: payment or data issue

    Utility may be perfect, but value is still lost.


    d) Exam-critical insight

    If the exam asks:

    “What influences warranty?”

    Correct answers will reference:

    • Availability
    • Capacity
    • Continuity
    • Security

    If any of these appear, they are almost certainly correct.


    3. Key Things to Read / Remember Right Before the Exam

    Warranty factors (must be memorised)

    • Availability
    • Capacity
    • Continuity
    • Security

    Exact wording matters.


    Utility factors

    • Supports outcomes
    • Removes constraints

    Utility is about purpose, not reliability.


    Common exam traps

    • Warranty equals quality alone → False
    • Utility is about reliability → False

    One-line memory hook

    Utility defines purpose; warranty ensures reliability through availability, capacity, continuity, and security.

  • 8.8. Utility / Warranty

    Utility describes what a service does and how it meets a customer’s needs.

    Utility is often described as “fit for purpose”.

    Warranty describes how a service is delivered and whether it can be relied upon.

    Warranty is often described as “fit for use”.

    Both utility and warranty are required for a service to deliver value.

    A service with utility but no warranty will not deliver value.

    A service with warranty but no utility will also not deliver value.

    Service providers must ensure that services deliver both utility and warranty.


    2. How This Applies to TakeCars (Car Rental Marketplace)

    This video introduces one of the most exam-tested ITIL concepts and one of the most practical lenses for judging service quality.

    a) Utility vs warranty in plain TakeCars terms

    Utility = fit for purpose

    What the service actually enables.

    For TakeCars:

    • The car is the right type
    • The location matches the trip
    • The booking meets the travel need

    If the customer needs:

    • A family car
    • For a road trip
    • With enough luggage space

    Utility fails if the car cannot meet that purpose.


    Warranty = fit for use

    How reliably the service is delivered.

    For TakeCars:

    • Car is available on time
    • Car is roadworthy
    • Insurance is valid
    • Support is available if something goes wrong

    A perfect car that never shows up has utility but no warranty.


    b) Why both are required

    Examples:

    • Cheap car, wrong size, but always available
      • Warranty present
      • Utility missing
      • No value
    • Perfect car, correct spec, but host cancels last minute
      • Utility present
      • Warranty missing
      • No value

    Only when both exist does value emerge.


    c) Marketplace-specific insight

    Marketplaces often focus on:

    • Utility (more listings, more options)

    But customers churn because of:

    • Warranty failures (cancellations, breakdowns, poor support)

    This is why:

    • Host reliability
    • Response times
    • Backup processes

    Matter as much as search and pricing.


    d) Exam-critical insight

    If an exam question asks:

    “What is required for a service to deliver value?”

    Correct answer:

    • Both utility and warranty

    Any answer suggesting one alone is sufficient is incorrect.


    3. Key Things to Read / Remember Right Before the Exam

    Utility vs warranty definitions (very high probability)

    • Utility: what the service does, fit for purpose
    • Warranty: how the service is delivered, fit for use

    Exact phrasing matters.


    Common exam traps

    • Utility alone delivers value → False
    • Warranty alone delivers value → False

    Look for answers that explicitly include both.


    One-line memory hook

    Utility enables the outcome; warranty ensures it can be relied upon.