Accenture case interviews: make the idea workable.

Accenture recruits across a wide range of work. Use your job description and interview invitation to identify whether you should expect a business discussion, a technical assessment, a presentation or a combination. Ask about preparation time, materials and the expected output before choosing your mock format.

Define success, explain assumptions and respond to the interviewer's cues. Prepare to discuss your experience too: the balance between the case and your background can vary by role.

Read the role description as a list of things you may need to demonstrate. If it mentions implementation, have an example of getting a change into use. If it mentions analytics, practise explaining how a finding changed a decision. Knowing the vocabulary is the beginning; showing what you did with it is more persuasive.

Consider this original practice scenario:

A retailer's customer support team takes too long to respond. Its director wants to introduce an AI assistant. Should the company proceed?

“Assess people, process and technology” gives you headings but leaves the decision untouched. A more useful opening is:

“I would first establish which customers are waiting and where the delay occurs. Then I would compare ways to remove that delay, including the proposed assistant, and test the cost and service implications.”

Ask what “too long” means. Time until the first reply and time until the customer's problem is resolved are different measures. An instant acknowledgement can improve one while doing nothing for the other.

Suppose the goal is to resolve routine order queries within one working day. You now have a specific outcome against which to assess the proposal.

Imagine these simplified facts:

Assume every response requires approval, the stages operate steadily and the team starts with no backlog. At the end of the first week, 200 queries remain unresolved. The assistant does not change that: approval still limits completed responses to 800.

This is the central finding. Say it before brainstorming features:

“Faster drafting will not meet the service goal while every response waits for supervisor approval. I would address the approval step before buying more drafting capacity.”

Then investigate why approval exists. Supervisors might catch incorrect refunds, protect customer information or compensate for an unclear policy. The solution depends on the reason. Removing a control without understanding its purpose is as weak as automating the queue in front of it.

Suppose the interviewer says 60% of queries are simple order-status requests. Agents already have reliable order data, and the business is willing to let them send those responses without approval. The remaining 40% still need a supervisor.

That leaves 400 approvals per week against capacity of 800. Drafting capacity of 1,200 also exceeds arrivals of 1,000. Under these simplified conditions, the process change can handle the incoming workload without the assistant.

I would recommend testing that change first. It directly removes the constraint and gives the client a useful comparison for any subsequent technology investment.

Do not conclude that the assistant has no value. It might reduce drafting effort, improve consistency or help absorb seasonal demand. Those are separate benefits to evaluate after establishing that response capacity is no longer the immediate problem.

Ask what the assistant would cost, how much editing its drafts require and whether the team can use the released time. Compare it with the improved process, rather than taking credit again for a problem the process change already solves.

“Run a pilot” is incomplete until you say what it will establish.

For this retailer, start with one query category, a defined team and a clear escalation rule. Compare resolution time, incorrect responses, repeat contacts and staff effort with a comparable group using the current approach. Check performance when order data is missing or the customer asks for something outside the routine policy.

A fast first response that triggers two more contacts may create extra work. Measure the whole interaction.

Set the next decision in advance: expand the process change if service improves without an unacceptable increase in mistakes; add the assistant only if it produces enough additional value to justify its cost and operating requirements. The exact thresholds should come from the client's service and financial objectives.

Prepare a story in which you had to make an idea work with other people. A university project, operational improvement or product rollout can all serve this purpose.

Explain the original problem, your own contribution, the resistance or constraint you encountered, and the outcome. Be ready for “What would you do differently?” and “How did you know the change helped?”

If you have technical experience, translate it. “We migrated the database” describes an activity. Explain which customer or operational problem the migration addressed, how you managed the transition and what improved afterwards.

Use Accenture's case workbook for structured exercises. It includes both sparse prompts and cases with more information than you need. Practise deciding what matters in each.

Then return to the retailer example. Have a partner reveal that arrivals double during a sale, or that half the supposedly routine queries contain incomplete data. Update your recommendation aloud. The point is to show that you can carry a proposal through new information and explain the consequence clearly.

For a longer exercise, choose an unfamiliar operations case from the case library. Finish with a recommendation that names the first operational change and the evidence needed before spending more.