# QA Analysis Report

Date: July 2, 2026
Product: VejalNai Chatbot
Audience: Product management, engineering, QA, and release owners

## Release Readiness Verdict

Current verdict: Beta only.

The product has enough features to demo the intended direction: shared inbox, bot replies, widget customization, inbound Meta channels, and team roles. It does not yet meet a production-grade bar because several core operational guarantees are incomplete.

## Product Promise Versus Current Reality

| Product promise | Current state | Gap |
| --- | --- | --- |
| Multi-channel chatbot agent | Web widget works. Facebook/WhatsApp inbound webhook intake exists. | External channel replies are not sent back to customers. |
| Human support takeover | Conversations can be assigned and human messages stored. | No outbound delivery service or delivery status. |
| AI/bot monitoring | `monitor_ai` privilege exists. Unknown questions can be resolved. | No AI monitor queue, approval workflow, confidence review, or audit trail. |
| Team roles and privileges | Roles and privileges exist in UI and DB. | Enforcement is incomplete outside team/assignment actions. |
| Widget customization | Admin can change colors, logo, copy, quick replies, position, origins. | No contrast validation, presets, preview regression tests, or session hardening. |
| SDK support | Android and iOS starter clients exist. REST platform values exist. | SDKs are post-message starters, not full production SDKs. |
| Production readiness | Health/ready endpoints, cache commands, encrypted secrets exist. | CI, RBAC, webhook idempotency, rate limits, audit logs, and provider health are missing. |

## Critical User Journeys

### 1. Website visitor asks a known question

Expected:

- Visitor opens widget.
- Visitor sends message.
- Bot matches approved intent.
- Bot replies immediately.
- Conversation appears in admin inbox.

Current assessment:

- This flow is mostly working.
- Known risks: visitor identity is weak, public endpoint lacks rate limiting, and UI needs visual regression coverage.

### 2. Website visitor asks an unknown question

Expected:

- Bot creates unknown question.
- Bot requests phone or says support will follow up.
- Conversation switches to human handoff.
- Callback task is visible.
- Human can resolve/train answer later.

Current assessment:

- This flow exists and is covered by tests.
- Known risks: training action lacks `train_ai` enforcement, callback completion lacks `manage_callbacks`, and no audit log records who changed bot knowledge.

### 3. Agent replies to a customer

Expected:

- Agent message is saved.
- Customer receives the reply on the original channel.
- Delivery status is visible.
- Failed delivery is retryable.

Current assessment:

- Local save works.
- Customer delivery only works indirectly for the web widget through polling/history.
- Facebook and WhatsApp delivery is absent.
- This is the largest release blocker.

### 4. Admin connects Facebook or WhatsApp

Expected:

- Admin enters credentials.
- System validates token and webhook configuration.
- Inbound and outbound health are visible.
- Signature verification is enforced in production.

Current assessment:

- Credential storage and inbound webhook intake exist.
- No token validation, subscription check, outbound send, health status, or required signature mode exists.

### 5. Owner manages team roles

Expected:

- Owner creates users.
- Roles and privileges control access.
- Last owner cannot be removed.

Current assessment:

- Team UI and core safeguards exist.
- Privilege enforcement is incomplete in other product areas.
- No invitation flow or password reset/onboarding path exists yet.

## Risk Analysis

| Risk | Severity | Probability | Product impact | Mitigation |
| --- | --- | --- | --- | --- |
| External channel replies are never delivered | P0 | High | Customers do not receive agent replies. | Build outbound delivery service and status tracking. |
| Duplicate webhook events create duplicate work | P0 | Medium-high | Duplicate bot replies/callbacks hurt trust and operations. | Store provider IDs and enforce idempotency. |
| Privilege bypass through membership-only checks | P0 | High | Unauthorized users can change settings or reply/train. | Centralize policies and add denial tests. |
| Bangla command text is corrupted | P1 | High | Target-language UX breaks. | Fix UTF-8 strings and add localization tests. |
| Public widget history identity is weak | P1 | Medium | Possible privacy/data leakage. | Signed widget sessions and rate limits. |
| Signature verification left off in production | P1 | Medium | Spoofed inbound traffic. | Production guardrail requiring SHA-256. |
| No audit log | P2 | High | Hard to investigate changes and support disputes. | Add audit events for admin/support actions. |
| No CI gate | P2 | Medium | Regressions can merge unnoticed. | Add PHPUnit, Pint, cache, and lint gates. |
| Polling-based inbox/widget | P2 | Medium | Scale and latency issues. | Move to queues and WebSockets/Reverb later. |

## Security And Privacy Analysis

Strengths:

- Dashboard routes are behind session authentication.
- CSRF protection applies to web forms.
- Channel access tokens and app secrets use encrypted Eloquent casts.
- Widget CORS can restrict allowed origins.
- Health and readiness routes are separated.

Weaknesses:

- RBAC is not consistently enforced.
- Empty widget allowed origins means any origin is allowed.
- Public widget history uses client-managed visitor id.
- Public widget APIs lack rate limiting.
- Webhooks can accept unsigned requests when configured off.
- No audit trail for settings, channel, team, training, and reply actions.
- No delivery logs for external channel messages.

## Functional Coverage Analysis

Covered reasonably well:

- Auth login/logout.
- Dashboard access.
- Organization membership basics.
- Conversation foundation.
- Bot matching and incoming flow.
- Widget API basic behavior.
- Channel inbound webhook happy paths.
- Team create/update/delete basics.
- Callback and unknown-question basic pages.

Insufficient coverage:

- Authorization denial for every privilege.
- Duplicate webhooks.
- Outbound external channel sends.
- Widget session security.
- Rate limits.
- Appearance contrast and responsive UI.
- Meta signature modes.
- SDK request contracts.
- Audit log creation.
- Production config requirements.

## Non-Functional Analysis

Performance:

- Current polling is acceptable for prototype use.
- Conversation lists load all conversations for an organization and will need pagination/search for production.
- Bot matching loads intents, phrases, and response templates into PHP and is fine for small datasets, but needs indexing/evaluation for scale.

Reliability:

- Queue configuration exists in docs and `.env.example`, but current local runtime uses sync queue.
- External sends should be queued with retry/backoff.
- Webhook processing should be idempotent and resilient to partial failures.

Maintainability:

- Laravel boundaries are generally clean.
- Business logic is concentrated in services for bot processing/matching.
- Widget JavaScript is large inside a PHP heredoc, making it harder to test and maintain.
- Policies are missing, which spreads authorization logic across controllers and requests.

Localization:

- Product targets Bangla, Banglish, and English.
- Source currently contains corrupted Bangla command text.
- Strings are hard-coded instead of translation files.

## Product Management Assessment

What is good:

- The product direction is clear.
- The Crisp-inspired inbox concept matches the target support use case.
- The widget customization scope matches user needs.
- Teams and privileges are the right foundation for human support.
- Channel settings and SDKs show the correct platform ambition.

What is not ready:

- Multi-channel cannot be claimed as complete until replies leave the system.
- AI monitoring is a permission, not a workflow.
- SDK support is starter-level.
- Production security gates are not enforced.

## Recommended Product Strategy

1. Freeze broad feature expansion for one stabilization phase.
2. Fix P0 correctness gaps first.
3. Turn external channels into complete two-way channels.
4. Add visible production readiness status inside admin settings.
5. Add AI monitoring only after delivery/RBAC/idempotency are correct.

## Release Gate

The product can move from beta to production candidate only when:

- PHPUnit, Pint, PHP lint, config cache, route cache, and view cache pass in CI.
- All P0 findings are closed.
- Every write route has privilege tests.
- Facebook and WhatsApp replies are delivered and retryable.
- Webhooks are idempotent.
- Widget sessions are signed and rate limited.
- Audit log exists for sensitive actions.
- Admin onboarding shows channel/widget/security health.
