CUSTOMER SERVICE AND REQUEST MANAGEMENT
Preparing after-sales responses with the right context
Illustrative project
Illustrative scenario. The data and calculations are assumptions used to explain the application.
Application: Customer service and request management
Business type: Business equipment supplier
Key decision: How to handle each after-sales inquiry and which cases need escalation before responding to the customer.
The context and the problem
The equipment supplier sells equipment to businesses and receives questions about installation, operation, delivery, and warranties. Requests arrive by email and through a form. Customer Service looks up the order in one system, checks manuals in another, and asks Operations when information is missing. A customer may write again before receiving a response, creating a second case.
The team needs to bring this context together, distinguish similar inquiries, and prepare a response supported by evidence. A question about a manual and a warranty claim may mention the same product, but they require different permissions, owners, and criteria. A fast response with incorrect information could create more rework and commit the company to something it has not approved.
Information and authorized access
The project would use incoming requests, the minimum necessary order data, an equipment catalog, current manuals, approved policies, and owners for each category. It would define how to verify that a person making an inquiry is entitled to receive information about that order. Possessing an order number alone would not be sufficient if the policy requires an additional check.
The solution would access only the systems and fields it needs. Documents would have versions and validity dates; other customers' data would remain outside each case. Unexpected attachments or instructions inside a document could not expand permissions or change workflow rules. If the history were unavailable through an authorized integration, the team would agree on an assisted lookup or a narrower scope.
The proposed solution
STRTGY could design a workflow to classify requests, suggest an owner, gather evidence, and prepare a draft response. The case record would show the source of each relevant piece of information and what still needs confirmation. Low-confidence classifications, unverified identities, or conflicting sources would stop automatic preparation and trigger a review.
In the initial scope, an advisor would review every response before it was sent. Claims, returns, and potential safety incidents would go to the designated owner. The agent would not promise refunds, equipment replacements, warranty coverage, or unconfirmed dates. Those commitments would require a human decision and the relevant procedure.
A request's path through the process
Customer Service receives the case. The workflow records the channel and time, assigns an identifier, and flags possible duplicates without silently merging them.
The advisor verifies the connection to the order. They confirm the person's identity or relationship to the order according to policy, requesting only the missing information that is necessary.
The solution suggests a category. It distinguishes information requests, follow-ups, and claims. Ambiguous cases are reviewed before assignment.
The workflow gathers context. It retrieves authorized manuals and data, retaining the version, source, and last update date.
A draft is prepared. The response separates confirmed information from outstanding questions and avoids unapproved commitments.
The advisor reviews and decides. They revise the text, approve it, or escalate it to Operations or the warranty owner. Any potential safety risk follows its established protocol.
Customer Service sends the response and follows up. The approved send is logged. The case closes only under the agreed criteria and can reopen if the resolution was insufficient.
What users would see
The advisor would have a queue showing the suggested category, case age, owner, and reason for waiting. Inside the case record, they would see the original request, order context, documents consulted, and draft response. A visible flag would show whether identity verification, availability confirmation, or an exception review was needed. The customer would receive a response validated by the team, without having to navigate the internal process.
Illustrative image. Technical questions and exceptions go to an accountable person before a commitment is made to the customer.
Deliverables and phases
Deliverables could include a request catalog, ownership matrix, authorized sources, preparation workflow, escalation rules, and quality tests. Historical records and difficult cases would be reviewed first. The workflow would then be tested without sending responses, followed by a supervised pilot in low-risk categories. Expanding categories or allowing additional actions would require validating results, permissions, and scope. No rollout date is assumed.
Metrics to test its usefulness
A baseline would be established by category, separating active work from external waiting time.
First useful response: median time from receipt to the first response that resolves the issue or requests necessary information; automatic acknowledgments are excluded.
Work per case: active minutes spent preparing and reviewing responses / cases handled.
Reclassification: cases whose category changes after review / classified cases × 100.
Reopening: cases reopened within an agreed window / eligible closed cases × 100.
Hypothetical economic example
With 600 monthly requests and 12 minutes of preparation and review per case, the work would take 120 hours. If a pilot demonstrated that preparation and review together took eight minutes, it would free up 600 × (12 − 8) / 60 = 40 hours per month. At an assumed internal cost of MXN 250 per hour, that would be equivalent to MXN 10,000 in work capacity. This calculation does not demonstrate payroll savings and excludes implementation and operating costs. A higher error or reopening rate could reduce that value.
How much time does your team spend gathering information before responding? Let's review one category of requests.