Compare the engagement models
| The handoff problem |
Partners to compare |
Scope to settle |
| Returns, fulfillment and physical delivery |
Livework, Engine, Manyone |
Policies, partners and frontline responsibility |
| A focused product and operations change |
David Spiegel, Method, Inviqa
 |
Product ownership and deployed software |
| Claims or complex cases |
Hellon, RGP, Nile, Gofore |
Exceptions, judgment and system dependencies |
| Staff tools and support resolution |
Designit, IDEO, Sutherland, Reaktor |
Employee workflows and ongoing operation |
| A connected service redesign |
frog, cxpartners, Koos, Tangity, Futurice, Solita |
Research, prototyping, implementation and adoption |
A customer has paid, booked or received confirmation. Now someone must schedule the appointment, prepare the order, deliver the service, explain a delay or resolve a problem. This is where a business can discover that its polished website and its internal processes tell different stories.
The buying question is specific: who can improve the handoffs between the product, the people delivering the service and the team helping customers when something goes wrong?
This guide compares 20 partners for that work. Some suit a focused project with an existing engineering team. Others suit a larger organization coordinating departments, locations and external suppliers.
We begin with service-design work that connects a customer promise to the departments and people delivering it. The opening examples address returns and physical service coordination; a focused product-and-operations engagement follows for a founder who already has delivery resources. Staff tools, claims and specialist service settings then provide different routes into the same handoff problem. We weigh the relevance of published work and the proposed responsibility, rather than company size or reported uplift. Project accounts establish scope; ask separately which recommendations reached implementation and what your own contract will deliver.
1. Livework for returns and refunds across departments
Livework is a service and business transformation consultancy whose work with adidas provides a particularly relevant example of post-purchase service design. Its account describes mapping the returns and refund journey with cross-functional teams, developing improvement concepts, testing prototypes with customers and using the findings to prioritize a roadmap. Livework’s adidas returns project
Consider Livework when the visible problem belongs to several departments. A customer asking about a refund may encounter a policy written by one team, a status maintained by another and an explanation supplied by customer service. The project needs a shared view of that entire experience.
Livework’s current offer includes project leadership and stewardship of multi-phase change programs. That gives buyers a reason to discuss both a focused journey project and a broader change effort. Livework’s delivery services
Ask for a proposal that connects the service blueprint to decisions: which policy, screen, message or operating procedure will change first? Establish who funds and implements those changes. The adidas account supports research, prototyping and roadmap work; it should not be read as proof that every resulting improvement was deployed.
2. Engine for coordination between digital and physical services
Engine is a customer experience and service design consultancy. Its Value Retail case follows a guest journey across planning, arrival, the shopping visit and departure. The work connected digital tools, hosts, concierge services and physical environments, then translated the experience into operating standards and a phased implementation roadmap. Engine’s Value Retail account
That makes Engine worth considering when the service is delivered by people in a place: a hospitality venue, an appointment business or a consumer service with a physical visit. A confirmation message is only useful if staff can recognize what was promised and deliver it when the customer arrives.
The important purchasing distinction is the operating model. A site redesign can improve what customers read; a service-design engagement can also define how reception, specialists and support coordinate around the visit.
Bring frontline staff and the person responsible for daily operations into discovery. Ask Engine to show how proposed interactions become usable instructions, responsibilities and rollout priorities. The published example establishes a vision and delivery plan; your contract should say whether implementation coaching, staff training and subsequent evaluation are included.
3. David Spiegel for product ownership across the handoff
David Spiegel is an independent product and growth consultant. His public profile describes joining 5 Axis Health as its first product hire, managing engineers and working across design, marketing, clinical and operations. The relevant detail is what happened beyond checkout: he identified fulfillment bottlenecks and changed the post-booking workflow with the teams responsible for delivering the service. David’s professional profile
That experience makes him a useful first conversation for a founder whose customer journey crosses software and operations. A paid order may be visible in the product while the team fulfilling it works from a separate queue. Improving that experience requires someone to connect the customer problem, the operating decision and the work engineers can ship.
David’s consulting offer includes diagnosing journeys, setting priorities, designing experiences and helping implement changes. Consider that model when you already have delivery capacity and want a direct product partner to establish what should change.
Bring the operations lead into the brief and agree who can change service rules. His telehealth experience supports a product and workflow assessment; clinical decisions remain with the appropriate professionals. If your organization needs a large research team across many locations, compare an agency scope alongside the individual engagement.
Designit is a design and experience consultancy. Its FedEx account describes work on fragmented operational workflows and overloaded interfaces. The team mapped the logistics environment, reorganized tasks and developed a design system used across operational applications. It is evidence of work on the employee-facing systems behind service delivery. Designit’s FedEx project
Consider Designit when customers experience delays because staff cannot easily see the next action, find the right information or understand the state of a case. A clearer customer status page may help, but the more consequential work could be inside the tools used to move the service forward.
Its Terminal 4 work at JFK adds a different perspective: research with passengers, employees and stakeholders informed an experience strategy and roadmap. Designit’s JFK Terminal 4 project
For this brief, ask Designit to connect the customer journey with the specific employee tasks obstructing it. Have the proposal name the applications, design work and engineering relationships involved. FedEx demonstrates operational interface work; Terminal 4 demonstrates strategy and concept development. Decide which kind of engagement your problem needs.
5. Hellon for consistent service promises and support
Hellon is a service design consultancy. Its Vodafone insurance account describes customer research, journey maps, service blueprints, co-creation and testing. The scope included how the insurance offer connected with telecom services, claims processes, communication and support. Hellon’s Vodafone project
This is relevant when a business has assembled several services but customers experience them as separate organizations. They may buy through one brand, receive instructions from another team and discover that support cannot explain what happens next.
Hellon is a useful comparison for work that needs research and agreement across those boundaries. A clear first assignment would be to map one customer request from confirmation through completion, identify conflicting promises and design how responsibility moves between the participating teams.
The brief should include service policies and staff practices alongside digital messages. Ask which teams will test the proposed approach and how unresolved cases will be escalated. If the main obstacle is already a known software integration defect, a directly commissioned engineering scope may be more appropriate. Choose service design when the unresolved question concerns how the whole service should work.
6. RGP for complex cases involving several roles
RGP is a consulting and project execution firm. Its insurer case connects three experiences: customers submitting and checking claims, sales partners supporting them, and employees processing the work. Its research led to an end-to-end service blueprint and recommendations covering document reuse, status communication, information access and employee workflows. RGP’s insurance service-design project
The model is relevant when a consumer service behaves like a case that travels through an organization. Different people need different information, while the customer expects one understandable account of progress.
RGP’s current human-centered design offer includes service and workflow prototyping, contextual research, journey mapping and cross-functional design sessions. RGP’s capabilities
Shortlist RGP when the work must fit into a broader operational change program. Give candidates a real example of a delayed case and ask how they would investigate the handoffs without losing the perspective of the person waiting.
The published insurer engagement chiefly establishes research, blueprinting and recommended changes. If you need deployed workflows, request an explicit delivery phase, named system owners and acceptance criteria. A blueprint is useful only when the organization can act on it.
7. frog for linking the app with the service
frog is a design and innovation consultancy within Capgemini Invent. Its IndiGo project concerns the relationship between an airline’s website and app and its wider travel experience. The published account describes research and redesign covering navigation, booking and travel management, with the aim of connecting physical and digital service. frog’s IndiGo project
Consider frog when customers manage an ongoing service through a digital product but the experience becomes confusing as soon as a real-world dependency changes. The relevant brief might cover how an account explains the next step, exposes available options and keeps service information understandable across channels.
The consultancy is a useful comparison for a substantial experience redesign spanning product strategy and design. Keep the first assignment tied to one consequential customer situation, such as changing an existing booking, rather than commissioning a general vision with no delivery boundary.
Ask which systems can supply reliable status information and who has authority to change the underlying service. The IndiGo case supports research and digital design. Confirm engineering, operational rollout and ongoing ownership separately, especially where another supplier controls part of the journey.
8. Inviqa for research connected to digital delivery
Inviqa combines a current research-led experience-design offer with digital product building and systems integration. Its approach includes service blueprints, prototypes, designs for engineering and ongoing evaluation. Inviqa’s experience-design approach and digital delivery offer
Its historical Virgin Trains case illustrates a specific handoff. The work included research with station staff and travelers, while Inviqa supported user testing for a JourneyCare feature that connected the ticket-buying experience with assistance arrangements previously handled through a separate form or helpline. Inviqa’s Virgin Trains account
That is a useful model when customers must leave the main product to arrange an essential part of the service. The buying question is how research, interfaces and integration will work together to make that next step manageable.
Consider Inviqa when the brief includes substantial digital implementation. Agree which systems the agency will change, which external suppliers it depends on and how the result will be maintained. The historical example demonstrates the kind of journey problem it has addressed; ask for a current team and delivery approach relevant to your platform.
9. Method for the operating work surrounding a customer interaction
Method’s McDonald’s project describes research and design across customer touchpoints and the operations around them. The work included a digital design system and prototyping in both controlled and real settings. Its services connect experience design with application development and organizational enablement.
Consider Method when a customer has completed an order but the service still depends on staff, queues or several channels. A prototype should show what the customer sees and what employees must do to make that promise true. Ask for a bounded service situation, such as collection or a changed order, and identify the operational decision makers. Confirm whether the engagement includes deployed software and staff adoption, alongside research and design. The published work supports a cross-functional discussion, rather than a guaranteed outcome for another business.
10. cxpartners for a service journey that needs organizational agreement
cxpartners’ service offer includes user research, service design, experience mapping and service blueprinting. It explicitly covers digital and non-digital experiences and work on organizational processes, tools and skills. That makes it relevant when post-purchase friction comes from several teams interpreting the service differently.
Compare a service-design engagement when support cannot resolve a problem without negotiating with operations or product. Start with one recurring customer request and ask the team to connect the visible journey with the decisions behind it. Who can change the process, and what will happen when the normal path fails? Agree on a practical implementation plan and the internal owners required to carry it out. Scope software construction separately if you need the partner to change systems as well as define the service.
11. Nile for claims and exception-heavy service processes
Nile’s insurance practice addresses claims and referral queues, including undocumented workarounds and the question of which decisions should remain with people. Its current offer distinguishes administrative work around a judgment from the judgment itself. That is directly relevant to a post-purchase service that becomes difficult when the customer’s case falls outside the standard process.
Consider Nile for a research-and-design assignment around exceptions, handoffs or automation in insurance. Bring a sample of ordinary and unusual cases and ask how staff actually move them forward. Establish what information is missing, where work is repeated and who can approve a change. The useful scope may include a prototype and an operating-model decision before a major build. Keep claims-policy and regulatory authority with the appropriate client owners.
12. Koos for connecting appointments with the patient-facing product
Koos’ healthcare practice identifies redesign work on the MyCUF app in the context of the medical appointment journey. Its broader service-design offer addresses customer experiences through a service-design approach. These are relevant references when booking is easy but the steps around receiving the service remain fragmented.
Compare Koos for a journey project involving patients, families and service staff. Choose a concrete moment such as preparing for an appointment, finding instructions or understanding the next action afterward. Ask how the project will bring the people delivering the service into research and testing. Confirm the boundary between customer-facing design, operational change and software delivery. A redesigned app must rely on accurate appointment information and a clear owner for communication when circumstances change.
13. Manyone for delivery journeys involving customers and external partners
Manyone’s service, product and CX practice includes frontstage and backstage mapping, service blueprints, prototypes and journey design. Its Deutsche Telekom example concerns an integrated fiber-rollout journey involving customers, landlords, contractors, partners and internal teams. That is a particularly relevant reference for a service sold before several parties must coordinate delivery.
Shortlist Manyone when the customer promise depends on a sequence that crosses organizational boundaries. Ask the team to map permissions, information and responsibility alongside the visible touchpoints. Which party confirms readiness, and who owns a stalled installation? Commission a defined journey with a testable operating sequence. Agree whether the engagement ends at detailed experience design or includes implementation support, and ensure external partners can participate before promising changes that depend on them.
14. IDEO for connecting support signals with product improvement
IDEO’s Motorola account describes using customer information to identify product problems and help support teams respond. One example concerns recognizing a pattern of complaints so the customer-support team could distribute instructions. The work connected design, engineering and service rather than treating support as an isolated destination after purchase.
Consider IDEO for a service-design and research engagement where recurring customer issues need to inform both immediate resolution and future product decisions. Ask what information the team would examine and how it would distinguish a product defect from confusing guidance. Agree on a practical response process and the owner who can change it. The cited project establishes a historical approach; ask for the current team and technical scope suitable for your own support systems.
15. Tangity for a service that crosses connected customer touchpoints
Tangity is an international network of strategy and design studios within NTT DATA. Its published work includes an end-to-end mobility assignment for Renfe and an innovation hub for Toyota Financial Services. Those references make it relevant to a service-design brief involving several customer touchpoints and organizational responsibilities.
Compare a strategy-and-design engagement when customers must manage an ongoing service after the initial transaction. Start with a specific situation, such as continuing a journey or requesting a change, and ask the proposed team to show its responsibility in a comparable assignment. Identify the systems and service rules that constrain the experience. Confirm who supplies research, implementation and rollout support; a network’s broad capabilities do not establish which disciplines your engagement includes. The first milestone should enable an actionable decision about the journey.
16. Sutherland for service design tied to customer-support operations
Sutherland’s customer-experience practice includes insight and design labs, CX engineering, contact-center services and knowledge management. Its stated scope covers service, retention and support across channels, with customer and employee journeys considered together. This is a useful distinction when a buyer needs an operating partner as well as a redesigned service.
Shortlist it for a substantial support transformation where the work must connect self-service, agents and back-office processes. Ask how the proposed journey will be tested with the people who handle difficult cases. Define resolution quality and repeated contacts alongside speed or automation. Separate design consulting from any ongoing operational contract so you can assess both purchases. Confirm the escalation path and who can change underlying policies when a better interface still cannot resolve the customer’s problem.
17. Futurice for service design that continues into digital development
Futurice’s human-centric service-design offer joins CX strategy, service design, product strategy and digital development. Its listed examples include railway passenger sales channels, airport lounges and passenger experiences for Tallink Silja. The relevant capability is designing the service experience while retaining a path to implementation.
Compare a multidisciplinary team when a confirmed customer journey crosses a digital product and a physical service. Ask how the team would investigate a changed trip, delayed service or missing instruction without reducing the problem to a new screen. Agree on a prototype that staff and customers can both try. Establish which systems Futurice will build or integrate and which remain with other suppliers. Include post-release learning in the scope if the operating process will change as the service is used.
18. Reaktor for resolving support requests through connected systems
Reaktor’s customer-service automation practice explicitly covers designing, building and running support platforms. It describes connecting order management, CRM, billing and logistics, while designing permissions, action validation and human escalation. That makes it relevant when the post-purchase problem is an inability to complete a request across fragmented systems.
Consider Reaktor when the assignment includes substantial engineering and you have a clear reason to examine automation. Start with one request that can be resolved end to end, such as finding a return’s status or completing an approved account action. Ask how the system will handle missing data, an incorrect action and a customer’s request for a person. Agree on evaluation and ongoing ownership before release. Measure successful resolution and reopened cases alongside any reduction in human handling.
19. Solita for changing the operating model behind a service journey
Solita’s service-design practice takes a multichannel view covering customer needs, service production, business and technology. It describes using customer insight to identify bottlenecks, co-design improvements and change operating models. Its offer includes developing internal service-design capability as well as project work.
Compare Solita when improving the experience requires more than a one-time blueprint. A subscription, transport or appointment service may need a continuing way to decide which journey problem to fix next and how to measure it. Ask for one concrete customer situation to anchor the first phase, with an experiment and an accountable delivery owner. Confirm whether the proposed scope includes digital development, organizational coaching or both. Agree how the client team will maintain the service after external specialists leave.
20. Gofore for an insurance journey with legacy and organizational dependencies
Gofore’s financial-services practice includes insurance customer journeys, service design, accessibility, omnichannel experiences and core-system modernization. Its broader design offer connects research, service development and changes to ways of working. This makes it relevant when the post-purchase experience is constrained by established systems and operational rules.
Consider a design-and-technology engagement for a bounded journey such as a policy change or an unresolved service request. Ask how the team will distinguish a usability issue from a data or process dependency. Identify the decision makers who can change those dependencies and the staff who will use the result. Settle the engineering scope, quality checks and adoption work explicitly. A clear customer message still needs reliable information and an organization able to act on it.
Start with the moment the promise breaks
Before hiring, choose one customer situation to investigate. “Improve the post-purchase experience” leaves too much room for teams to work on unrelated things.
A useful starting statement has three parts: what the customer was promised, what actually happened and which decision your business needs to make. For example: a confirmed appointment requires another document, but the request arrives after the customer has already traveled. The decision concerns when the requirement is communicated, who checks it and what happens when it is missing.
Trace that situation through the customer interface and the work behind it. A service blueprint is useful because it connects the customer’s actions with staff activities and supporting processes. Nielsen Norman Group explains the method
Include customers whose cases were resolved smoothly as well as those who complained. Compare what differed: information quality, staffing, policy, supplier behavior or the way work was assigned. Support records can reveal recurring symptoms, but they do not show every customer who quietly abandoned the service.
Give candidates the same practical brief
Ask each shortlisted partner to respond to the same bounded journey. The brief should contain enough operational detail to expose differences in the proposed work.
Define the start and finish. The start might be a confirmed order or accepted booking. The finish should describe the value delivered: the customer received the item, attended the appointment or obtained a resolved claim. A sent email is usually an intermediate event.
Show the promises customers see. Supply the confirmation, account screens, expected timing and relevant support messages. Identify which statements describe a firm commitment and which describe an estimate.
Name the people and systems involved. Include operations, support, product, engineering and external providers. Identify who can change a policy, reserve capacity or approve a new workflow.
Provide examples of exceptions. Delays, rescheduling, missing information and partial completion often reveal the handoff problem more clearly than an ideal journey.
Ask for a first deliverable that enables action. This might combine an evidence-backed diagnosis, a proposed service sequence, tested customer communication and a prioritized implementation plan. Require the partner to explain which decisions each output will support.
Specify the delivery boundary. Research and prototypes, embedded product ownership, software implementation and staff rollout are different purchases. Have each proposal identify the work included and the work your team must supply.
A practical example of a better handoff
Consider a hypothetical home-installation business. Customers pay for equipment and choose an appointment. They then receive a confirmation that looks final, even though an installer still needs to approve the job and verify that the equipment is available.
When either dependency fails, support must reconstruct the case from messages between the warehouse and installer. The customer keeps seeing the original appointment.
A useful intervention would investigate the operating sequence before changing the confirmation page. Can availability be verified earlier? Who accepts responsibility for approving the appointment? What should customers see while confirmation is pending? Who contacts them if the expected response does not arrive?
The first release might introduce a clearer pending state, a work queue for unresolved bookings and a named owner for exceptions. It could also change when the company offers a firm appointment. Those are product and operating decisions; better wording alone cannot supply missing capacity.
Test the proposed experience with both customers and staff. Customers should understand what is confirmed and what they can do next. Staff should be able to find the case, identify the required action and complete the handoff without a separate investigation.
Measure completion and the work required to achieve it
Choose measures that reflect the service being bought. Useful candidates include time from confirmation to completion, the proportion delivered within the promised window, unresolved cases by age, repeated customer contacts and cancellations while waiting.
Break these down by the situations that make the journey different. A service involving an external appointment may need a different view from one fulfilled automatically. An overall average can conceal a queue of customers experiencing long delays.
Pair speed with quality. Closing a case quickly is not an improvement if customers must reopen it. Fewer support contacts can also be ambiguous: customers may have found the answer, or they may have stopped trying. Review a sample of completed and unresolved cases alongside the dashboard.
Assign ongoing ownership before the project ends. Someone should maintain the operating rules, customer messages and exception process when the product or service changes.
For work that begins earlier in the journey, see ExpertShortlist’s subscription onboarding and checkout guide. For the handoff after confirmation, start with the provider whose engagement model matches the change you need and the team you have available.
Sources
Project examples are the providers’ published accounts. The hiring assessments explain fit; reported client outcomes are not guarantees.
Frequently asked questions
When should we hire a service design partner?
Consider a service design engagement when a customer journey crosses product, operations and support, and nobody can explain or fix the handoffs alone. Start with one bounded journey and include the people who can change its rules.
Does service blueprinting include implementation?
A service blueprint connects customer actions with staff activities and supporting processes. Implementation is a separate scope to confirm: proposals should identify who changes software, policies, customer messages and frontline practices.
