Relationships

Relationships are the central concept in Matchpal, representing the working connection between a student and a provider.

What is a Relationship?

A relationship in Matchpal represents:

• A pairing between one student and one provider
• A specific service type (tutoring or advising)
• An allocated grant amount (hours or sessions)
• The complete history of their interactions

Think of it as a contract: the student has hours available, the provider delivers services, and the relationship tracks everything.

Relationship Structure

Each relationship contains:

Core Properties

Grant Allocation

Activity Records

• Sessions conducted
• Revisions completed (advising)
• Communications exchanged
• Status change history

Relationship Lifecycle

Relationships progress through defined stages:

Proposed → Paired → Completed
              ↓
           Declined
              ↓
          Cancelled

Proposed

The initial state when a match is created:

• Generated by matching algorithm or admin
• Waiting for provider response
• Student notified of the proposed match
• Grant hours held (reserved) from student's balance

Transitions from Proposed:

• Provider accepts → Paired
• Provider declines → Declined
• Admin cancels → Cancelled
• Timeout occurs → Declined (configurable)

Paired

Active working relationship:

• Provider has accepted the proposal
• Sessions can be conducted and logged
• Grant hours being consumed
• Both parties can communicate

Transitions from Paired:

• Services completed successfully → Completed
• Either party or admin ends early → Cancelled

Completed

Successfully concluded relationship:

• All intended services delivered
• Final session logged
• Grant usage finalized
• Any unused hours released back to student
• Historical record preserved

Declined

Provider did not accept the proposal:

• Provider explicitly declined, or
• Proposal timed out without response
• Student notified of decline
• Grant hold released
• May trigger re-matching process

Cancelled

Relationship ended before completion:

• Initiated by admin, student, or provider
• Reason documented
• Grant hold released for unused portion
• Historical record preserved

Multiple Relationships

Students can have multiple relationships:

Concurrent Relationships

A student might have:

• One relationship for tutoring
• Another for advising
• Multiple tutoring relationships (different subjects)

Each relationship has its own:

• Provider
• Grant allocation
• Session history

Sequential Relationships

Over time, a student might:

• Complete one relationship
• Start a new one with a different provider
• Or return to a previous provider

Grant Management in Relationships

Initial Allocation

When a relationship is created:

1. Admin or system specifies hours
2. Those hours become "held" on student's account
3. Available balance decreases
4. Provider knows hours are reserved

During Active Relationship

As sessions occur:

1. Provider logs session
2. Hours deducted from relationship allocation
3. Student's "used" total increases
4. Remaining hours decrease

At Completion or Cancellation

When relationship ends:

1. Used hours finalized
2. Unused hours released from hold
3. Student's available balance increases
4. Final accounting recorded

Viewing Relationships

For Students

Students see their relationships:

• Current active relationships
• Proposed matches awaiting response
• Past completed or cancelled relationships
• Hours used and remaining per relationship

For Providers

Providers see their relationships:

• Current assigned students
• Pending proposals to respond to
• Historical client relationships
• Session counts per relationship

For Admins

Admins see all relationships:

• Platform-wide relationship list
• Filterable by status, student, provider, date
• Detailed view of any relationship
• Ability to modify or intervene

Creating Relationships

Through Matching

Most relationships are created by the matching algorithm:

1. Student completes intake questionnaire
2. Matching algorithm runs
3. Best provider matches identified
4. Proposals created and sent
5. Providers respond

See Matching Algorithm for details.

Manual Creation

Admins can create relationships directly:

1. Select student
2. Select provider
3. Choose service type
4. Set hour allocation
5. Create relationship (starts as Proposed)

Modifying Relationships

Adjusting Allocation

If a relationship needs more hours:

1. Admin opens relationship
2. Adjusts allocated hours
3. Additional hours held from student's grant
4. Relationship continues

Reassigning

If student needs a different provider:

1. Admin opens relationship
2. Selects "Reassign"
3. Chooses new provider
4. Original relationship declined
5. New proposal created

Cancelling

If relationship needs to end:

1. Admin opens relationship
2. Selects "Cancel"
3. Chooses reason
4. Unused hours released
5. Both parties notified

Relationship Best Practices

For Healthy Relationships

• Clear expectations set at start
• Regular session cadence
• Prompt communication
• Issues escalated early

Warning Signs

• Long gaps between sessions
• Repeated cancellations
• Communication problems
• Grant usage anomalies

When to Intervene

Admins should step in when:

• Provider not responding to proposals
• Either party reports issues
• Unusual patterns detected
• Grant running low without progress

Related Documentation

• Managing Relationships - Admin guide
• Matching Algorithm - How matches are created
• Sessions - Tracking service delivery
• Grants & Packages - Billing context