One inbox or form.
Choose one source of support requests and agree which records the pilot can use. Data access and permissions are confirmed before work begins.
Services / AI workflow pilot
AI support-intake pilot.
Your team stays in control.
Start with one inbox or form. Classify incoming requests and prepare draft replies for an authorised person to review. Your team sends the final response through its existing process.
Remote delivery led by Arjit Srivastava. We validate the proposed workflow before agreeing its scope and delivery schedule.
(01)
A small, defined workflow.
Classify and draft.
One AI step proposes a request category and drafts a reply using agreed instructions and approved sample material.
One human review destination.
The output goes to an agreed place for an authorised reviewer to check, correct or reject it. The pilot does not send customer replies automatically or take downstream business actions.
A limited integration scope.
At most two business apps, plus the model provider. The specific connections depend on available APIs or connectors, authorised access and a feasibility check.
(02)
Agree how the pilot will be accepted.
The written scope defines the inputs, expected outputs, reviewer and acceptance criteria before implementation. The pilot includes:
- 20 agreed tests using no more than 200 records. These cover the agreed categories, reply guidance, uncertain or malformed inputs, and human review.
- One revision within the agreed scope. Additional workflows, apps or requirements are quoted separately.
- A documented handover. Review the workflow, its limitations, test results and the steps your team will use to operate it.
- Seven calendar days of defect correction. The written scope defines the coverage and start date. This does not include new features or ongoing operations.
AI output needs review. The pilot does not promise a particular accuracy rate, time saving or business result. Acceptance depends on the criteria we agree and the test results.
(03)
What should your reviewer accept?
Before connecting a support workflow, agree how your team will recognise a useful draft and when it must be corrected. These four examples show the request, proposed routing and a reviewer’s reasoning.
Synthetic examples, not performance results. The requests are invented and the drafts were written for this guide. No live model evaluation is represented. The unsuitable drafts are teaching examples, not observed model failures. Your categories, escalation rules and acceptance tests must be agreed separately.
A mail app needs clarification
Invented request: Since a password change, Outlook prompts me every few minutes. Web mail and Teams still work. Only I am affected.
Expected routing in this example: email · normal · Service Desk
Reject this illustrative draft: “Your password has been reset and Outlook is fixed.”
Reviewer’s correction: Web mail still works, and no reset or repair has been performed. Remove the unsupported completion claim.
Revised illustrative draft: “Which Outlook version and operating system are you using? Please share the non-sensitive error text, if any. Do not send passwords or verification codes. You reported that web mail still works; the reviewer can use that distinction when investigating.”
Evaluation status: not run. These drafts illustrate a review decision; they are not measured model outputs.
An access request needs approval
Invented request: My individual mailbox works. I have never had permission to open our shared support mailbox. Please grant me access.
Expected routing in this example: access · normal · Identity Team
Reject this illustrative draft: “You now have access to the shared mailbox.”
Reviewer’s correction: A request is not an approval. The draft must leave permission changes to an authorised person.
Revised illustrative draft: “Please use your normal access-request process to identify the shared mailbox and its approver. An authorised person must review the request before any access is granted. No permission change has been made.”
Evaluation status: not run. These drafts illustrate a review decision; they are not measured model outputs.
A reported outage needs human triage
Invented request: Nobody in our 40-person team can send or receive mail. Both desktop Outlook and web mail are failing now.
Expected routing in this example: email · urgent · Service Desk
Reject this illustrative draft: “The email provider is down. Service will return in 30 minutes.”
Reviewer’s correction: The reported impact supports urgent triage, but neither the cause nor a restoration time has been verified.
Revised illustrative draft: “You report that the whole team cannot send or receive mail in either Outlook or web mail. What time did this begin, and what non-sensitive error message appears? Please use your agreed urgent-support channel so the responsible team can investigate.”
Evaluation status: not run. These drafts illustrate a review decision; they are not measured model outputs.
A vague request needs context
Invented request: It is not working.
Expected routing in this example: other · normal · Service Desk
Reject this illustrative draft: “Restart Outlook to resolve your email problem.”
Reviewer’s correction: The request does not identify an application or an email problem. Ask for context before proposing a diagnosis.
Revised illustrative draft: “Which system is not working, what were you trying to do, and what happened? Please share any non-sensitive error text and whether other people are affected. Do not include passwords or unrelated personal documents.”
Evaluation status: not run. These drafts illustrate a review decision; they are not measured model outputs.
Use the same review method: check routing against your written policy; look for unsupported actions, diagnoses or promises; then accept, edit or reject the draft. Record the reason and reviewer. An unrun example is never a passed test.
The queue names above are illustrative. “Urgent” flags a reported impact for human triage; it does not confirm an incident or promise a response time. These examples do not replace the acceptance tests in your written pilot scope.
For an initial enquiry, describe your inbox or form, request types and reviewer. Keep credentials and sensitive tickets out of the message.
Follow CompileSquad on LinkedIn for practical workflow examples and human-review checklists .
(04)
Validate first. Then agree delivery.
Arjit Srivastava leads delivery with AI-assistant support for implementation. Before committing to a delivery date, we check the chosen apps and model provider, approved samples, data-handling permissions, access, costs and Arjit’s availability.
You provide a workflow owner, an authorised reviewer, approved sample requests and response guidance. We demonstrate the proposed path with those samples before confirming implementation. There is no fixed delivery timeline until these prerequisites and the written scope are agreed.
Our homepage workflow demonstration uses sample data and simulated actions. It is not a customer deployment, does not connect to business systems and does not send requests to an AI model. It illustrates the approach; live compatibility must be validated for your pilot.
Ongoing management, additional integrations, autonomous sending and broader business-process outsourcing are outside this pilot. Any later work requires a separate scope.
Start with your processTell us what arrives.
Tell us what arrives.
And who reviews it.
Share the inbox or form you use, the types of requests you receive and where your team reviews replies. We can then assess whether this pilot fits.
Phone
+91 8808002220How we work
Entirely remote.
No customer-facing office or in-person visits.
An initial discussion confirms fit. Implementation begins after the written scope, commencement payment and required access are agreed.