CUSTOMER SERVICE AND REQUEST MANAGEMENT
Tracking internal requests across teams
Illustrative project
Illustrative scenario. The data and calculations are assumptions used to explain the application.
Application: Customer service and request management
Business type: Multisite business
Key decision: Who should handle each request, what information they need, and when it should be escalated.
The context and the need
The business manages several sites and receives internal requests for maintenance, furniture, and general services. Employees contact different people; some requests are duplicated, while others move between departments without a visible owner. When someone asks for an update, Administration reconstructs conversations and searches for files.
The priority is to organize intake, gather enough information, and maintain follow-through. A broken light, a layout change, and a repair requiring an outside provider should not all follow exactly the same process. The team needs to distinguish operational urgency, incomplete information, and decisions that involve spending. A priority label should never, on its own, count as purchase authorization.
Inputs and permissions
The scope could include forms, an authorized internal inbox, a site directory, a service catalog, owners, working hours, and service rules. If a ticketing system exists, its integration would be assessed. Otherwise, a controlled register suited to the volume and tracking needs would be defined.
Each request would need a location, description, and contact. Photos or documents would be requested only when they provide necessary context. Employees would see their own cases, while each team would see what it needs to handle. Requests containing sensitive personal data would be separated and sent to the appropriate channel. Access rules would not be inferred solely from the requester's text.
The proposed workflow
STRTGY could structure a shared intake process that suggests a category and owner, identifies missing information, and gathers authorized background records. The solution would prepare summaries for the people receiving the work and maintain a status the requester can understand. Transfers between systems would depend on integrations and permissions confirmed during design.
Priority criteria would be agreed with Operations. A possible emergency would leave the ordinary workflow and follow the established human-led protocol. Ambiguous cases would go to a review queue. Purchases, engaging providers, access to facilities, and security changes would retain their specific authorizations. The workflow could prepare information without replacing those decisions.
How a case would be handled
The employee describes the need. Intake records the site, location, and contact, and explains what information is missing before work can continue.
The solution prepares a classification. It suggests a service and owner, showing which details in the request support the proposal.
The coordination team confirms the route. It reviews ambiguities, duplicates, and urgent requests. Potential critical incidents follow the defined protocol.
The owner assesses the case. They review the background and determine whether they can handle it, need a site visit, or require additional approval.
An authorized person decides. If spending or a restricted intervention is involved, they review the case through the existing process. A rejection returns the case with a reason and a next step.
The service team updates the record. It records progress and evidence. The workflow prepares status updates for communication through authorized channels.
The requester confirms the outcome. They confirm the service was completed or explain what remains outstanding. Closure and any reopening retain a history with named owners.
What users would see
Employees would see the status, owner, last update, and information they need to provide. The coordination team would have a queue organized by age and reason for blockage, distinguishing cases awaiting the requester, approval, or work. Owners would have access to a summary alongside the original sources. The interface would avoid presenting an estimated timeframe as a promise when it still depends on a visit or an outside provider.
Photographic illustration of coordination to clarify a request’s context and confirm who should handle it.
Deliverables and rollout
The project could deliver a service catalog, routing rules, a permissions matrix, forms, a tracking register, and test scenarios. Work would begin with one site and representative categories, validating both ordinary cases and exceptions. The pilot would include human review of routing and reconciliation with the source system. Expansion would depend on acceptance by the responsible teams and their actual service capacity, without committing to dates before the initial assessment.
What to measure
A baseline would be established using comparable requests, also recording the volume that currently arrives outside the main channel.
Correct assignment: requests accepted by the first assigned owner / assigned requests × 100.
Time to assignment: median hours from receipt to a confirmed owner.
Overdue open requests: open requests exceeding the agreed service criterion / open requests × 100.
Transfers: number of department changes per request, excluding planned approval steps.
Reopening: reopened requests / eligible closed requests within the agreed window × 100.
Hypothetical economic example
If 400 monthly requests require ten minutes of classification and administrative follow-up each, they total approximately 66.7 hours. If a pilot verified six minutes per request, including review, the difference would be 400 × (10 − 6) / 60 ≈ 26.7 hours. At an assumed internal cost of MXN 240 per hour, that would be equivalent to MXN 6,400 per month in work capacity, calculated before rounding the hours. Repair work is excluded and is not assumed to disappear. Operating costs, maintenance, and the initial investment need to be evaluated separately. Better organization also does not automatically increase providers' capacity.
Where do your team's requests lose momentum today? Let's review owners, intake channels, and exceptions.