Buying services is difficult when the service is not clearly described.
A supplier can price a product by looking at a drawing, part number, quantity, or technical specification. But a service is often less visible. It may include people, time, knowledge, systems, response times, reports, responsibilities, locations, tools, and assumptions.
If the buyer sends an RFQ without a clear Service Description, suppliers will fill in the gaps themselves. One supplier may assume a basic service. Another supplier may include reporting, project management, backup staffing, training, quality follow-up, or extended support. The prices may look comparable, but they are not based on the same requirement.
This is why the Service Description is one of the most important documents in a service RFQ. It helps suppliers understand what the buyer needs, how the service should be delivered, and what must be included in the quotation.
In this article, you will learn what a Service Description is, why it matters in procurement, how it connects to RFQ, SOW, and SLA, and what buyers should include before asking suppliers for prices.
LHTS framework connection
Role: Tactical procurement
Supporting roles: Operative procurement and procurement management
Process: Need definition, RFQ preparation, service specification, supplier quotation, supplier evaluation, contract preparation, supplier performance follow-up
Level: Basic
Related course: Sourcing process 1
Supporting learning: RFQ Template, Statement of Work, Service Level Agreement, Supplier Evaluation
Quick answer: What is a Service Description?
A Service Description is a procurement document that explains the service the buyer wants to purchase.
It describes what the service is, where it will be delivered, who will use it, what is included, what is excluded, which requirements apply, and what information suppliers need in order to quote correctly.
In an RFQ, the Service Description helps suppliers understand the requirement and submit comparable offers. Without it, suppliers may quote based on different assumptions.
The problem: unclear services create unclear supplier prices
Many service RFQs fail because the buyer asks for a price before the service is properly defined.
For example, a buyer may ask suppliers to quote for “IT support,” “cleaning services,” “maintenance,” “consulting support,” “transport services,” or “reception services.”
These phrases are not enough.
Suppliers need to understand:
- how large the service is
- what is included
- what is excluded
- when the service must be delivered
- where the service will be performed
- what systems, tools, or resources are required
- what service volumes are expected
- what quality level is required
- what reporting is needed
- what the buyer will provide
- what the supplier is responsible for
Without this information, suppliers must guess. That makes the RFQ weak and the price comparison unreliable.
A low price may simply mean that the supplier has excluded work the buyer expects to be included.
Why Service Descriptions matter in RFQs
A Service Description gives structure to the RFQ. It helps both buyer and supplier understand the same requirement.
A good Service Description helps the buyer:
- create comparable supplier offers
- reduce unclear assumptions
- avoid scope creep
- improve quotation accuracy
- evaluate suppliers on service content, not only price
- reduce disputes after contract award
- define what should be included in the contract
- support supplier performance follow-up
For suppliers, the Service Description explains what they are expected to deliver. It helps them decide whether they can provide the service and how they should price it.
A strong Service Description improves the quality of supplier responses before negotiation even starts.
How Service Description, SOW, and SLA work together
Service Description, Statement of Work, and Service Level Agreement are connected, but they are not exactly the same.
Service Description
The Service Description explains what service the buyer wants to purchase.
It gives the supplier the practical picture of the service need.
Example:
“The buyer requires IT support for approximately 300 workstation users, including remote support for software issues and on-site support for hardware-related problems.”
Statement of Work
The Statement of Work, or SOW, defines the work to be performed, deliverables, responsibilities, timelines, assumptions, and acceptance criteria.
Example:
“The supplier shall provide incident handling, routine workstation support, monthly reporting, maintenance activities, and documented escalation according to the agreed process.”
Service Level Agreement
The Service Level Agreement, or SLA, defines how well the supplier must perform the service.
Example:
“Critical incidents must be responded to within one hour. Server uptime shall be 99.9% outside planned maintenance. Customer satisfaction shall be at least 95%.”
In simple terms:
Service Description: What service are we buying?
Statement of Work: What work and deliverables are included?
SLA: How well must the service perform?
For many service RFQs, the buyer should include all three or combine them in a clear RFQ package.
How this connects to the tactical procurement role
The Service Description is mainly connected to the tactical procurement role because tactical buyers often prepare RFQs, collect quotations, evaluate suppliers, and support contract preparation.
The tactical buyer does not always write the full Service Description alone. The internal stakeholder, service owner, project manager, or technical expert usually provides important input.
But the tactical buyer should make sure the Service Description is clear enough for sourcing.
The tactical buyer should ask:
- Is the service described clearly?
- Can suppliers understand what they are pricing?
- Are service volumes stated?
- Are locations and service hours clear?
- Are responsibilities divided between buyer and supplier?
- Are exclusions stated?
- Are quality requirements included?
- Is the SOW needed?
- Is the SLA needed?
- Can we compare supplier offers based on this information?
This is how procurement creates value before negotiation. A well-structured Service Description reduces uncertainty and improves supplier responses.
How this connects to operative procurement
Operative procurement may become involved after the contract is signed, especially when services are ordered, confirmed, received, approved, or invoiced.
A weak Service Description can create operative problems such as:
- unclear purchase orders
- disputes about what was ordered
- invoices for extra work
- difficulty confirming service completion
- unclear supplier contact routes
- inconsistent service delivery
- internal complaints
- blocked invoices
A strong Service Description makes day-to-day follow-up easier because it explains what the supplier is expected to provide.
How this connects to procurement management
Procurement management should make sure that service buying follows a structured method.
This can include:
- standard templates for Service Descriptions
- RFQ package checklists
- guidance for when SOW and SLA are required
- approval routines for high-value or high-risk services
- contract attachment standards
- supplier performance review routines
- lessons learned after contract completion
For management, Service Descriptions are not only documents. They are part of procurement governance. They help the organization control external service spend and reduce unclear commitments.
Where the Service Description fits in the procurement process
The Service Description should be created before the RFQ is sent to suppliers.
1. Need definition
The internal stakeholder explains the business need. Procurement helps turn that need into a clear service requirement.
2. Service Description preparation
The buyer and stakeholder define the service in practical terms. This includes scope, service users, locations, volumes, service hours, responsibilities, standards, and key assumptions.
3. RFQ package
The Service Description is included in the RFQ package together with supplier instructions, pricing format, contract terms, evaluation criteria, and any SOW or SLA.
4. Supplier questions
Suppliers review the Service Description and ask questions. These questions are useful because they reveal unclear areas before quotations are submitted.
5. Supplier quotation
Suppliers quote based on the Service Description. They should state assumptions, exclusions, proposed delivery model, resources, and deviations.
6. Supplier evaluation
The buyer evaluates whether suppliers understood the service and whether their offer covers the required scope.
7. Negotiation
The Service Description may be clarified during negotiation. Any final changes should be documented.
8. Contract preparation
The final Service Description should become part of the signed contract or be reflected in a SOW, SLA, or contract appendix.
9. Supplier performance follow-up
After award, the Service Description helps the buyer and supplier understand what was agreed and what should be delivered.
What should be included in a Service Description?
The level of detail depends on the type and complexity of the service. A simple service may need a short description. A complex service may require a detailed description supported by a SOW and SLA.
A practical Service Description should include the following sections.
1. Background and purpose
Explain why the service is needed and what business problem it should solve.
Example:
“The buyer requires external IT support to ensure stable workstation support, fast incident handling, and reliable maintenance for daily corporate operations.”
2. Service scope
Describe what the service includes.
This may include tasks, activities, support areas, service categories, deliverables, or responsibilities.
3. Exclusions
State what is not included.
This is important because suppliers often price based on what they believe is excluded. Clear exclusions reduce misunderstandings.
4. Service users or volumes
Define the size of the service.
Examples:
- number of users
- number of locations
- number of service hours
- number of tickets
- number of machines
- number of cleaning areas
- number of deliveries
- expected monthly volume
5. Locations
State where the service will be delivered.
This may include on-site locations, remote delivery, multiple countries, warehouses, offices, production sites, or customer locations.
6. Service hours
Define when the service must be available se also SLA).
Examples:
- office hours
- shift-based operations
- 24/7 support
- weekend coverage
- emergency support
- public holiday requirements
7. Technical and operational requirements
Describe systems, tools, methods, standards, processes, or technical requirements the supplier must follow.
8. Quality requirements
Define quality expectations.
This may include standards, certifications, inspection routines, customer satisfaction, error rates, documentation requirements, or performance expectations.
9. Buyer responsibilities
State what the buyer will provide.
Examples:
- access to facilities
- internal contact person
- data
- equipment
- system access
- drawings
- approvals
- policies
- safety instructions
10. Supplier responsibilities
State what the supplier must provide.
Examples:
- personnel
- tools
- supervision
- training
- insurance
- reporting
- documentation
- escalation process
- replacement resources
11. Reporting and communication
Explain what reports, meetings, and communication routines are required.
12. Security, confidentiality, and compliance
Include relevant requirements for data protection, confidentiality, safety, environmental compliance, labor standards, or regulatory obligations.
13. Pricing information needed
The Service Description should help suppliers price correctly. The RFQ may also ask for a specific price format, such as hourly rate, fixed monthly fee, price per ticket, price per visit, or price per deliverable.
14. Related SOW or SLA
If the service requires detailed deliverables or measurable service levels, the Service Description should refer to the SOW and SLA.
Practical example: Service Description for IT support
Below is an example of how a Service Description for IT support can be structured.
Background and purpose
The buyer requires ongoing IT support to ensure stable daily operations for approximately 300 workstation users and related corporate systems.
Service scope
The supplier shall provide IT support for workstation users, including incident handling, troubleshooting, user support, peripheral support, routine updates, and basic maintenance activities.
Technical requirements
The service shall support Windows 11 and macOS workstations, associated peripherals, standard office software, and agreed corporate applications.
Service availability
The supplier shall provide support during agreed service hours. Critical support requirements and response times shall be defined in the SLA.
On-site and remote support
Remote support is acceptable for software issues and troubleshooting. On-site support is required for hardware-related issues when remote support is not sufficient.
Quantity and volume
The service covers approximately 300 users. Suppliers should state how their staffing model supports this volume.
Quality standards
The supplier shall document all maintenance and incident responses in the agreed IT service management platform. Customer satisfaction and service performance shall be reported monthly.
Reporting
The supplier shall provide monthly reporting on incident management, user satisfaction, system stability, and improvement actions.
Security and confidentiality
The supplier must follow the buyer’s IT security policy, confidentiality requirements, and data protection rules.
This type of Service Description gives suppliers enough information to understand the service and prepare a structured quotation.
Weak Service Description versus strong Service Description
Weak Service Description
“We need IT support for our employees.”
This is too vague. It does not explain number of users, systems, service hours, location, support type, response expectations, security requirements, or reporting.
Stronger Service Description
“The buyer requires IT support for approximately 300 workstation users across one headquarters location and two regional offices. The service includes remote support for software issues, on-site support for hardware-related problems, routine workstation maintenance, documentation in the buyer’s ITSM system, monthly reporting, and compliance with the buyer’s IT security policy. Service levels for response time, uptime, and customer satisfaction are defined in the attached SLA.”
This version gives suppliers a clearer basis for pricing and delivery planning.
How suppliers use the Service Description
Suppliers use the Service Description to decide how to respond to the RFQ.
A strong supplier response may include:
- confirmation of understanding
- proposed service delivery model
- staffing or resource plan
- tools and systems
- assumptions
- exclusions
- pricing model
- implementation plan
- reporting approach
- deviations from the requirement
- suggestions for improvement
- references from similar services
If the Service Description is weak, supplier responses will be inconsistent. If the Service Description is strong, the buyer can evaluate both price and service model more effectively.
Common mistakes when writing Service Descriptions
Mistake 1: Describing the service too generally
A broad phrase such as “maintenance service” or “IT support” is not enough. Suppliers need details to quote properly.
Mistake 2: Forgetting service volumes
Without volume information, suppliers cannot estimate resources or price accurately.
Mistake 3: Not stating exclusions
If exclusions are not stated, the buyer and supplier may later disagree about what was included in the price.
Mistake 4: Mixing Service Description, SOW, and SLA without structure
These documents can overlap, but the buyer should still be clear about what each document controls.
Mistake 5: Ignoring buyer responsibilities
The supplier may depend on the buyer for access, information, approvals, systems, or site readiness. These responsibilities should be visible.
Mistake 6: Not including reporting requirements
If reporting is expected, it should be described before the supplier prices the service.
Mistake 7: Leaving quality expectations unclear
Quality requirements should be stated in a way that suppliers can understand and, where possible, measure.
Mistake 8: Sending the RFQ before the service owner has reviewed the description
The internal service owner should confirm that the Service Description reflects the real business need before the RFQ is issued.
Link to related course: Sourcing process 1
If you want to go deeper into how service requirements are turned into RFQ documents, the Learn How to Source course Sourcing process 1 is the most relevant next step.
A Service Description is one of the key inputs to a strong RFQ. It helps buyers define the need, collect comparable offers, evaluate suppliers, and prepare the final agreement.
This topic also connects naturally to the RFQ Template, Statement of Work, and Service Level Agreement learning areas.
FAQ: Service Description in procurement
What is a Service Description in procurement?
A Service Description is a document that explains the service the buyer wants to purchase. It describes the scope, users, volumes, locations, service hours, requirements, responsibilities, and other information suppliers need to quote correctly.
Why is a Service Description important in an RFQ?
A Service Description helps suppliers understand the requirement and submit comparable quotations. Without it, suppliers may quote based on different assumptions.
What should be included in a Service Description?
A Service Description should include background, service scope, exclusions, service users or volumes, locations, service hours, technical requirements, quality requirements, buyer responsibilities, supplier responsibilities, reporting, compliance needs, and any related SOW or SLA.
What is the difference between Service Description and Statement of Work?
The Service Description explains what service the buyer wants to buy. The Statement of Work defines the work, deliverables, responsibilities, assumptions, and acceptance criteria in more detail.
What is the difference between Service Description and SLA?
The Service Description explains what service is required. The SLA defines how well the supplier must perform the service, including service levels, KPIs, reporting, and escalation.
Should the Service Description be part of the contract?
Yes. The final Service Description should normally be included in or reflected in the signed contract, often as an appendix, schedule, SOW, or service specification.
Who should write the Service Description?
The Service Description should be prepared by procurement together with the internal stakeholder, service owner, technical expert, or project manager. Procurement structures the document, while the service owner confirms the business need.
Conclusion: define the service before asking for the price
A Service Description is one of the most important documents when buying services.
If the service is unclear, suppliers will make assumptions. Those assumptions create quotations that are difficult to compare, increase the risk of missing scope, and may lead to disputes after contract award.
The practical next step is to review your next service RFQ before sending it. Ask whether the service is clearly described, whether suppliers know what is included, whether volumes and locations are stated, whether responsibilities are clear, and whether a SOW or SLA is needed.
A strong Service Description helps buyers create better RFQs, receive better supplier offers, and build stronger contracts.