Business Analysis
User Personas
Representative, not customer-validated.
Source: support-system: personas derived from roles, permissions, and workflows in the implemented system
Support System: User Personas
These personas are representative, not validated. They were written from the roles the system defines, the permissions each role holds, and the workflows the interface supports. No agents, supervisors, or customers were interviewed. They are a way to keep design trade-offs concrete, and they should be replaced with research findings if the product meets real users.
The names are invented.
Persona 1: Alex, support agent
Role in the system: Agent. Can view assigned tickets, reply, add notes, and use macros. Cannot manage routing, SLA, or roles.
Context. Works a queue through the day, switching between email, chat, and WhatsApp tickets. Needs to answer quickly without losing track of what a customer said last time.
Needs
- Tickets arrive routed to them, with the customer's history beside the conversation.
- To know when a colleague is replying to the same ticket.
- To set a status when replying without a second click.
- A way to step away that does not strand tickets.
Frustrations the product addresses
- Being handed a ticket with no explanation of why it is theirs. The reason is stored on the assignment.
- Customers repeating themselves. Sticky routing sends returning customers back to their previous agent when that agent is eligible.
- A clock that keeps running while a customer is silent. Pending pauses it.
Where the product falls short for Alex. No suggested replies. Attachments live on local disk, which is irrelevant in a demo and would matter in a hosted product.
Success looks like. A queue they trust and a short path from ticket to reply.
Persona 2: Priya, support supervisor
Role in the system: Supervisor. Can view all tickets, assign and merge them, manage queues and routing, view SLA policies, and view and export analytics. Changing an SLA policy needs the Admin or Owner role, which is a gap for this persona.
Context. Responsible for response times and for how work is spread across a team of agents with different skills, languages, and shifts.
Needs
- A live picture of the queue and who is online.
- Warning before an SLA breach, not a report afterwards.
- To change routing behaviour without asking an engineer.
- To explain to an agent why a ticket moved.
Frustrations the product addresses
- Not knowing why a ticket is unassigned. The queue reason is shown on the ticket.
- Uneven load. Rebalancing moves untouched tickets from the busiest agent to the least busy qualified one.
- Rules she cannot read. The routing settings describe each rule in plain language and mark which values are customised.
Where the product falls short for Priya. No report of how long tickets spend paused, so she cannot yet see whether pending is being used to stop clocks. No routing recommendations.
Success looks like. She sees a problem forming and fixes it with a setting, not a ticket to engineering.
Persona 3: Sam, workspace administrator
Role in the system: Owner. Holds every permission. The Admin role holds every permission except theme.manage, so branding stays with the Owner.
Context. Sets up and maintains the workspace. Connects channels, defines who can do what, and keeps the system tidy.
Needs
- Roles that match real job functions.
- To connect email, chat, WhatsApp, and SMS without code.
- To keep an integration's access narrow.
- An audit trail of changes.
Frustrations the product addresses
- Over-broad access. Roles and API keys can only hold keys from one permission catalog.
- A product that looks unlike the company. Branding is applied at runtime with a live preview.
Where the product falls short for Sam. No single sign-on. The API documentation covers part of the surface.
Success looks like. A new team is working within an afternoon, and nothing they can do surprises him.
Persona 4: Rita, customer
Role in the system: Not a user. Contacts the company through a channel and may answer a survey. Does not sign in.
Context. Writes in when something is wrong, usually on the channel most convenient for her. Wants the answer once, from someone who knows what happened.
Needs
- A reply on the channel she used.
- Not to explain again.
- Her follow-up message not to vanish.
What the product does for Rita
- Continuity through sticky routing, subject to the agent being available.
- A new linked ticket when she writes after closure, rather than a lost message.
- A satisfaction survey after the ticket is solved.
Where the product falls short for Rita. No portal to see her tickets. No way to see status without writing in.
Success looks like. She does not notice the system at all.
How the personas were used
| Decision | Persona it served |
|---|---|
| Reason stored on every assignment | Alex, Priya |
| Pending pauses the SLA clock | Alex, Priya |
| Sticky routing | Rita, Alex |
| Layered routing policy in plain language | Priya |
| Permission catalog shared by roles and API keys | Sam |
| Linked follow-up for closed tickets | Rita, Priya |
Limitations
- No interviews, observation, or usage data.
- Four personas do not cover a real support organisation. There is no persona for a billing specialist, a team lead who is also an agent, or a customer who is another company's integration.
- The personas describe intended use. They say nothing about whether the intended use is correct.